Greenfield BFF vs retrofitting later: where the asymmetry actually is

Decision. “Add the BFF later” is a real option, not a one-way door — provided the SPA is built so the token never escapes one module. The retrofit is ~2–5 days of mostly-deleting work: the API keeps its JwtBearer scheme unchanged because the BFF forwards a bearer token to it [2][3], and the SPA-side change is one HTTP-client module plus a login link [5]. The genuine one-way doors are elsewhere: API endpoints that only ever spoke cookie (BFF-local endpoints) [4], SignalR/WebSockets through the BFF [14], and access-token claims read in component code [22]. Build the SPA now; keep the door open with the checklist below.

First: two different things are called “BFF”

The reversibility answer flips depending on which one you mean.

The admin-console question is almost entirely the first flavour. Most of the internet’s BFF-regret literature is about the second [13]. Don’t import that regret into this decision.

What actually changes when a BFF arrives

Sorted by what it costs you at retrofit time, not by how scary it sounds.

Score

• Throwaway (and you want to throw it away): OIDC JS library, silent renew, callback routes, token storage, CORS config, download blob hacks. Deleting these is the retrofit’s dividend, not its cost.
• Mechanical: IdP client toggle, fetch wrapper (credentials + X-CSRF), 401 branch, /bff/user hook, relative base URLs. Hours, not days — if centralised.
• Genuinely painful: SignalR/WebSockets through the proxy; any real-time or long-lived connection. Plus the operational build-out (extra deployable, shared key ring, session store) — which you pay whenever you adopt, so it is not an asymmetry at all.

Where the “it’s just one module” claim breaks

The optimistic claim — it’s one HTTP-client file plus one ASP.NET auth block — is true for a disciplined codebase and false for a typical one. It breaks precisely here:

1. jwtDecode(token) in components. Roles/tenant/name pulled off the decoded access token for UI gating. Post-BFF the token doesn’t exist in the browser. Every one of those call sites is a rewrite against /bff/user [24]. This is the #1 blast-radius multiplier.
2. getAccessToken() reachable from app state. Once the token is in a Zustand/Redux store or a React context, arbitrary code reads it. Every reader is a call site.
3. Ad-hoc fetch(url, {headers: {Authorization: ...}}) outside the wrapper — typically in a “quick” file-upload or export feature.
4. Absolute API URLs compiled into feature modules instead of a single base.
5. Browser → third-party API calls using the same token (or a different one). The BFF can’t proxy what it doesn’t know about; these need their own decision.
6. Tests that mint a fake JWT and stuff it into localStorage. Under a BFF, the auth fixture is a cookie/session — MSW handlers and E2E login helpers get rewritten.
7. Real-time: see SignalR above.

Everything on that list is avoidable by construction, for free, today. That is the whole game.

The reverse door: what a BFF costs you if you later don’t want it

Symmetry check — is the BFF itself a one-way door?

• Removing it is easy if you kept it a pure security proxy: the API still validates bearer JWTs [2], so a browser SPA could go back to talking to it directly. You’d re-add CORS and an OIDC JS library. Same 2–5 days, mirrored.
• Removing it becomes hard the moment you use local/embedded BFF endpoints, which are cookie-authenticated and are explicitly aimed at “single-consumer scenarios” [4]. Logic that lands there is logic no other client can reach. That is where the API-shaping BFF’s one-way door quietly opens.
• A second client (mobile/CLI/service) does not force you off the BFF — it forces the API to stay bearer-capable, which it already is under proxy mode. If you ever need one API surface serving both cookie-bearing browsers and bearer-token clients, ASP.NET Core supports listing multiple schemes and trying each in order [16]. Duende BFF v4 also collapses the “one BFF per SPA” sprawl into one host with many frontends [19].
• The standing cost you can’t refund: one more service to deploy, scale, monitor and patch; an extra network hop; a shared Data Protection key ring; a session store [12][8]. For a Duende BFF specifically, a licence — free under $1M revenue, paid above [18].

Community opinion (dev.to, summarising 2024–25 Reddit/HN threads): “If you’re a startup, skip it. If you’re at scale, it’s worth it.” / “We ended up with four different backends — the maintenance is painful.” [13] — note both quotes are about the API-shaping flavour, not the token handler.

The traps that make the retrofit feel expensive

All three fail silently, which is why teams remember the migration as painful:

• UseBff() placed after UseAuthorization() → anti-forgery enforcement is silently disabled, no error [7].
• A typo in a YARP metadata key → no token attached, no anti-forgery check, no warning [7].
• Enough roles/claims → the auth cookie blows past the browser’s 4 KB limit and chunking papers over it until it doesn’t [9]. Fix: server-side sessions, so the cookie carries only a session id [8].

Keep-the-door-open checklist (the actual deliverable)

Build the pure SPA now. Do these ten things and the later BFF retrofit is a 2–5 day, one-PR change instead of a rewrite. Every item is free — most are just good practice anyway.

1. One auth module. src/auth/ is the only directory that knows the word “token”. Nothing imports it except the HTTP client.
2. Never put the access token in app state. No Redux/Zustand/context slot for it. In-memory closure inside the auth module only.
3. No jwtDecode outside the auth module. Expose a typed useCurrentUser() returning { name, roles, … }. Its implementation decodes the ID token today; tomorrow it fetches /bff/user. Consumers never notice. Add an ESLint no-restricted-imports rule on jwt-decode.
4. You own the fetch wrapper. One apiClient file. TanStack Query calls it; components never call fetch directly. This is the file that swaps Authorization for credentials: 'include' + X-CSRF: 1 [2].
5. Relative API paths. Always /api/.... Use the Vite dev proxy for local dev [17] — which is also exactly how you’ll run the BFF locally later.
6. Keep the API bearer-only and client-agnostic. No cookie auth, no session, no CORS-origin assumptions leaking into handlers. The API must never learn that a browser is talking to it.
7. Handle 401 centrally, in the wrapper, as “session gone → go to login”. Don’t distinguish “token expired” in feature code.
8. Deploy the SPA and API same-site from day one (app.example.com / api.example.com, or better example.com + example.com/api). Cross-site is now a dead end for cookies [25]; getting the origins right up front is free and removes the only genuinely structural retrofit blocker.
9. Test fixtures go through the auth module too. One loginAs(role) helper for E2E, one MSW auth handler. Don’t hand-mint JWTs into localStorage across 40 spec files.
10. Decide about real-time now. If SignalR is on the roadmap, that’s the one item that a BFF makes materially harder [14] — either plan a direct-to-API bearer channel for it, or price the workaround in.

Effort, in numbers a lead can act on

The asymmetry is therefore not between greenfield and retrofit — it’s between a disciplined SPA and a leaky one. The BFF decision is a two-way door [20]; the discipline decision is the one that’s hard to reverse.