BFF Still Earns Its Keep in 2025 — It Was Never a Trend

· 5 min read

Every so often someone asks whether the BFF is on its way out, now that front-end frameworks can run loaders on the server and talk straight to a database. My view runs the other way. A Backend for Frontend was never a buzzword tied to one generation of tooling. It answers a structural question: how do you feed one backend to clients whose needs have nothing in common? Stronger frameworks have not made that question go away. They have just wrapped it in convenience, which is a different thing from solving it.

One backend cannot satisfy four front ends

You rarely ship a single front end. The public web wants SEO, speed, and a trim payload. The admin console wants the same record spread out in full, with audit fields bolted on. A game lobby wants low latency, a fixed shape, and something that rides a long-lived push connection. Mobile, mindful of bandwidth and battery, wants one request that bundles up everything the screen needs so it isn’t chattering back and forth. Four clients, one downstream, four genuinely different shapes.

Without a BFF, where does that aggregating and trimming end up? Two places, neither pleasant. One, it gets shoved back into the downstream service, which starts growing endpoints like getUserForLobby and getUserForAdmin — the backend held hostage by a front end’s display needs. Two, it gets pushed into each client, so every one of them calls three or four downstreams, stitches the result together, handles the failures, and reimplements the same aggregation in web, mobile, and admin, each copy slowly drifting from the others. A BFF takes that work and gives it a clear owner: it faces the backend on behalf of one class of front end, and that front end talks only to it.

This is not quite the same job as an API gateway. A gateway is a shared inbound pipe — auth, rate limiting, routing — and it tries to treat everyone the same. A BFF takes a side. It exists for one kind of client, and that client gets to decide what shape the responses should be. You can run both, but don’t cram a BFF’s trimming duties into a gateway meant to serve all comers. That gateway ends up the big ball of mud nobody dares touch.

So why not put it all in the framework’s layout or loader

This is the easiest trap to fall into in 2025. Today’s meta-frameworks let you fetch data right inside a route’s server segment, and it feels lovely — lovely enough that you’ll want to write the aggregation, the external API calls, and the secrets in there too. The trouble is that the boundary smears.

One setup I’ve run in anger was Nuxt with Nitro, where the server routes doubled as the SSR data source and the BFF gateway. The discipline that mattered: external requests never touch the data layer directly. When a page needs data, it goes through a Nitro server route, and that layer is what reaches downstream, adds the auth, and decides the response shape. The page components only ever receive something already trimmed. The moment you let a loader fetch a third party directly, carrying an API key, that line snaps — and the three things below all get harder at once.

First, security. Downstream addresses, internal auth, third-party keys — once any of that lives inside code that can be bundled into the client, you’re betting on whether the build tool drew the line cleanly. Lock them behind a server-side BFF and the client doesn’t even know those endpoints exist. That’s security by structure, not security by reminding everyone to be careful. Lean on structure, not on people’s discipline.

Second, versioning. The shape a front end wants will change — the lobby wants one more field today, the admin wants two lists merged tomorrow. If each front end assembles that shape against the downstream itself, every change means touching the downstream and coordinating with another team. With a BFF, when the shape changes you change the BFF and leave the downstream alone. The layer becomes a buffer: the downstream evolves at its own pace, and the display shapes get absorbed in the BFF. Downstream and front-end versioning come apart and move independently.

Third, observability. When every outbound request funnels through one layer, the whole call chain is in view. Which downstream is slow, which third party is throwing errors, how many external calls a single render actually fired — log it, trace it, and meter it at the BFF, and it reads at a glance. Scatter the aggregation across each front end’s loader and you’ll be piecing together which downstreams one request touched from half a dozen places. Logs and traces are written for the next person who has to debug this. Keep them in one layer and that person loses a few less nights of sleep.

Pulling it together

A BFF is not an extra service you stand up to look fashionable. It answers a question that has always been there: who faces the browser, who faces the backend, and who keeps the risk out at the edge. Hand those three things to one clear-cut layer and the front end only does display, the downstream only minds its own domain, and the risk sits in the middle where it can be watched. Frameworks make it possible to blend all of this together. That doesn’t make it advisable. A green build has never once meant a sound design.

Key takeaways

  • A BFF solves a structural problem: one backend feeding clients of wildly different shapes needs a clear owner for aggregation and trimming.
  • Don’t push aggregation back into the downstream (endpoints held hostage) or into the front end (logic duplicated and drifting) — that relocates the problem instead of solving it.
  • Meta-framework loaders are convenient, but external requests shouldn’t touch the data layer directly, or security, versioning, and observability all smear together.
  • A BFF buys three things: secrets and downstreams hidden on the server, front-end shape changes contained to the BFF, and the whole call chain observed in one place.
  • A green build is not a sound design; a BFF’s worth is drawing a clean line around who faces whom and who carries the risk.

Sheng’s take, drafted with Claude · part of the 2026-06-13 blog renovation, paint still drying.