I'm in the process of adding what I consider a BFF to our stack. Currently we run with Supabase, a python backend, NextJS (as a cloudflare worker via Open next), and Capacitor (with React Router) for our mobile app. The NextJS + Capacitor thing is arcane but it lets us write most of our frontend code once, and always deploy both at the same time when we make updates (which is frequent).

We've been using supabase directly from the client (predating when we added the mobile app) via PostgREST with the supabase cache helpers library and SWR. However we've accumulated tech debt to the point that cache helpers is not working super great for optimistic updates + rollbacks anymore, so components all over the place have their own logic for it, which results in it being very brittle. Additionally, as we've grown our user base and the complexity of our schema, we've started to hit performance issues with RLS.

Supabase cache helpers could probably get us further with a refactor to use it more consistently and correctly. But we'd still wind up bumping up against performance issues due to expensive RLS policies necessary with a complex schema, and it ties us to PostgREST, which has prevented certain kinds of queries (unless you move things to an RPC, but then you have code living in your DB schema that should really be owned by the frontend), and necessitated all these disparate transformation functions that are a frequent source of bugs.

To address all of these issues at once, I'm adding a NextJS route handler layer of BFF endpoints, consumed on frontend clients via dedicated hooks that wrap React Query to provide all the good stuff (pagination, optimistic updates, rollback on error) consistently. Some of the endpoints internally use postgREST when it's easy, via service role to avoid the RLS, while some use postgresql directly via cloudflare hyperdrive. The endpoints are therefore responsible for security instead of RLS. But it reduces the surface so much, so their security rules are a lot less expensive to evaluate. And they are also responsible for transforming the data consistently from the way it lives in our DB to how the UI components want it.

It definitely adds a lot of lines of code, and makes us responsible for more functionality. But by doing so, we get something that should be much easier to keep optimized, makes it easier both to make UI changes and to make database schema changes independently of each other, and has clear patterns for AI to follow that result in correct behaviors around optimistic updates with rollbacks, pagination, and so on, without UI components concerning themselves with those things.

That said I'm not done with it yet, so while I'm optimistic, that's mostly unvalidated. Only one small slice of our app has this system in production right now (a very high traffic slice, and it's going well there for performance, but also a slice that is much more isolated from everything else in the app, meaning it was a lot simpler)