5 Tools for Building Backends-for-Frontends (and When to Move to Federation)

In modern web and mobile application development, monolithic general-purpose backend APIs quickly grow too bulky and complex to deal with multiple ways to consume data on the frontend. Any band-aid solutions muddy the separation of concerns between the frontend and backend components, and make codebases less maintainable and scalable.

The Backends-for-Frontends (BFF) pattern solves this by giving each client experience its own API layer. But a well-designed BFF has many moving parts—service mesh, serverless infrastructure, auth, observability—and teams keep reinventing the wheel for each one.

The tooling around the BFF pattern has matured. Here's what teams reach for now—and where federation starts to make more sense.

WunderGraph started as one of the first open-source BFF frameworks. Teams used it to compose microservices, databases, and third-party APIs into a single client-facing layer. As those teams scaled—more services, more teams, more consumers—the BFF pattern started showing its limits. Coordinating changes across multiple BFF layers, with no shared schema governance, becomes expensive.

WunderGraph's product today is Cosmo , an open-source GraphQL Federation platform. Teams that outgrew their BFF layers use it to run a single federated graph across distributed services. SoundCloud pioneered the BFF pattern and now runs GraphQL Federation on Cosmo, cutting compute by 86% and improving one key query's latency by 45% (case study). Luxury Presence replaced its BFF layers with federation, shrinking code reviews from 3 PRs per feature to 1–2 and now shipping up to 40 times a day.

If you're at the stage where multiple BFF layers are solving the same cross-service composition problem, federation might be the cleaner model.

Istio is an open-source service mesh that makes managing, securing, and shaping all traffic and communication between your microservices – and adding observability, too – possible, without ever writing code for any of this – no matter how your distributed architecture is deployed.

In a microservices architecture, traffic can flow in two directions: north-south and east-west. North-south traffic refers to traffic that flows in and out of the cluster, such as traffic between the frontend and backend services. East-west traffic refers to traffic that flows between services within the cluster.

While API Gateways handle the north-south traffic between the backend cluster and the frontend client(s), abstracting away implementation detail, service meshes like Istio are built specifically for east-west traffic to give more manageable and secure communication between the services within a backend cluster.

1. Route and shape traffic between microservices, with added load balancing and service discovery. This means you can use Istio to implement A/B testing, canary releases, and other deployment strategies without requiring any changes to underlying microservices themselves.
2. Provide security, role-based access control, and encryption across backend services, ensuring that sensitive data is properly obfuscated and that the requests being made to any microservice within the cluster are from a valid source (authentication) and one that is allowed to make that request (authorization).
3. Add observability—distributed tracing, logging, and metrics across all components of a service, etc. As a service mesh, Istio is privy to all traffic within a cluster anyway, so using it for any and all logging needs is a no-brainer.
4. Make testing microservices in isolation easier. The distributed, interconnected nature of these systems makes it challenging to reproduce and diagnose issues. Istio intercepts ALL inter-service traffic by default, making it a great vector for injecting faults, delays, and other conditions into the communication between services to simulate different scenarios and test how the system responds.
5. Add resilience: If an individual downstream component (say, a database) called by multiple microservices goes down, it can bring all of them down in turn. If those fail, in turn, the API gateways that use them stop working properly, and this propagates up the chain. Also, if one of these downstream components is running slowly, the response time of the entire backend cluster is equal to the speed of the slowest downstream call. Service meshes like Istio fix that with:

• Automatic retries until the call succeeds,
• Implementing a circuit breaker pattern means that after a few failed retry attempts, we don't attempt that call again for a while and risk congestion.
• rate-limiting to ensure any of our microservices don't flood downstream calls.

Serverless computing is a cloud computing model in which you build and run applications without managing the underlying infrastructure. If you're using the multitude of services offered by Amazon's AWS, it handles server management, scaling, and maintenance so that you can focus on writing your application code.

Because of those benefits, serverless tech stacks for your BFF layer (like in AWS) can help you move fast, scale up and down according to demand, and, with pay-as-you-go, potentially be far more cost-effective than building and hosting your own on-prem server, making them ideal for rapid, iterative BFF development and a faster time to market.

Here's the TL;DR: Amazon API Gateway (routes requests from the frontend to the backend) + AWS Lambda (contains functions for your business logic, data transformations, or processing data from the backend) + DynamoDB (for storing data from downstream microservices).

The logical question now, of course, is how you collect data from your downstream microservices and put them into the DynamoDB layer to begin with. Here are some options:

1. Using Webhoooks: Downstream services will push updates to your Lambda functions using Webhooks (as HTTP requests). The AWS Lambda Function URLs makes this easy – you won't need any extraneous API Gateways. Your Lambdas can include the BFF logic. This way, there's no need for an event-driven architecture.
2. Using Event Consumers: But if an event-driven architecture makes more sense for your use case, and your microservices can actually publish events, use Amazon EventBridge to collect these pushed events and route them to Lambda functions according to a rule.
3. Using Polling: But what if your downstream services can neither make HTTP requests nor publish events? In that case, you'll need to poll them manually. An AWS service that makes sense here is the EventBridge Scheduler . With it, you can create cron jobs to manually trigger Lambda functions that poll the APIs of your downstream microservices for data.

What remains is auth and observability, and the AWS suite includes solutions for them, too – Identity and Access Management (IAM), Web Application Firewall (WAF), Cognito, Cloudwatch, etc. Overall, serverless technologies (and the AWS platform in particular) provides a range of services and tools that make it an ideal choice for developing BFFs.

If deploying and using AWS scares you a bit, check out SST , which provides TypeScript-first infrastructure-as-code for AWS serverless stacks.

The Backend-for-Frontend layer is ideal for handling auth, as negotiating authentication and authorization directly from the public frontend client (i.e. running in a browser) is risky. Auth solutions like Clerk and Auth.js make this easier:

1. They're incredibly easy to integrate into any tech stack, with single sign on (SSO) support from providers like Google, FB, GitHub
2. They're incredibly customizable, providing customizable interfaces for login, registration, and account management.

Clerk offers a simple, secure, regularly-audited, best-practices way to add authentication to your application with drop-in components and pages. It is purpose built for the JAMstack, supporting NextJS, Remix, RedwoodJS, Gatsby, React Native/Expo, with database integrations for Hasura, Supabase, Fauna, and Firebase.

Auth.js is an open-source authentication solution that was first developed for only Next.Js applications but now supports other frameworks like Svelte and SolidJS, with a staggering number of database integrations .

Both support a wide range of authentication methods, including email and password, social logins (such as Google and Facebook), single sign-on (SSO), and multi-factor authentication (MFA). Clerk provides customizable user interfaces for login, registration, and account management; Auth.js offers a flexible API for building custom authentication flows.

No matter which one you use, here's the workflow:

• Whenever the frontend needs to authenticate or authorize a user, it calls an endpoint on the BFF, let's say, "/api/auth”
• The BFF uses OpenID Connect (OIDC) or another method to authenticate the user, generating ID, access, and refresh tokens.
• Tokens are cached, and an encrypted cookie is issued to the frontend that represents the current session of this user.
• Whenever the frontend needs to access data from downstream services, it passes the encrypted cookie to the BFF, which extracts the access token from its cache and calls the downstream APIs or microservices, including that token in the authorization header.
• Downstream services return a response to the BFF, and the BFF forwards it to the frontend.

Clerk and Auth.js integrate into web applications via JavaScript APIs and React components. Clerk's drop-in UI handles most auth flows out of the box; Auth.js gives you lower-level hooks to wire authentication into your own backend APIs and services.

Adding observability to your BFF is important for understanding and troubleshooting issues in your application, and for making informed decisions on optimization and scaling.

You don't have to roll your own solution for this – use tools like Axiom, Grafana, and Datadog to identify + diagnose issues with your BFF, by tracking metrics such as response time, error rates, and resource usage, and receive alerts if any of these metrics exceed defined thresholds.

Axiom is a data management and analytics platform that enables organizations to gather, manage, and analyze large volumes of data from various sources. The platform is designed to provide users with a comprehensive view of their data, allowing them to make better-informed business decisions.

Grafana is an open-source analytics and visualization platform that allows you to monitor and analyze data from various sources, including databases, cloud services, and IoT devices. Grafana can help you create interactive, real-time dashboards and alerts for your applications and infrastructure.

Datadog is a cloud-based monitoring and analytics platform that provides visibility into the performance of applications, infrastructure, and logs. The platform is designed to collect, process, and analyze large volumes of data in real-time, and provides insights and visualizations to help users troubleshoot issues, optimize performance, and improve overall efficiency.

These services visualize collected data for you, setting up dashboards to monitor metrics in real-time, and letting you quickly identify concerning trends.

💡They integrate with serverless and cloud platforms like AWS and Azure, if your BFF is using serverless tech, as mentioned before.

Surprised? Don't be! These are primarily frameworks for fullstack development, yes, but they can also be used as BFF's by definition.

How? These frameworks provide the necessary infrastructure and features to create a dedicated backend application (this is usually a NodeJS layer) per frontend, tightly coupled with it, managed by the frontend team itself, and deployed together with the frontend – aka, the ideal definition of a BFF.

For NextJS this takes the form of API routes , and for Remix, it's the Loader pattern . Both can serve as great choices for a BFF layer if your project or app already has a mature backend coded in PHP, Ruby, Elixir, etc. (i.e., anything not JavaScript).

These tools handle the individual pain points. For how to structure the BFF layer itself—one BFF per experience, consistent error handling, TypeScript contracts—see 5 Best Practices for Backends-for-Frontends.