Node.js on VIP
Two types of Node.js applications are supported on the VIP Platform.
Decoupled / headless frontend
The REST API allows WordPress to operate in a decoupled / headless manner. Rather than a traditional PHP-driven theme, sites can be run as a static single-page application (SPA) or a fully isomorphic application (with server-side rendering).
Both types are supported, and VIP offers some add-ons (like Redis) to make them even more complete.
Microservices / APIs
WordPress is flexible enough to support many different use cases, but not all of them. A companion microservice can be used to offload tasks that may not be well-suited for a typical WordPress app, such as a proxy for another API or service or a middleware layer like a GraphQL API.
Requirements
An application must fulfill several requirements before it is able to run on VIP’s infrastructure.
Exposing a health check endpoint
The VIP Platform sends frequent health checks at this endpoint: /cache-healthcheck?
All Node.js applications must implement this endpoint using application code.
Production dependencies
Node.js applications on the VIP Platform must use npm to manage their dependencies.
Use VIP-CLI to manage environment variables that need to be present when building and running the application.
Dynamic PORT
VIP assigns a dynamic port to applications using the PORT environment variable. In order for an application to work correctly, it needs to start on the assigned port.
If an application’s port is declared in code, the assigned port can be accessed using process.env.PORT. Logic should be added to fall back to a default port if no port is assigned (i.e., in local development):
const PORT = process.env.PORT || 3000;If an application’s port is defined in the start script in package.json, the assigned port can be accessed using $PORT:
"start": "frontity serve --port $PORT"Other requirements
Stateless, immutable, and multi-container
All applications on VIP must be able to run across multiple containers and processes at the same time. This means that each deployment of a Node.js application must be stateless and immutable. The file system in the container is read-only and an application must not rely on absolute paths. If any data is stored in memory it will be lost on deployment or when containers are added or removed.
Data can be persisted elsewhere (e.g., in a WordPress application via the REST API or GraphQL). If a cache data is needed for later reuse, Redis can be deployed alongside the Node.js application.
No process monitors
For production deployment, an application does not need any process monitors (like nodemon or PM2) to handle restarts. This is handled automatically.
Example applications that fulfill all these requirements can be found in the Node.js skeleton starter repository.
Limitations
For security and performance reasons, there are some paths that have special behavior across all applications hosted on VIP, even Node.js applications:
/wp-admin/wp-content/wp-includes/wp-login
VIP recommends avoiding the use of these paths on Node.js sites. If you need to proxy or redirect a request matching one of these paths to a WordPress site, we suggest rewriting it. For example, redirect https://nodejs-app.example.com/admin to https://wp-app.example.com/wp-admin/.
New Relic
If New Relic is not yet enabled, create a support ticket request and specify the environment where New Relic should be enabled (e.g., production, development, preprod).
To use New Relic with Node.js, install the official NPM package and require / import the package. Once New Relic has been enabled for a Node.js application, monitoring will be configured using environment variables. Do not configure the New Relic agent via newrelic.js.