Backend-for-Frontends (BFFs) vs. Data layers
One of the most widely adopted solutions today is using backend-for-frontends (BFFs), where each frontend has its own backend service that transforms the underlying backend APIs tailored to the bespoke requirements of that frontend.
While BFFs solve the aforementioned three problems, as Lee Bryon pointed out more than 8 years ago (opens in a new tab), having one BFF per UI introduces its own set of new problems:
- Duplicating significant amounts of work because, while frontends differ in their needs, there are still many similarities between their transformations
- Creating product inconsistencies across different frontends because different BFFs will fix the same bugs and implement the same features at different times
- Making it difficult to create new frontends as that requires bootstrapping another BFF
- Requiring careful coordination of deployments between the client and the BFF as they are tightly coupled
Having one central data layer (instead of one per frontend) circumvents these problems, but the concern with that centralization was that it would “become bloated by handling multiple concerns.” (source (opens in a new tab))
That is where GraphQL comes into the picture.
GraphQL APIs enable clients to query for the exact data their UI needs. That means “becoming bloated by handling multiple concerns” is not an issue because GraphQL APIs don’t contain any specific frontend’s concerns.
Building a central data layer based on GraphQL is the best of all worlds: it solves the three problems at the interface between backend and frontend without the added challenges introduced by using BFFs.