4 ms·

This pattern is essentially what technologies like GraphQL or Falcor make super easy. My GraphQL server talks to a bunch of microservices and presents a simple

This pattern is essentially what technologies like GraphQL or Falcor make super easy. My GraphQL server talks to a bunch of microservices and presents a simple clean API for my web application, largely freeing the front-end from years worth of bloated APIs.

zappo2938 11y ago
This was my first thought also. They invented a name for the pattern but it is just a facade with the development responsibilities delegated to the front end team. Nothing ground breaking. This is probably more of a communication solution between front end and back end developers. The concept is very similar to GraphQL and Falcor. There isn't a benefit BFF gets with multiple end points over a single end point interface. I was trying to explain what Falcor was to a friend a couple weeks ago. It's a facade pattern and a correct use case for javascript and its asynchronous nature that has the added benefit of also being the language Facebook and Netflix frontend developers are using when they use React. Outside of the interface on the backend they are not using javascript but rather Python, Java, and in the case of Facebook, PHP, yuk. The point here is that even where the frontend interfaces with the backend it is still in the frontend's domain. The word, phrase, that came to mind, although I rarely use it, was clearing house. This pattern of managing transactions already exists in the business world -- the software used in clearing houses might already reflect this, that would be curious. It makes sense and there are similarities including error checking between a financial clearing house and these APIs. A clearing API might be an appropriate name.
herval 11y ago
These sorts of overarching architectures always leave me scratching my head too. IMHO a combination of a graph layer (eg the two you mentioned) and an scs architecture (scs-architecture.org) allow teams to remain largely independent and productive. That might sound superficially similar to "BFFs" as in "each team owns the client + api", but shifts the responsibility for larger units of work and away from individual microservices (which becomes a huge pain when you start to have dozens of BFFs interfacing with hundreds of microservices maintained by independent teams).
bsaul 11y ago
I don't think having a single entry point aggregating micro-services to provide a unified API for all your front-ends is what this pattern is about. Actually pretty much the opposite, but maybe i'm missing something...
- kapad 11y ago
  It isn't really a unified API for all front ends, but a separate API for each front end. And sometimes that really makes sense.

zappo2938 11y ago

This was my first thought also. They invented a name for the pattern but it is just a facade with the development responsibilities delegated to the front end team. Nothing ground breaking. This is probably more of a communication solution between front end and back end developers. The concept is very similar to GraphQL and Falcor. There isn't a benefit BFF gets with multiple end points over a single end point interface. I was trying to explain what Falcor was to a friend a couple weeks ago. It's a facade pattern and a correct use case for javascript and its asynchronous nature that has the added benefit of also being the language Facebook and Netflix frontend developers are using when they use React. Outside of the interface on the backend they are not using javascript but rather Python, Java, and in the case of Facebook, PHP, yuk. The point here is that even where the frontend interfaces with the backend it is still in the frontend's domain. The word, phrase, that came to mind, although I rarely use it, was clearing house. This pattern of managing transactions already exists in the business world -- the software used in clearing houses might already reflect this, that would be curious. It makes sense and there are similarities including error checking between a financial clearing house and these APIs. A clearing API might be an appropriate name.

herval 11y ago

These sorts of overarching architectures always leave me scratching my head too. IMHO a combination of a graph layer (eg the two you mentioned) and an scs architecture (scs-architecture.org) allow teams to remain largely independent and productive. That might sound superficially similar to "BFFs" as in "each team owns the client + api", but shifts the responsibility for larger units of work and away from individual microservices (which becomes a huge pain when you start to have dozens of BFFs interfacing with hundreds of microservices maintained by independent teams).

bsaul 11y ago

I don't think having a single entry point aggregating micro-services to provide a unified API for all your front-ends is what this pattern is about. Actually pretty much the opposite, but maybe i'm missing something...

kapad 11y ago
It isn't really a unified API for all front ends, but a separate API for each front end. And sometimes that really makes sense.