Design and Implementation of a Node.js Middleware Layer for a Data Platform

In July the feasibility of a Node.js middleware layer for the data platform was discussed, and by September it supported four platforms, three of which are stable in production and one in testing.

The author joined the data platform in April and initially planned only incremental improvements to existing infrastructure such as component libraries and standards; the Node.js layer project emerged unexpectedly from a discussion about front‑back end collaboration efficiency.

01 Node.js Positioning

The middleware functions like an API gateway, handling interface proxy, aggregation, and business logic that does not involve the database. Currently the platform has two service types: conventional Java back‑ends and T‑Service, a unified data service that serves front‑end business units and internal applications. T‑Service does not directly interface with the front end, requiring a Java controller layer; the Node.js layer aims to replace these low‑reuse controllers, allowing front‑end developers to query data directly (provided they can write SQL) and freeing Java developers to focus on core services.

Beyond these benefits, expanding front‑end capabilities broadens technical perspective and encourages holistic business thinking.

02 Technical Selection

Given the lightweight nature of the middleware, any framework would suffice; the team chose NestJS v7 for its higher‑level module abstraction, built‑in guards, filters, and interceptors, full compatibility with Express, rich ecosystem, and excellent TypeScript support. Version 7 was selected over v8 to avoid RxJS v7 breaking changes. While NestJS’s request‑scoped providers pose challenges for shared modules like logging, the team opted for the conventional cls‑hooked approach.

03 Service Governance

The services run on the company’s future‑cloud Kubernetes cluster. Health checks are performed via TCP probes (preferred because the services are single‑core pods without a reverse proxy). Logging follows the same ELK pipeline as Java services, with two key practices: propagating a x‑trace‑id header for traceability and regularly cleaning up daily‑rotated log files to prevent disk exhaustion.

04 Summary

The Node.js middleware is still in its early, lightweight stage and will face further challenges. This article records the initial experiences, both positive and negative, and invites feedback. The next article will detail the specific roles and tasks of the middleware in the currently integrated projects.