R5.1 · Run the Dashboard BFF as a standalone service, not the shell's route handlers

Theme	R5 · Technology stack
Domain	Application and platform architecture
Status	Proposed
Needs client validation	Yes
Reinforces	R3.1 — the same boundary, expressed as a runtime selection
Anchored in	The ADS technology stack table · the experience map's runtime section · the options deck's single-BFF topology · assessment finding D-06
Open questions	Takes a position on 19; depends on 14
Deliverables	D2.1 · D3.1

Concern

Two client documents name two different runtimes for the same component, and the gap between them is a build against a promotion.

The ADS puts the BFF inside the web application. Its technology table lists the backend as "Next.js route handlers, Node.js — REST endpoints, server actions", and the new Dashboard Shell component is described as the BFF experience: serving the shell and MFEs, session lifecycle, CIAM and Unleash, delegating cross-domain calls.

The estate already runs one that is not that. The experience map documents di-dashboard-services — Fastify, registered in APIM DEV, already serving /api/v1/insurance, /api/v1/investments and /api/v1/wealth-investor, paired with the di-dashboard Next.js micro-frontend — as part of an estate that "already powers ~80% of the target UI." The options deck draws the same thing: its single-BFF topology is "di-dashboard-services, Fastify, behind APIM with Redis."

Open question 19 records the ambiguity as a validation item. What makes it a stack decision rather than a fact-finding one is that the two are not equivalent implementations of a component. They differ on what can call it, what can govern it, and what it fails and deploys with.

Recommendation

Make the standalone service the Dashboard BFF. The shell keeps route handlers for what belongs to the shell — the auth callback, session, feature-flag evaluation, its own rendering. Everything composed moves behind a registered API.

Four consequences follow, in order of weight.

It is an API the gateway can see. Route handlers inside the shell are not a registered APIM product; they are paths on a Next.js application. The fan-out to thirteen hard dependencies begins at this hop, which makes it the one that most needs a gateway in front of it — and the controls R4.1 argues the mediation layer must carry, rate limiting and quota among them, have nothing to attach to on the route-handler path.

It can be called by something that is not a browser.R3.1 reduces at the runtime level to exactly this: route handlers are reachable only through the Next.js application, so the 56.6% of authentications that are mobile arrive later as a second build rather than as a second caller.

Shell and aggregation fail separately and ship separately. Finding D-06 already calls the BFF an unmitigated single point of failure with no bulkheading between BU call paths. Sharing a process and a release train with the shell adds the shell's failure modes and the shell's cadence on top of that, and makes the options deck's first concern — "one bad BFF release breaks all six LOBs for all customers" — strictly worse, because the release surface now includes every front-end change.

It is the cheaper path. The service exists and is wired. The experience map lists six known gaps between DEV and PROD: two are ordinary promotion work (the PROD gateway URL, front-end Key Vault registrations), two are configuration debt (Unleash not wired into the BFF, Wealth Investor in DEV pointing at Wealth UAT), and two are identity — the stripped x-federated-id header and the unimplemented gb-core-authx exchange. Under R1.1's navigation-first scope, those two are not launch-path promotion work; they return when the portal aggregates protected BU data. The remaining four are a punch list, not a design.

What it changes

It turns open question 19 into a decision. It is currently filed as validation — is di-dashboard-services the ADS's Dashboard BFF, a predecessor or a parallel effort? — and the honest answer may be "a parallel effort". That does not make the question go away; it makes it a choice between two running things, and this page supplies the criterion.

It changes what WS 3 prices. A promotion with a six-item punch list and a build of a new aggregation tier are different line items with different risk. The roadmap cannot carry both.

It names one runtime in D2.1. The application and platform architecture section has to state a single answer here, and today the material supports two.

What we are not recommending

Dropping Next.js. It stays the shell — SSR, routing, the MFE host, the web session. The recommendation is about which process serves composed data, not about the framework.

Moving to per-LOB micro-BFFs now. The options deck's Conway's Law concern asks for a written sunset date or migration trigger for the single-BFF pattern, and that is open question 18's to settle. A standalone service makes that migration easier; it does not pre-empt it.

Rewriting di-dashboard-services. Fastify is a choice already made by a team already running it. Nothing in the material argues against it, and re-litigating a working runtime is how a promotion turns back into a build.

Dependencies and open questions

• Open question 19 — which component is the MVP's Dashboard BFF. This is a question for the delivery team, and it should be asked before the ADS is re-issued against the assessment's conditions.
• Open question 14 — the named owner for the shared runtime. A standalone service needs an owner, an on-call rotation and a release process more visibly than a route handler does, which is an argument for settling both together rather than a cost of this one.
• The six DEV-to-PROD gaps in the experience map, with dates. They are the promotion plan, and two of them are identity work this recommendation does not cover.