> Hence, over-fetching is not an option<p>If you actually measure real latencies (e.g. collect metrics from your mobile apps), this is not true most of the time, at least in my experience. Most responses are fairly small, making them a bit smaller doesn’t have much impact on mobile app performance in the real world.<p>I’d guess for most apps, there are maybe a handful of endpoints where the response size can be reduced a tonne for mobile clients, <i>AND</i> that makes a big performance difference in practice. But instead of hopping straight to BFFs, or other approaches to solving this like GraphQL, you can just add a “fields” query param to those few key endpoints. If provided by the caller, you return only the fields they ask for. No massive re-architecture to BFFs or GQL, just a small change to a couple endpoints that a single dev can implement in a day or two.<p>Now, there are other benefits to BFFs than minimal, client specific payloads. One is that you can make breaking changes to underlying APIs, and not break always-so-slow-to-upgrade mobile clients, by preserving backwards compatibility in your mobile BFF layer. Another is coordinating multiple calls - turning many sequential round trips into a single round trip can be a big win. But if your main concern is payload size, BFFs are probably an over engineered solution.
BFF is perhaps the purest example of Conway's law. When the backend team cannot or will not make the necessary changes for the frontend team, another layer is introduced: the BFF. There is no particular reason why the real backend can't solve this problem; it is purely political.
There's a massive benefit missed here: backwards compatibility! Or more specifically, the lack of a need for it.<p>If you force your frontend to only use what makes sense as a "general" backend API, it ends up being inefficient. There are 1:n calls needed to get all data, or a lack of a specific filter requires pulling back everything to do client side filtering, etc.<p>On the other hand, if you build out your back-end to support every single front-end use case, it gets massive quickly. If other third parties start using it (as part of your published API) you now are forced to support it long term - even if your frontend changes and no longer consumes it - until you finally decide to break backwards compatibility (and the third party app). Break things enough and your users will quickly hate you.<p>This is especially true early on, when your frontend is going though rapid and radical changes.<p>I see BFF as the intermediate, giving best of both. You can rapidly adapt to front-end needs but don't commit to long-term support. There's actually no need for BC support at all if you can deploy front-end and BFF atomically.<p>If you build your code in a structured way, you're sharing the actual business and data logic, and it's trivially easy to "promote" a BFF resource to the official API, with whatever BC commitment you want to provide. The key thing is you are doing this deliberately, and not because the front-end is trying something out that might completely change in the next iteration.
I can't say I see the point of this, unless you have a criminally unresponsive backend dev team.<p>Any half-decent backend API will offer parameters to limit the response of an endpoint, from basic pagination to filtering what info is returned per unit. What's the use of extra complexity of a "BFF" if those calls can be crafted on the fly.<p>And to be clear, I am <i>not</i> suggesting that custom endpoint be crafted for every call that gets made, that just seem like a strawman the article is positing; but rather that calls <i>specify</i> when info they need.
I think it’s a great idea, except that instead of BFF, we should call that layer “a view”. The microservices can be then called “controllers and models”
I feel like another alternative in this space is to use GraphQL: while it does introduce complexity in terms of query handling, it does allow each frontend to more precisely query the data model and avoids having to tightly couple the frontend data model to the backend data model.
Call me an old gray beard here. But, IMHO the client is x10 more complex in all platforms. Pumping out crud api calls is fast. Dealing with React/swift/state management/product managers is not. So with this project BFF I feel it's going the wrong way. We need ways to help the clients do less work faster. Not the backends. Client team members don't need more work - working on a BFF. They need less work, maybe Backend team members do more client work near the api layer.
Huge fan.<p>Our company has been working on a new large platform built around BFF and it's been really nice to work with.<p>We have several SPA and mobile apps which interact with our data very differently. It took a bit to break the mindset of using the HTTP layer as the "point of reuse" but now it's far easier to add and maintain functionality.<p>We feel much more productive compared to past projects where we spent a lot of time trying to make "one API to rule them all" with a single ever-changing model.
I like Remix's take on it: <a href="https://remix.run/docs/en/v1/guides/bff" rel="nofollow">https://remix.run/docs/en/v1/guides/bff</a>
Based on my experience seeing this in action, adopt this at work if you want to have every team create their own shitty ad-hoc service mesh that sucks. Now adding a column to a table takes three PRs and three deploys! And you have to write redundant tests for each stupid layer.
That is still complicated. To maximally reduce complexity you need less. After all the word <i>complexity</i> literally means <i>many</i>.<p>1. Use a single traffic receiver at both the browser application and the terminal application. This thing works like a load balancer. It receives messages from a network and sends them where they need to go. There is only 1 place to troubleshoot connectivity concerns. You can still choose between monolith and multi-service applications and have as many micro services as you want.<p>2. Reduce reliance on HTTP. HTTP is a unidirectional communication technology with a forced round trip. That is a tremendous amount of unnecessary overhead/complexity. I prefer a persistent websocket opened from the browser. Websockets are bidirectional and there is no round trip. This means no more polling the server for updates. Instead everything is an independent event. The browser sends messages to the server at any time and the server independently sends messages to the browser as quickly as it can, which is real time communication happening as quickly as your network connection has bandwidth and your application can process it.
At my last company, when we were building a greenfield application, we leveraged this pattern, at a time when GraphQL was not yet available. In my new company, I look at GraphQL and realize that this solves the BFF pattern in a standardized way
I see people say "graphql" a lot in this thread.<p>There are a number of downsides to graphql that arise from its overly generic (and yet, at the same time, not generic enough) nature. No HTTP caching of graphql requests is one. Very deeply nested payloads is another. Difficulty of expressing complex query logic through parameters. Inability to natively represent structures such as trees of unknown depth. Special efforts spent on preventing arbitrarily deep/complex queries. And so on.<p>A BFF does not have any of these problems. It can be made as closely tailored to a particular frontend as possible. It does not need to concern itself with a generic use case.
I really like the BFF pattern as it can solve a lot of problems. That said, I've always found it quite complicated to build BFFs because there was no such thing as a "BFF Framework", which was one of the reasons we've built WunderGraph. One of the core use cases is to make building BFFs easy and solve a lot of cross cutting concerns. The idea is that you don't really "write" a BFF but rather generate most of it by treating APIs (origins) as dependencies. I'd love to hear what you think about this approach on implementing the BFF pattern:<p><a href="https://docs.wundergraph.com/docs/use-cases/backend-for-frontend" rel="nofollow">https://docs.wundergraph.com/docs/use-cases/backend-for-fron...</a>
> The latter [BFF] is responsible for:
>
> Getting the data from each required microservice
>
> Extracting the relevant parts
>
> Aggregating them
>
> And finally returning them in the format relevant to the specific client<p>I am pretty certain that the only reason why BFF were invented is for security in mobile and SPA applications, to securely deal with OAuth tokens.<p>If you don’t need that don’t use a BFF, keep things simple. Start by not building a SPA when it can be a classic server client web app. I feel like most of the web should just be that.
Feels like it would fit right in to this architecture: <a href="https://www.youtube.com/watch?v=y8OnoxKotPQ" rel="nofollow">https://www.youtube.com/watch?v=y8OnoxKotPQ</a>
I've seen this pattern frequently lately -- front-end team develops "full stack" MVP using a react/node type stack. Then someone like me comes along when real back-end features are needed, and writes something in python, like an admin page. The point of contact is the db (typically Mongo) - and later on someone will add postgres to properly handle the data...
I really like SvelteKit's way of helping you create a similar BFF with their endpoints system. I still have my "real" backends, but w/ SvelteKit endpoints I can even turn my BFFs into real APIs. And it's trivial to create an interface for getting/posting data from those BFF APIs, which I use for admin.
This looks like overengineering to me. The frontend cannot be <i>that</i> dumb. Every modern frontend technology out there can parse a bunch of JSON efficiently.<p>If for whatever reason you don't want to call a few REST endpoints to render some stuff, then you should probably replace those endpoints with some other technology.
Maybe this works out for some engineering organizations, but man am I glad not to work with this style of "backend" anymore. The folks at my last gig did this and never have I seen such a mess of services.<p>One particularly annoying pain point was that one of the engineering directors made it his personal mission to ensure that every service's Protobuf definition conformed to some platonic ideal. We'd have a BFF service Foo that essentially provides a wrapper around another service, Bar (among other things). Naturally, Foo's service definition included some Protobuf messages defined in Bar. Now the simple thing to do here would be to include those Protobuf message definitions in Foo.proto and expose them to consumers of the Foo service, but that apparently couples clients too tightly to Bar's service definition (?). So, it was decided that Foo's Protobuf file would contain actual copies of the messages defined in Bar. Adding a new field to a message in Bar wouldn't expose it to clients of Foo unless you also update the message definition in Foo.proto as well as the code that converts from Bar::SomeMessage to Foo:SomeMessage. Now imagine that the backend service is something commonly used, like UserService, and that there are potentially dozens of BFF services that contain copies of the definition of UserService::User. Welcome to hell.<p>The aforementioned engineering director would hunt down BFF services that dared to include a message dependency instead of copying the definition. He would then open a ticket and assign it to the service owner, informing them that they were not in compliance with the "Architectural Decision Record": the indisputable, no-exceptions, holy-of-holies log of technical mandates that were decided by a handful of people in a meeting three years ago.<p>This issue isn't necessarily inherent to BFF architecture, but I think it comes from the same place of overengineering and architectural astronautics.
I'm happy that the conclusion for this article starts with:<p>> You probably shouldn’t implement microservices.<p>Because the whole article just seems like making more problems on top of your existing problems.
My company uses this pattern extensively, just as indicated in the post. Frontend teams deliver their own backend-for-frontend and the backend teams just worry about their own microservices. Generally, it works out pretty well most of the time.<p>The big issue I've been seeing is that occasionally frontend teams will decide to develop "features" by stringing together massive series of calls to the backend to implement logic that a singular backend could do much more efficiently. For example, they commonly will have their backend-for-frontend attempt to query large lists of data, even walking through multiple pages, in order to deliver a summary that a backend service could implement in a SQL query. Unnecessary load on the backend service and on the DB to transmit all that data needlessly to the BFF.<p>I know the easy answer is to blame the frontend devs, but this pattern seems to almost encourage this sort of thing. Frontends try to skip involving the backend teams due to time constraints or just plain naivety, and suddenly the backend team wakes up one morning to find a massive increase in load on their systems triggering alerts, and the frontend team believes its not their fault. This just feels like an innate risk to promoting a frontend team to owning an individual service living in the data center.