Serverless SSR: Architecture, Development, and Optimization for Frontend Rendering

Serverless has become hot recently, and many businesses have deployed Serverless cloud functions, achieving good results. The industry is continuously exploring more scenarios for Serverless.

For frontend developers, what does Serverless mean? For Node services, where can Serverless be applied?

Serverless + SSR = ?

Serverless cloud functions are an abstraction of computing resources that run on a cloud platform. Developers do not need to worry about underlying resource allocation, scaling, or deployment; the platform provides all services required for code execution.

SSR (Server‑Side Rendering) renders HTML on the server. Historically, PHP/JSP generated HTML, but with the rise of JavaScript isomorphism, frameworks like React and Vue now support rendering on the server.

Applying Serverless to SSR brings several advantages:

Cloud resources can theoretically scale infinitely, so the frontend does not need to consider the impact of traffic on SSR machines.

Frontend developers no longer need to manage SSR machine operations, reducing deployment and maintenance costs and improving development efficiency.

The Tencent NOW live IVWEB team is gradually migrating SSR workloads to Tencent Cloud Function platform, simplifying deployment and operations.

2. Evolution of Serverless

J, a frontend developer, faced problems when trying to deploy a direct‑output (SSR) service: machine provisioning, scaling, Nginx configuration, and fallback static pages.

He discovered a PPT about Serverless architecture evolution, illustrating the transition from IaaS (virtual‑machine based) to FaaS (cloud‑function based).

In the FaaS model, developers focus on business logic while the platform handles the underlying infrastructure.

FaaS + BaaS under Serverless

FaaS makes cloud deployment easy, but it does not solve the "common infrastructure services" problem (object storage, KV store, push notifications, etc.). These are provided by BaaS (Backend as a Service) from cloud providers.

Serverless literally means "no server" for developers; the platform abstracts server management.

In this architecture, functions handle business logic while BaaS services provide common capabilities.

3. SCF Cloud Function Development

J studied Tencent Cloud Function (SCF) and learned that functions are executed in an environment managed by the platform. The execution involves four elements: input parameters, context, side effects, and return value.

Input: HTTP request headers and body.

Context: request ID, environment variables, etc.

Side effects: calls to external services such as databases or object storage.

Return value: HTTP response, e.g., {"retcode":0,"msg":"ok"}.

After deployment, the platform provides a URL that triggers the function.

4. NGW Serverless Isomorphic Rendering Solution

When moving the direct‑output service to Serverless, J faced several gaps:

Original solution used TSW to run a Koa app, which listens on a port; Serverless functions are not port‑based.

Can the legacy service be migrated seamlessly?

How to package and publish functions within the existing CI pipeline?

How to debug functions locally?

How to map the function URL to the business domain?

Engineering Packaging

Beyond the usual frontend webpack bundle, the Serverless package must be zipped and uploaded to the function platform.

The CLI tool handles the zip creation, enabling command‑style deployment for CI integration.

Serverless Homogeneous Environment

Since TSW cannot run inside a function, J extracted needed components (ajax, monitor, logger) and re‑implemented global objects like window.REQUEST that the legacy code expects.

"Stream" vs "Block"

The original Koa app uses streaming I/O, while Serverless functions receive block‑style input. J built adapters that construct IncomingMessage and ServerResponse objects from the function’s input, pass them to app.callback() , and then convert the response back to the function’s return format.

NGW Gateway Forwarding

J introduced NGW (Node Gateway) to improve availability and simplify integration.

NGW provides fallback logic, gray‑release capabilities, and comprehensive link logging.

Local Debugging of Cloud Functions

Because functions are stateless, developers can locally construct input and context objects. J used a local Koa server to generate these objects, invoke the function, and view the rendered output.

Isomorphic Rendering Process

The final Serverless rendering flow consists of three steps:

Init: Initialize the function environment and process input.

Koa: Execute the React isomorphic business logic as a Koa app.

Clear: Clean up the environment and return the rendered result.

Performance Bottlenecks and Optimization

Load testing revealed a sharp drop in success rate under high concurrency due to cold starts. Cold start occurs when a new execution environment must be initialized; hot start reuses an existing environment.

Increasing the minimum number of instances reduced cold starts and improved throughput.

Memory limits also caused 4xx errors under load. Optimizing the Node memory model eliminated most of these errors.

Current Status and Next Steps

NGW + Serverless SSR is now used in multiple projects such as NOW live, WeChat Nearby, browser live, and group gifting. Deployment and operation workload for Node services has been reduced by over 80%.