How We Scaled Medical Front‑End with Node.js: SSR, Internal Tools & API Services

I am Gao Xiang, a front‑end engineer from WeDoctor Group's Consumer Business Unit. This article compiles my talk at the "First Colorful Front‑End Technology Salon" titled "Node.js Applications in the Healthcare Industry", describing the development history and practical experience of Node.js at WeDoctor.

Technology Stack Evolution

WeDoctor, an internet medical company based in Hangzhou, grew its front‑end team from a few people in 2015 to over 120 today. The front‑end technology stack has evolved dramatically, as shown in the diagram below.

Before 2016 the development was tightly coupled front‑end/back‑end.

In 2017 Vue was introduced, enabling front‑end/back‑end separation and experiments with Vue SSR.

In 2018 Vue SSR was fully adopted, accumulating substantial Node.js experience and many online Node.js applications.

In 2023 the solutions were distilled into frameworks, documentation, plugins, and scaffolds to better support iterative demands.

Node.js started relatively late at WeDoctor but grew quickly; most consumer‑line services have migrated to an SSR architecture.

Overall, Node.js applications account for roughly one‑quarter of all front‑end applications, with the majority being SSR, followed by full‑stack internal tools, and API services for aggregation and forwarding.

Application Scenario 1: Internal Tools

Our team builds many internal efficiency tools serving developers, testers, operators, and product managers, all using Node.js for the backend layer. Three representative tools are:

Jindouyun – Requirement publishing management system

Magic Cube – Visual activity page building platform

Smart Operations Butler – Community operation tool

For example, Jindouyun streamlines the entire requirement release process, automating branch merging, release planning, package.json change monitoring, and more, thereby multiplying development and testing efficiency.

Node.js handles data persistence, API design, Dubbo service calls, DingTalk notifications, email alerts, and scheduled tasks within this system.

Application Scenario 2: Vue Server‑Side Rendering (SSR)

We have extensively researched and practiced Vue SSR, achieving a unified codebase for both client and server, delivering single‑page user experience while supporting SEO. This frees back‑end developers from presentation concerns and lets them focus on service development.

Key SSR implementations include:

Async Data Mixing – We adopt Nuxt.js‑style asyncData to fetch data on the server, merge it with component data, and keep it decoupled from Vuex.

General Utility Wrappers – Common methods such as cookie handling and routing are abstracted to hide client/server differences, and we provide useful plugins.

feb‑alive Plugin – A Vue page‑level cache plugin that replaces keep-alive, delivering browser‑level navigation experience.

Exception Degradation Mechanism – When server‑side errors occur (e.g., API failure or browser‑only code in asyncData), the system can fall back to a SPA, avoiding a 500 error page. The degradation flow is illustrated below.

Server‑Side Caching – LRU‑Cache is used for idempotent interfaces to reduce response latency.

Full‑Link Tracing Integration – SSR apps are hooked into the internal tracing system to capture end‑to‑end request paths.

Internal Framework Packaging – We encapsulated the SSR solution into an internal framework (Aug.js) built on Egg.js and TypeScript, exposing configurable webpack and middleware hooks.

Application Scenario 3: API Services (BFF)

We adopt the Backend‑For‑Frontend pattern, where front‑end engineers maintain a layer between client applications and underlying services, performing data aggregation, adaptation, and routing.

Node.js API services perform:

Dubbo service invocation via dubbo2.js with custom wrappers.

Registration with Eureka using eureka-js-client for service discovery.

Decorator‑based routing on top of Egg.js and TypeScript to improve developer experience.

Our internal framework Aug.js (based on Egg.js) integrates logging, APM, Gtrace, Eureka, and other middleware to provide a reusable enterprise‑grade Node.js solution.

Node.js Ecosystem Construction

Beyond the core services, we built a full‑link tracing system and a performance monitoring platform.

Full‑Link Tracing

Each incoming request generates a unique TraceId; subsequent calls propagate this ID via HTTP headers or Dubbo attachments. A Span represents an atomic operation (function call, RPC, DB access). The system records TraceId, SpanId, ParentId, and timestamps to reconstruct the call tree.

const spanId = generateUUID16();
const spanCtx = { spanId };
const parentSpanId = req.headers['span-id'];
const parentTraceId = req.headers['trace-id'];
if (parentSpanId && parentTraceId) {
  spanCtx.traceId = parentTraceId;
  spanCtx.parentId = parentSpanId;
  spanCtx.reference = reference.CHILD_OF;
} else {
  const traceId = generateUUID32();
  spanCtx.traceId = traceId;
  spanCtx.parentId = traceId.substr(-16);
}

TraceId propagation and Span ordering (via startTime) enable precise latency analysis. Node.js and Java services push tracing data to Kafka; a proxy layer adapts HTTP‑only clients, and a web UI visualizes the trace.

Performance Monitoring Platform

We evaluated several APM products on criteria such as invasiveness, implementation method, maturity, data security, and performance. The chosen solution is Elastic APM, which can be deployed internally with low overhead and comprehensive baseline monitoring. Further customization is possible if deeper analysis is required.

Conclusion

Node.js has become a powerful efficiency tool at WeDoctor. It enables front‑end engineers to turn ideas into products quickly, supports robust SSR with graceful degradation, provides full‑link tracing for rapid issue localization, and offers performance monitoring to ensure stability. The key takeaway: avoid reinventing the wheel.