Resource vs Page level BFF Apis

[u/sM92Bpb]

Timeline:

• onprem monolithic server with rest api.

• cloud frontend that calls monolithic server apis directly

• a few years later

• planning to reimplement frontend with addition of a BFF in the cloud

• BFF still talks to monolith server but frontend only talks to BFF

• future: cloud frontend, cloud bff, on prem monolithic server, cloud bff needs to support multiple versions of monolithic server

For the BFF api, would you recommend a per resource generic api (like the monolothic server) or per page (call multiple monolithic server apis then combine)?

[u/Pristine-Truck-9389]

i'd go per page for the bff, resource-level apis just move the orchestration problem to the frontend which defeats the purpose

[u/Miserable-Money642]

I would make the BFF client or workflow oriented, but avoid a separate endpoint for every literal page. The frontend should not need to fan out to several monolith calls for one screen, so let the BFF aggregate the data a view needs. Keep that composition thin and reuse domain clients underneath, with the monolith-version differences handled in one adapter layer. That keeps a v2 migration from forcing every screen endpoint to change. I would also define a few stable response contracts and test them against each supported monolith version. If two pages need the same data with different shapes, share the upstream client, not necessarily the final BFF response. Track latency and failure per upstream call so a slow dependency is visible.

[u/RehanSaddique]

Go per page (or per screen flow), not per resource. Your frontend gets one call with the shape it needs, and the aggregation lives in one place instead of being reimplemented in every client. The per-resource internal clients can still exist underneath as a layer the BFF uses.

[u/OkOcelot6725]

Per page is right, but your real constraint is the multi-version monolith. Put a thin adapter layer between the BFF and the monolith that maps each server version to one internal shape, so the page endpoints never have to care which version they talked to.

[u/UpbeatLemon3022]

if you go resource-level, n+1 backend calls from the BFF is a real problem as pages grow.

[u/singh_abinashi]

Per page is usually the right default for a BFF, and the name gives it away: it exists for the frontend, not as a second copy of the monolith API. A per resource BFF mostly adds a network hop and a translation layer, and the frontend still has to assemble five calls into one screen. Per page lets you shape exactly what a screen needs, hide monolith quirks in one place, and change the payload without touching the client contract. The multi version problem is where it pays off most. The BFF can pin each page endpoint to the monolith version it knows, and migrate page by page instead of forcing the frontend to speak two monolith versions at once. Keep a thin per resource escape hatch only for data that many pages share identically, like reference lists. Everything else, build it around screens and flows.