How to Implement Health Checks and Smooth Deployments for Node.js with Egg.js

Health Check

In the first lecture we introduced routing traffic through a gateway to a Node.js application, and explained that the gateway must verify the application’s health before forwarding requests. The gateway calls a HTTP health‑check endpoint (e.g., /health/check) every 30 seconds; a 200 response means the service is available, otherwise the gateway stops sending traffic.

Implementing this is straightforward: add a controller that returns OK with status 200. If the endpoint returns a non‑200 code, the gateway treats the service as unavailable.

Smooth Deployment

During a release the Node.js process may go offline right after a successful health check, causing a 30‑second window of failed requests. To avoid this, a smooth‑deployment strategy is used: the release system calls an offline API before stopping the service and an online API after the new version is ready.

The offline API sets a global variable indicating the service is offline, but the actual process shutdown is delayed, allowing in‑flight requests to complete. Because Egg.js runs multiple worker processes, the offline signal must be broadcast to all workers via inter‑process communication; otherwise some workers would still report an online status.

We implemented an Egg.js plugin pp-ndp (as middleware) with the following core logic:

const { request } = ctx;
const { path, hostname } = request;
if (path === online) {
  app.messenger.sendToApp(ONLINE, '');
  ctx.body = 'NDP: Nodejs Is Online';
} else if (path === offline) {
  app.messenger.sendToApp(OFFLINE, '');
  ctx.body = 'NDP: Nodejs Is Offline';
} else if (path === check) {
  ctx.body = 'NDP: Nodejs Start Success';
} else if (path === status) {
  if (app[ISONLINE]) {
    ctx.body = 'NDP: Nodejs Is Online';
  } else {
    ctx.status = 500;
  }
} else {
  await next();
}

This approach works best when multiple Node.js instances are deployed in groups; a single‑machine deployment would still experience downtime during a release.

CDN and Front‑End Code Discovery

Because the front‑end assets are bundled together with the Node.js code for server‑side rendering, the client‑side scripts are still served via CDN. Using webpack‑manifest‑plugin, a manifest.json file is generated that maps original asset names to their hashed paths, e.g.:

{
  "vendor.js": "/static/f5e0281b/js/vendor.chunk.js",
  "vendor.js.map": "/static/f5e0281b/js/vendor.chunk.js.map",
  "Page.css": "/static/f2065164/css/Page.chunk.css",
  "Page.js": "/static/f2065164/js/Page.chunk.js",
  "Page.js.map": "/static/f2065164/js/Page.chunk.js.map"
}

These files are uploaded to a CDN and referenced in templates via the Egg.js plugin pp-just:

<script src="{{ctx.just.use('Page.js')}}"></script>

The plugin reads manifest.json, prefixes the CDN domain, and outputs the final URL, such as:

<script src="https://qiyukf.nosdn.127.net/huke/static/f2065164/js/Page.chunk.js"></script>

This enables versioned assets and smooth rollouts without manual path management.

Conclusion

The health‑check and smooth‑deployment techniques described solve early‑stage release problems, making deployments safer. As the system grows, additional strategies like gray‑release environments and application monitoring will be needed, which will be covered in the next lecture.