| name | frontend-bff-boundary-review |
| description | Determines and reviews whether aggregation/shaping logic belongs in a Backend-for-Frontend layer versus client-side composition, and audits existing BFF boundaries for scope creep, duplicated aggregation logic, and leaked backend topology or pass-through authorization. |
| allowed-tools | Read Grep Glob |
| metadata | {"author":"github: Raishin","version":"0.1.0","updated":"2026-07-02","category":"architecture"} |
Frontend BFF Boundary Review
Purpose
Decide whether a multi-backend data need belongs in a Backend-for-Frontend (BFF) route or in client-side composition, and audit an existing BFF layer for the two failure modes that matter most: organic scope creep (duplicated or one-off aggregation logic scattered across routes) and trust-boundary erosion (a BFF that forwards client-supplied authorization claims or credentials without re-verifying them, or that leaks internal backend topology into its responses). This skill exists so the boundary decision and the trust-boundary audit stay the focus, and so field-level contract review of an already-scoped endpoint, or client-side cache/store design once data has landed in the browser, stay out of scope.
When to use
Use this skill when the user asks to:
- decide whether a feature needing data from multiple backend services should aggregate server-side (a BFF route) or client-side (parallel query-library calls),
- audit an existing BFF layer, or a specific BFF route, that has grown organically over time,
- review whether a proposed new BFF route or service duplicates an existing one's aggregation logic,
- check whether a BFF route re-authenticates/re-authorizes the caller or merely passes through client-supplied claims/tokens to backend services.
Do not use this skill for:
- reviewing the field-level shape, versioning, or authorization contract of a single already-scoped API endpoint — that is
api-integration-contract-review,
- client-side cache/store design (query-library cache keys, state colocation) once data has already been fetched — that is
state-management-decision-review,
- rendering-mode or
fetch() cache-directive selection for a Next.js route with no cross-service aggregation involved — that is nextjs-rendering-caching-review,
- Server Action authorization or
'use client'/'use server' boundary review with no BFF-scope question involved — that is nextjs-app-router-data-fetching-review.
Context7 Documentation Protocol
- Resolve
/vercel/next.js with resolve-library-id before citing any Route Handler capability, caching directive, or runtime behavior as grounds for a BFF-vs-client-composition recommendation.
- Before recommending a Next.js Route Handler as the BFF implementation vehicle, read the repo's
package.json to confirm the installed Next.js major version, then call query-docs scoped to that version for "Route Handler caching" and "route segment config revalidate fetchCache." Caching semantics changed materially across major versions — Route Handler GET methods are cached by default through Next.js 14 but are not cached by default starting in Next.js 15, requiring an explicit export const dynamic = 'force-static' to opt back in. A BFF route assumed to cache aggregated responses on an unverified version can silently hit every backend on every request instead of reducing round-trips as intended.
- If the version cannot be confirmed, or Context7 is unavailable, state the caching claim as
documentation-based, version-unconfirmed and recommend the user verify export const dynamic / export const revalidate / export const fetchCache behavior against their installed version before relying on it for load-reduction claims.
- Do not assume a Route Handler behaves like a
fetch() call inside a Server Component; segment-level config (dynamic, revalidate, fetchCache) governs the Route Handler's own caching, and it is set independently of caching used for calls the handler itself makes.
Lean operating rules
- A BFF is a trust boundary, not a convenience layer for reshaping JSON. The default posture for any BFF route is that it terminates the client's authentication context and establishes its own — it does not relay whatever the client sent forward.
- Default toward BFF aggregation when a feature needs data from two or more backend services with different authorization models or error shapes. Default toward client-side composition only when the backends involved are already safe to call directly from the browser (same trust level as the client, already CORS-exposed, no internal-only topology).
- Before proposing a new BFF route, search for an existing route already serving an overlapping need. A second BFF route re-implementing the same aggregation is a maintenance and drift risk, not a fresh feature.
- Treat any BFF route that reads a client-supplied authorization claim (a role, user ID, or permission flag taken from a request body, query string, or an unverified header) and uses it directly to gate a backend call as a HIGH-severity finding — this is pass-through authorization, not delegation.
- Treat any BFF route that forwards a client-supplied bearer token or credential straight to a downstream backend, in place of the BFF re-authenticating the session and minting its own downstream credential, as a HIGH-severity finding, unless the system is an explicit, documented token-exchange/delegation design (e.g. OAuth token exchange) with its own re-verification step.
- Treat any BFF response that exposes internal-only backend hostnames, service names, stack traces, or service-specific error codes/shapes verbatim to the browser as a MEDIUM-to-HIGH finding depending on sensitivity — the BFF exists in part to prevent this leak, and a thin pass-through response defeats that purpose.
- Do not recommend client-side composition when it would require the browser to hold credentials for, or make direct network calls to, a backend that is not already intended to be internet-reachable — that is a bigger security regression than the aggregation-placement question being asked.
- Do not flag every multi-call client-side data-fetching pattern as a problem. Client-side composition of two or three already-public, already-authorized endpoints is a legitimate, lower-latency choice; only escalate when trust boundaries or topology are actually crossed.
- Never execute, build, or run application code as part of this review; this is a static-review skill (Read/Grep/Glob only).
- Treat any hardcoded API key, service token, or credential found in BFF route source, environment file references, or example data as a HIGH-severity finding requiring immediate escalation, separate from the boundary-scope verdict.
References
Load these only when needed:
Response minimum
Return, at minimum:
- the boundary decision (BFF aggregation vs. client-side composition) with justification tied to the number of backends, their auth models, and their reachability from the browser,
- for any new/extended BFF route: an explicit scope statement and a check for an existing overlapping route,
- a trust-boundary audit result (pass-through-authorization check, credential-forwarding check, topology-leak check) for any BFF route in scope,
- ranked findings with file:line evidence, risk class, and fix,
- the Next.js major version the caching claims were verified against, if a Route Handler is the proposed implementation,
- verdict: approve / approve-with-notes / block,
- evidence level and open questions.
