Does anyone have any experience successfully doing that at a large company or FAANG?
Would like to know what technologies you used and how you convinced your leadership about the idea.
we use Apollo Client to communicate with our bff layer, which is Express and Apollo Server. The graphql resolvers in turn grab data from underlying Java REST apis, which are not exposed to the outside internet.
Overall it's worked great for us. Graphql takes a lot of getting used to, but it frees our teams up to move fast on their own, especially vendor contractors. Negative is, our schema has gotten gargantuan and needs to be heavily refactored.
One really cool thing Apollo Server unlocks is caching, and also a great metrics dashboard
Also did bff in the past for a health care company using Go. Challenge there was natural latency hitting slow backend apis and transforming the data
We are trying to be able to have our FEEs write apis quickly while still having low operational load.
Also curious how you convinced leadership about your BFF idea? How did you convince them that its better than modifying the existing backend apis.
More specifically, useful arguments include:
- "Digital decoupling" reduces the number of potential blockers by allowing FEDs to develop against mocked or partial APIs, which allows customer-facing products and services to be more rapidly developed and deployed to market;
- BE4FEs decouple the external API structure from the internal systems view, which means you can design and create new and powerful customer experiences that don't directly mirror internal systems;
- They allow you to more effectively compose data from a variety of backoffice sources, and reduces the risk of backoffice upgrades, modernizations, and changes;
- They allow you to reduce the number of business stakeholders that need to be brought into the API and product discussion, since business logic can be implemented at a layer above the backoffice systems, which allows for more precisely-targeted features and scope and improved velocity;
- By managing caching and processing at the BE4FE layer, you can reduce backoffice system load and engineer your performance and cost requirements accordingly;
- Your BE4FE allows for granular, product- or service-specific security, confidentiality, redaction, and auditing approaches that may exceed or differ from those the backoffice systems implement;
- A properly-engineered BE4FE provides "ablative security" layers that protect backoffice systems from malformed requests, inadvertent or hostile overload, exfiltration or unintended disclosure of sensitive data, and so on.
A few potential talking points:
BFF pattern allows you to separate concerns, have different team topologies and development methodologies, and technical standards and values for different parts of the system. Leadership may appreciate your arguments if you can put them context of enabling teams to advance independently and have different priorities which could otherwise be in conflict. An example could be efficiency gains from fronted / client oriented teams not having to switch language to work on BFF if using node. Another could be testing standards / code coverage for platform APIs may be higher than necessary for more experimental client related work.
I think your point of focusing on how the requirements of the BFF team differ from the backend team could be a strong argument. Like the backend apis have to be low latency and consistent whereas the frontend apis can accept some higher api latency in exchange for lower page load speeds and eventual consistency via caching.
So I’m looking for perspectives on building a backend for frontend team implementing some APIs specifically for frontends that does the work of stitching together backend api calls from many microservices.