BFF: How Aggregation, Cross-Cutting, and Rendering Are Layered

Abstract

Many people understand BFF simply as "adding an extra Node layer for interface forwarding." A more precise view is: a server-side pipeline oriented toward site pages—within the same process (or deployment unit), it first goes through static and module handling (different in development vs. production), then executes site-wide common rules, then enters a specific page to complete data aggregation and initial screen assembly, and finally the rendering template decides how to output HTML (including SSR, streaming, fallback on failure, etc.).

The diagram below breaks down three responsibilities: cross-cutting, aggregation, and rendering—their respective boundaries and the reasons for separation.

1. Why Split into Three Parts?

If not layered	Common consequences
Aggregation scattered across pages	Different request sets for initial screen and browser side; Cookie, authentication, gateway prefix tend to be inconsistent.
Cross-cutting embedded in every page	SSO, country path, multi‑site logic copied and pasted; high cost to change.
Rendering tightly coupled with business API	Changing templates or streaming plan involves the interface layer; templates hard to reuse.

Three division principles to remember:

Cross‑cutting: try to complete it before entering the specific page route.
Aggregation: complete it after determining which page it is, before writing out the HTML.
Rendering: focuses on how data enters the page and which fallback path to follow on error, reducing coupling to gateway details.

2. A Diagram for the Overall Flow

Edge and static layer: In development, Vite middlewareMode handles module graph, HMR, /@vite, etc.; in production, Nginx/CDN and build artifacts (e.g., dist) serve static resources, usually without running a Vite process to handle user requests. The diagram puts them in the same cell to indicate that "the request first touches a static layer" rather than implying Vite handles traffic online.

Static layer and middleware: both execute before entering the business page; middleware exists in both development and production, while the static layer implementation switches with the environment.

Handle and aggregation: the load increases after route matching; aggregation often includes anti‑corruption to reshape downstream data into a form convenient for rendering and serialization.

Rendering: follows the Handle, responsible for generating HTML and the way state is passed to the browser.

3. Cross‑cutting: Rules First, Then the Page

Before rendering a specific page, put the request into the correct site context: the clientId corresponding to the current Host, Cookie domain, whether through SSO or gateway proxy, whether the URL contains a country segment and the actual path for matching, whether to attempt remote full‑page rendering with fallback on failure, etc.

Benefit: Rules are centralized and executed consistently across the site; business pages do not need to reimplement them.
Cost: The team needs to understand the middleware chain through which the request passes; troubleshooting requires checking whether the path has been rewritten and context fields.

4. Aggregation: What Data Does This Page Need?

The content that needs to be displayed on the initial screen or the first part of a stream, and its sources, is the responsibility of aggregation. The difference from "simply providing a JSON gateway" is that the result often needs to be embedded in HTML (e.g., serialized global state), rather than just returning REST JSON.

4.1 Anti‑corruption Layer (Data Transformer)

Simply concatenating results from multiple interfaces is of limited value. A more critical step is to transform the downstream deeply nested, historically constrained naming, UI‑model‑inconsistent JSON into a structure directly bindable by components—that is, a Data Transformer; in domain‑driven design, this can be seen as an Anti‑Corruption Layer: the template faces the site's view model, not a literal mapping of backend fields.

Division suggestion: Fetching, retrying, parallelism are handled by the API wrapper; how the shape becomes a UI model is handled by the page or a shared transform, making it easier to test and reuse.

Request direction (to the gateway):

Response direction (back to BFF):

Common practice: pass the transformed object to the template, which uses a safe serialization method to write it globally (e.g., window.__SSR_RENDER_DATA__ or similar naming standardized by the project). The idea can be summarized as anti‑corruption first, then handover.

The fetch order, dependencies, and failure strategy are decided by the page or layout; connection methods and default caching should be pushed down to a unified HTTP client; field‑to‑UI‑model mapping resides in the anti‑corruption layer to avoid deep field penetration inside components.

5. Rendering: HTML, Stream, and Data Handover

This layer does two things: (1) convert aggregation results into HTML or a stream; (2) transfer state from the Node side to JavaScript in the browser in a stable and secure way, and complete hydration.

The division with BFF can be summarized as:

The BFF side focuses on how the request enters, context, and data sources; the template focuses on how data enters the DOM and the fallback path on error.

CSR, SSR, hybrid, streaming, etc. are product formats; by constraining the Handle lifecycle, rendering modes can be prevented from leaking into business code as many conditional branches.

5.1 Handover: Serialization and Hydration

After aggregation (including anti‑corruption), the data is typically a JavaScript object in memory. The browser bundle cannot hold a reference to the Node heap, so state must be passed via executable or uniformly parsible text on the initial screen—this is the handover in SSR context:

Serialization: In Node, transform the object into a string that can be embedded in a <script> tag (global name such as window.__INITIAL_STATE__ or a project‑agreed window.__SSR_RENDER_DATA__, standardized by convention).
Deserialization and Hydration: After the browser loads the bundle, it reads the same state, allowing the framework to align with the DOM already output by the server, avoiding a full page redraw or duplicate rendering.

Security: If the object contains user‑controlled fields, directly concatenating JSON.stringify without escaping into a script tag presents an XSS risk; use a safe serialization like serialize-javascript and agree on the fields allowed to enter the initial state.
Performance: The larger the inline state, the larger the HTML size and parsing cost; for large lists, truncate, paginate, or only pass identifiers on the initial screen and let the client fetch details later.

Anti‑corruption solves "whether the shape is correct"; handover solves "whether the state can cross the Node‑browser boundary safely and stably"—without both, SSR is most prone to issues in production.

6. Caching: Three Types to Consider

Type	Effect	Risk
Connection‑level default caching	Reduces downstream pressure, reduces repeated read latency	If cache keys for user‑related read paths are poorly designed, data may be mixed across users.
Per‑request TTL	Hot public data, adjustable per environment	Too long a TTL can make configuration changes invisible to users for too long.
Application‑level throttling / coalescing	Prevents cache stampede, coalesces concurrent requests	Different semantics from HTTP‑level caching; should not be mixed.

When cross‑cutting and aggregation overlap, caching strategies are most error‑prone. It is recommended to define in conventions: which paths should never be cached, which allow short TTL, to avoid relying entirely on default behavior.

7. Benefits and Costs

What you gain

Site‑wide cross‑cutting (auth, domain, path rules, etc.) is concentrated in the middleware, limiting the scope of changes in business pages;
Rendering format is decoupled from downstream gateways, allowing templates and interface versions to evolve independently;
The entry layer and presentation layer have clear responsibilities, facilitating division of labor, review, and layered testing.

What you pay

Increased complexity;
Some differences between development and production environments;
Requires supporting monitoring and logging.

8. Conclusion

Cross‑cutting moves site‑wide rules forward, reducing duplicate logic on the page side.
Aggregation summarizes downstream data within the page boundary and shapes it into a UI‑suitable form via anti‑corruption / Transformer.
Rendering lets the template manage HTML output and error fallback; the handover (safe serialization and hydration) determines whether state can enter the browser with controlled size and security boundaries.

0 Comments

Leave a Comment