i work for big corporation running a large global ecommerce application

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

Did you have problems caching between BFF and backend apis?

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.

From a sales perspective (I was in a position to be tech-agnostic, due to coming in as a consultant), BE4FEs can be sold to the business on basis of: (A) decoupling and velocity; (B) flexibility and features; (C) performance and efficiency; and (D) security and confidentiality. (Also worth noting that API gateways are the more general case of BE4FEs, so similar arguments apply bidirectionally.)

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.

I have no FAANG experience but I’ll comment if that’s alright.

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.

This is great! The main questions I’m anticipating are “why cant we just improve the backend apis” and “why do we want the frontend team to own an Service?”

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.

This is very normal in banking industry. Our backend systems are running on mainframes so it's normal to have layer(s) of "midrange" to expose nice APIs on top of mainframe programs.

Have you searched internally to see if someone has already built a solution you can leverage? Can you provide more details about what exactly you're trying to solve?

Sure, basically we have a standard microservices architecture and sometimes the needs of the frontend team and backend teams aren't aligned. For example, searching UX or Pagination UX needs are classic examples where scalable apis use cursor pagination but frontend UX needs offset pagination. So in many cases frontend UIs make a huge number of api calls across a number of microservices to render a single view (classic graphql use case) and end up caching a view of the database in the browser to implement filtering.

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.

What's the difference between a backend team and a backend-for-frontend team?