NodeJS Middleware Layer for iQIYI PC Web: Architecture, Design, and Monitoring

iQIYI, the largest Chinese internet video portal, serves tens of millions of users daily on its PC main site. Rapid business expansion and frequent project updates have increased the demands on interface performance, response time, caching strategies, and customization, leading to complex front‑end logic and high communication costs with multiple backend teams.

To address these challenges, a dedicated backend service was built to aggregate various APIs into a single endpoint for the PC Web front‑end, improving user experience and development efficiency. NodeJS was chosen because of its stability, widespread adoption in web projects, and the fact that JavaScript is familiar to front‑end developers.

1. What is the PC Web NodeJS Middleware Layer?

The NodeJS middleware layer is a thin data service positioned between the client and the platform, exposing internal and external APIs for the front‑end or development platform. It enables front‑back separation, performs data stitching, transformation, and filtering. The role is illustrated in the following diagram:

The middleware provides customized API aggregation for PC Web, allowing backend teams to supply raw abstract data interfaces while the middleware consolidates them. Front‑end pages request a single middleware endpoint to obtain ready‑to‑display data, eliminating multiple client‑side calls.

2. Architecture Design

The middleware adopts an nginx + Varnish + Node architecture. Nginx handles request routing and load balancing, Varnish serves as a high‑performance caching layer, and Node processes business logic. On a 4‑core server, four Node processes are launched (one per CPU core) and distributed by nginx’s ip_hash algorithm.

Varnish caches full API responses, reducing repeated upstream calls. To cache JSONP requests that contain timestamps or callbacks, a parameter‑filtering layer rewrites requests before they reach Varnish, enabling cache reuse and improving overall performance.

3. Code Architecture

The middleware is built on a custom framework called qiyi-wings, which is a Koa2‑based wrapper. The framework enforces a clear separation of concerns: app/base/*.js: Base classes for DAO, model, and service. app/controller/*: Handles user input, invokes services, and returns results. app/dao/*.js: Implements all external API calls. app/middleware/*.js: Custom middleware such as error handling and request timing. app/model/*.js: Defines unified data models (e.g., video, album, star). app/formatter/*.js: Transforms raw data into the model schema. app/service/*: Core business logic. app/util/*.js: Shared utility functions. app/router.js: URL routing configuration. app/app.js: Framework bootstrap. index.js: Service startup script.

4. Business Interface Example

A video‑information API demonstrates the development workflow. First, a route is defined in router.js to accept HTTP requests.

Next, a controller parses parameters, invokes the video service, and returns data.

The service layer performs the core logic: it calls the DAO to fetch raw data, then uses the model and formatter to produce a unified response.

To standardize output across teams, a Video Model defines common fields (e.g., video ID, title, duration). The model ensures consistent data structures for front‑end consumption.

A Video Formatter converts heterogeneous backend payloads into the model schema.

With these modules, a single, reusable video API is delivered, allowing front‑end components to be shared across pages.

5. Service Monitoring Implementation

The middleware runs on dozens of machines, handling billions of daily requests and tens of thousands of QPS. Stability is ensured through:

Release Process Standardization: Development → Test → Pre‑production packaging → Production deployment, with version‑controlled rollbacks.

Log‑Based Monitoring: Detailed logs (errors, timeouts, performance metrics) are shipped to an Elasticsearch cluster and visualized in a custom dashboard showing QPS trends, latency, error rates, and resource usage.

Hardware/System Monitoring: Integration with the internal Hubble system (similar to Zabbix) monitors CPU, memory, nginx and Varnish health, and triggers phone/SMS alerts on threshold breaches.

Alarm Granularity: Interface subscription, error‑rate thresholds (1% per hour, 10% over 10 minutes), and automated email notifications to owners.

Network Dial‑Testing: Nationwide synthetic traffic checks via the Yunbo testing system, with SMS alerts on connectivity issues.

通过上述流程层、业务层、系统层、网络层的监控相结合从而保证了中间层服务99.99%的稳定性与可用性。

6. Benefits of the Middleware Layer

The introduction of the middleware brings several advantages:

Customizable, business‑driven APIs expand front‑end capabilities.

Front‑end engineers develop and maintain the APIs, reducing hand‑off time and accelerating iteration.

Using NodeJS (JavaScript) aligns with front‑end skill sets, lowering learning curves.

Full‑stack development improves engineers’ skill breadth and reduces staffing costs.

Although the primary backend services are built with Java, NodeJS offers a lightweight, event‑driven environment that excels at JSON handling, API aggregation, and high‑concurrency scenarios, making it ideal for gateway‑type services.

7. Closing Remarks

The middleware empowers the PC Web team to own its data interfaces, reducing dependency on upstream services, fostering creativity, and enabling rapid project delivery.