BFF can live on a different stack from the heavier backend, and bear a different development cycle.

I've worked in a few orgs where backend devs work on both the standard backend and the BFF, often adjusting both when adding new features. It's just convenient to have a separate layer closer to the frontend, dedicated to it.

Indeed we see this even comes for free with some stacks like Next.js, in which you can define an api (BFF) to interface with the primary backend.

On the surface may sound weird but in practice has actually been pretty great when used mindfully.

I wish Next.js talked about this some more and beefed up their API routes.

Writing your BFF in the same codebase, sharing types, and parsing incoming data on the server without filling up the client bundle is a fab experience.

We use Remix in this way. Making calls to multiple endpoints on link prefetch is fantastic for speed

Nuxt3 will have this feature, they call it "nitro" and it uses the npm library called h3 (as opposed to expressjs) under the hood.

Author here. Yes, it's all about Conway's Law. Unfortunately, it's still a law that governs all companies. Fun fact: I stopped working in projects because I mostly had to find technical solutions to organizational issues.

PS: I wouldn't call it "political" (negatively connotated) but "organizational" (statement of fact)

'Organizational' is indeed a better way to describe it. Poor choice of words on my part.

I know where it comes from, don't worry :-)

Right. But you could avoid this whole BFF malarkey by having a team that owned and released the BE and FE themselves.

This is the purest end goal though, if you've got a large monolith or you directly consume a shared backend with a large number of teams, how do you get there? BFF is just one attempt to decouple with another layer of abstraction. Eventually you can strangle the problem on the backend.

CDC on that backend would be one way. You could stream the data out to the various teams who could then materialise a view of it within their application and then craft an API over that view.

How do you do that when you have multiple teams working on separate FEs, which all need to talk to the same BE?

You exploit Conway's Law by not having separate FE teams. I think this is called the Reverse Conway Manoeuvre if memory serves

It's not political that microservices owning well-defined slices of a pie can't cater to the frontend's every whim without creating a dependency spaghetti everywhere that you have cross-cutting concerns. It's just common sense.

If you're arguing that most microservice vs monolith decisions represent a political and not a technical decision, I'll grant you that.

I don't think it's necessarily bad. In fact it is quite an elegant solution to issues between frontend and backend teams. I just think it's a great example of Conway's law. Conway's law (IMO) was never a negative thing, merely an observation of the realities of software development.

Your post brings up an interesting angle which is that the frontend and backend people can have different expectations of what the backend should actually do (perhaps leading to dependency spaghetti). In this case, introducing a BFF can be a way to isolate that from the rest of the architecture.

Those well defined slices of pie you’re referring to are often exactly the political boundaries OP is referring to.

This is the degenerate form of Conways Law.

100%. A backend API can be used from multiple frontends. Just one from my experience working for an electricity provider, API from Desktop webapp, android mobile app, IOS mobile app all retail customer facing. Then from a Sales pipeline for new customers in a CRM app. From B2B customers (Electricians building new homes requesting connections) in a different web app.

Isn't the article suggesting that due to a different "front ends" (web app, mobile client, etc) there are different sets of requirements, which a backend should not deal with (for sake of simplicity and separation of concerns)?

The BFF layer seems like a natural next step, basically a code shim to abstract away the peculiarities of each FE platform from the (presumably) "pure" business logic / API platform of the BE.

Ideally you wouldn't have (or need) microservices! I'd rather deal with a monolithic rails app any day.

However, assuming you've got them, BFF means only one group has to get the following right:

* User authentication

* Web performance analytics

* A/B testing

* More difficult bits of HTTP (fast TLS, prefetch, streaming responses)

If you have microservices but no BFF, you're pretty much stuck with your page being substantially rendered via js. Maybe that's okay for some things? I sure don't like it.

>> I'd rather deal with a monolithic rails app any day.

if your app gets "bigger" this can work OK, but I've found they typically get "wider" and then any work on the monolith gets really painful and slow. My last two gigs have been at opposite ends of the spectrum and it's kind of a "pick your poison" situation.

Comparing alternatives, BFFs add reliability that an API Gateway pattern doesn't have. One choice is to shard the API Gateway, but then the distinction between BFF and Gateway becomes more philosophical.

You grossly over-simplify the problem though of when you're trying to consume part of a monolith without contributing to it. BFF can be a valid approach to making a break. We also have 4 back-end teams and a poor release process, so for net-new projects this pattern has given teams a lot of deployment flexibility. It's definitely not cost-free, but I'd argue it's far less political than your inferred recommendation of "change the organizational structure to have a 'real' backend team".

It is not purely political.

In the case of GraphQL Federation, the ”BFF” does solve the N+1 queries problem, which is an actual problem.

Conway's law is neither good nor bad, it's reality.

Edit: Which I see you agree about.