Unified Access for Multiple Rendering Methods: Design Philosophy of a BFF Page Architecture

In complex business scenarios, page rendering has long ceased to be a simple choice between SSR and CSR. It has become a systemic design issue concerning experience, stability, and engineering governance. This article aims to discuss not a specific rendering technique, but how to integrate multiple rendering methods into a single BFF page platform, allowing them to be accessed in a unified manner while remaining available even in the event of failure.

I. Introduction: When Rendering Solutions Are No Longer a Binary Choice

If you only look at the technical jargon, front-end rendering solutions seem to be a simple multiple-choice question: should the page use SSR or CSR?

However, anyone who has worked on complex business applications will soon realize this question is incomplete. In a production environment, teams never face a single "most advanced rendering technology"; instead, they face a set of goals that must be achieved simultaneously and often constrain each other:

Faster first-screen experience
Better SEO performance
Higher online stability
Lower onboarding and maintenance costs

Therefore, the question worth discussing quickly evolves into a more engineering-oriented formulation:

Can we avoid binding pages to a single rendering mode, and instead let the system choose based on the scenario, switch on failure, and access in a unified manner?

This is precisely the question this BFF page architecture aims to answer.

Its focus is not on "making SSR perfect" nor on "letting CSR cover everything", but on abstracting page rendering into a set of system capabilities that can be uniformly accessed, switched on demand, and recovered upon failure.

In other words, this article is not about a particular rendering technique, but about a page organization method more suitable for complex business scenarios.

II. Three Core Contradictions in Complex Businesses

1. The Contradiction Between Page Experience and System Stability

SSR has obvious advantages: fast first screen, SEO-friendly, and content reaches users earlier.

But SSR also has inherent costs. If any link in the server-side rendering chain goes wrong—such as API timeout, data anomalies, or module execution failure—the entire page may become unusable directly.

CSR, on the other hand, is the opposite. It is less dependent on the server and more stable, but first-screen performance and SEO often suffer.

The real challenge has never been understanding the differences between the two, but rather how to make them work together in the same system instead of replacing each other.

2. The Contradiction Between Business Diversity and Technical Consistency

Different pages have different requirements.

Some pages place a high priority on SEO.
Some pages have complex interactions and are better suited for client-side driving.
Some pages require high availability and would rather degrade gracefully than throw errors directly.
Some pages are more static and better suited for pre-rendering or static generation.

If each type of page maintains its own access method, the system will quickly become fragmented. Developer experience will decline, maintenance costs will rise, and it will be difficult for the team to form a unified engineering standard.

3. The Contradiction Between the Success Path and the Failure Path

Many systems only focus on the "normal successful rendering" path during design. However, what truly determines the lower bound of the online experience is often how the system reacts when failure occurs.

A mature page platform should not only describe "how to succeed" but also define "how to continue serving after failure."

These three contradictions combined lead to one conclusion: if page rendering is still understood as a single-point technology choice, the system will quickly be reshaped by business complexity.

III. Core Idea: Unified Access, Not Unified Rendering

The core idea of this architecture can be summarized in one sentence:

What is unified is the page access method, not the page rendering method.

That is, the platform does not require all pages to use SSR or CSR. Instead, it provides a unified page organization method and converges different rendering modes into platform capabilities.

This approach has two direct benefits:

Business pages only need to declare their requirements, without repeatedly building the underlying rendering flow.
The platform can uniformly manage routing, templates, exception handling, rendering switching, and degradation logic.

In other words, the page itself focuses on "who I am and what I want to display", while the platform focuses on "how I should be rendered and how to catch failures."

This is also why, when understanding this architecture, it's best not to stare at specific frameworks and code details first, but to grasp its organization method.

IV. Architecture Overview: Three-Layer Division and Request Flow

For ease of understanding, we can ignore the specific package structure in engineering and abstract it into three layers:

Page Layer

The page layer is responsible for describing the page itself, including page configuration, routing information, page entry point, and which rendering template to choose.

This layer answers the question: In what way does this page want to be delivered?

Runtime Layer

The runtime layer is responsible for handling the actual rendering flow, such as processing incoming requests, template execution, server-side rendering, client-side takeover, and error recovery logic.

This layer answers the question: How does the system deliver the page to the user safely and stably?

Business Capability Layer

The business capability layer carries APIs, shared components, business hooks, and common logic.

This layer answers the question: What business capabilities are needed when rendering the page?

Once these three layers are separated, a page is no longer "some isolated code" but a standardized unit within the platform.

Once this layered approach is understood, looking back at how requests flow makes the entire system much clearer.

How a Request Flows Through the System

If we view a page visit as an assembly line, the overall process is roughly as follows:

In this flow, there are two points worth noting.

First, the page is not "hardcoded for rendering" directly; it first goes through template selection, then enters the corresponding flow.

Second, the rendering result is not limited to success. The system explicitly checks whether SSR is successful and enters a pre-designed recovery path upon failure.

This means that failure is no longer an exception outside the system, but a manageable part within the system.

To achieve this, process orchestration alone is insufficient; a more critical abstraction layer is needed to accommodate different rendering modes—this is where templating comes in.

V. Templating: Why It's the Fulcrum of This System

Many teams, when building a page system, tend to hardcode rendering logic within specific business code. In the short term, this allows for fast development; but as the number of pages grows, maintenance costs quickly escalate.

The significance of templating is that it extracts the "rendering mode" from business code, making it a configurable, reusable, and replaceable platform capability.

In this architecture, different pages can use different templates, such as:

Pure SSR
Pure CSR
Static generation
Mixed SSR and CSR mode

The value of this is not just "supporting more modes", but making the page's rendering method an engineering decision rather than a historical burden.

When a team needs to adjust the rendering strategy for a certain type of page, the focus shifts from "rewriting a set of page logic" to "switching or extending a template capability."

Among all template capabilities, the one that best represents the system's character is not a particular rendering mode, but the way it handles failure.

VI. Automatic Degradation from SSR to CSR on Failure: More than a Fallback, It's an Architectural Capability

If I were to choose one feature to represent the design philosophy of this architecture, it would be "automatic degradation from SSR to CSR on failure."

Because it perfectly embodies mature engineering judgment:

The user may not necessarily get the most ideal page, but the system must do its best to ensure the user gets a usable page.

This can be understood on two levels.

The first level is the normal path.

When server-side rendering completes successfully, the user receives the complete HTML. The first screen is faster and SEO-friendly. Subsequently, the client takes over the page and mounts interactive capabilities.

The second level is the error path.

Once an exception occurs during SSR—such as data fetch failure or rendering error—the system does not expose the error directly to the user. Instead, it switches to the CSR version and continues delivering the page.

This process can be understood through the following sequence diagram:

This design may seem like just an additional fallback path, but it has a profound impact on the system's character.

It transforms the page platform from "performs well when successful" to "remains as usable as possible when it fails."

This is also why I prefer to understand this capability as an architectural capability, rather than a "convenient fallback strategy."

Why Is It Considered an Architectural Capability

Many people, upon first seeing "degrade to CSR after SSR failure", might think it's just an error fallback strategy.

But from a platform perspective, it goes far beyond a simple fallback.

It Unifies the Success and Failure Paths

In many systems, exception handling is often an afterthought, scattered across business code. Here, failure handling is integrated into the unified rendering flow, becoming a standard platform capability.

This means that pages do not need to invent their own error recovery logic, and the system can more easily form consistent behavior.

It Moves "High Availability" from an Operational Goal into the Frontend Architecture Layer

In the past, high availability was mainly discussed at the level of service deployment, disaster recovery, or API governance. But page rendering itself is part of the user experience, and it should also have degradation, switching, and recovery capabilities.

From this perspective, this BFF page architecture is not just a frontend engineering solution; it's more like bringing the idea of high availability into the page delivery pipeline.

It Makes Architecture Evolution More Flexible

When a team wants to try a new rendering mode, they don't need to overthrow the existing system. As long as the template mechanism and runtime mechanism are stable, new capabilities can be extended on top of them.

This extensibility comes from treating "multiple modes coexisting" as the norm from the very beginning, rather than an exception.

VII. Why BFF Is the Most Suitable Hosting Position, and Applicable Scenarios

One natural advantage of BFF is that it sits right between "user requests" and "business services."

It understands both the page routing and delivery methods, and it can coordinate data fetching, rendering context, middleware capabilities, and error handling flows.

Therefore, placing the unified access of multiple rendering methods at the BFF layer brings several direct benefits:

More suitable for uniformly handling page entry, context, and routing.
More suitable for connecting server-side data fetching and page rendering flows.
More suitable for consolidating exception recovery logic into platform capabilities.
More suitable for decoupling business pages from underlying rendering mechanisms.

If traditional page development is more like "directly writing pages", this approach is more like "operating a page platform."

And whether a page platform is worth building ultimately depends on the scenario itself.

What Scenarios Are Most Suitable for This Architecture?

Not all projects need such a system, but in the following scenarios, it will be very valuable:

There are many pages, and different pages have different requirements for rendering methods.
The business simultaneously cares about SEO, first-screen experience, and online stability.
The team wants to unify page access standards instead of maintaining separate solutions.
There is a need to incorporate failure recovery as a formal architectural capability rather than a temporary patch.

Conversely, if the project is very small, the page types are homogeneous, and there are no requirements for SEO or server-side rendering, this system might be overkill.

Whether an architecture is reasonable does not depend on how advanced it is, but on whether it matches the scale of the problem.

VIII. Conclusion: Rendering Methods Are Ultimately a System Organization Problem

At this point, we can compress the thinking behind this system into a few judgments:

A page platform should not support only one rendering mode; it should support multiple modes with unified access.
Architecture design should not only cover the success path but also explicitly design the failure path.
Business pages should not directly couple with underlying rendering details; they should be built on top of platform capabilities.
The goal of a page system is not just to "render it out", but to "render it out stably, scalably, and governably."

These judgments together constitute the truly valuable part of this BFF page architecture.

If we bring back the question from the beginning of the article, we can now give a more complete answer.

Often, we treat SSR, CSR, SSG, and other terms as technology selection problems. But when the number of pages increases, business complexity rises, and stability requirements grow, you will find that they are first and foremost not about "which to choose", but about "how to be organized."

What truly matters is not which rendering mode you ultimately choose, but whether you have the ability to incorporate different rendering modes into a single platform, allowing pages to be accessed in a unified manner and remain available even in failure.

From this perspective, "unified access for multiple rendering methods" is not a technique, nor a temporary engineering optimization. It is more like a page system design philosophy:

It acknowledges differences and allows multiple modes to coexist.

It faces failure squarely and incorporates recovery capabilities into the main flow.

Its pursuit is not local optimization, but the stability, resilience, and governability of the entire page delivery system.

And BFF is a very suitable position to host this design philosophy.

If you only understand it as a set of SSR solutions, you may underestimate its value. If you understand it as an organization method for a page platform, many design choices become natural. Unified access for multiple rendering methods is essentially about establishing order in the page system, not just adding a few more rendering methods to the page.

0 Comments

Leave a Comment