How Bilibili Evolved Its Frontend: From MVC to Vue SSR and Scalable Architecture

Background

At the end of 2017 Bilibili reviewed its front‑end development path. The original workflow followed a backend‑centric MVC model where front‑end and back‑end coordinated via pre‑agreed APIs, leading to increased workload and high communication and integration costs.

Front‑End/Back‑End Separation

To reduce the tight coupling, Bilibili adopted a front‑end/back‑end separation strategy. Two basic patterns were explored: a simple static‑HTML approach without a middle layer, and a Node‑based middle layer.

The first pattern serves an HTML template from a static server; the client loads required JS/CSS and fetches data via AJAX. This works well for pages without SEO requirements.

Need for Server‑Side Rendering

SPA pages suffered from white‑screen delays and poor SEO in Chinese search engines. To address this, server‑side rendering (SSR) with Node was introduced.

Technology Selection

Node frameworks evaluated included Hapi, Express, Koa, and EggJS. Express was initially chosen for its simplicity, but later replaced by Koa2 after Node added async/await support, offering better performance and middleware handling.

For the front‑end framework, Vue and React were considered; Vue was selected for its ability to share logic between client and server (isomorphic rendering).

Project Structure

The repository contains separate directories for client code (Vue, Webpack), server code (Express/Koa), build configuration, and shared utilities. Key folders include client , server , build , config , and dist .

SSR Implementation

Vue’s official SSR example was followed, using createBundleRenderer to render pages on the server.

const { createBundleRenderer } = require('vue-server-renderer');
const renderer = createBundleRenderer(serverBundle, { /* options */ });

Two entry points are built: entry-client.js for the browser bundle and entry-server.js for the server bundle, which are combined into bundle.json for rendering.

Deployment and Operations

Docker containers (1 CPU / 4 GB) run the services, initially with two instances and later scaled to six for high‑traffic pages. A bug related to missing cookies in SSR requests was fixed by passing the cookie through the rendering context.

Configuration Center

A configuration center stores script version hashes, allowing dynamic selection of Vue bundles without restarting services. This enables hot updates of front‑end assets.

Caching Strategy

Two‑layer caching is applied: CDN caching for static assets and file‑based server‑side caching that writes rendered HTML to disk for subsequent fast responses.

Refactoring and Library Extraction

The core utilities (logging, config center integration) were extracted into an internal npm package. The client code was also packaged as a reusable library, allowing other teams to adopt the SSR solution without copying the entire codebase.

Performance Testing

Load tests revealed CPU bottlenecks on 1 CPU / 4 GB instances, especially with Vue 2.3.x due to virtual‑DOM overhead. Upgrading to Vue 2.4.x improved throughput, but CPU remained the limiting factor for complex component trees.

Conclusion

Successful front‑end modernization required close collaboration between front‑end and back‑end teams, API redesign, automated configuration syncing, and careful performance tuning. The journey from static pages to a scalable, SSR‑enabled architecture continues to evolve.