You should never ever run directly against Node.js in production. Maybe.

If you‘ve spent any time in the Node.js community, you‘ve probably heard this piece of advice repeated ad nauseam: "Never run directly against Node.js in production." It‘s practically a commandment, handed down from the Node.js gods on high.

But like many articles of faith, it‘s worth examining more closely. Is it always true? Are there cases where running directly against Node.js in production might be (gasp) acceptable? Let‘s dive in and see if we can separate the gospel from the heresy.

What does it mean to "run directly against Node.js"?

Before we go any further, let‘s clarify what we mean by running "directly against Node.js". When you run a Node.js application, you typically start it from the command line using the node command:

node app.js

Here, app.js is the entry point to your application. This command spins up the Node.js runtime, loads your application code, and starts executing it. Your app will keep running until you terminate the node process, either manually or through a crash.

In a development environment, running Node.js apps this way is common. It‘s simple and direct. But for production deployments, most developers recommend adding a layer of process management on top of the raw node invocation.

The risks of running directly against Node.js in production

So why is running production applications directly against Node.js discouraged? There are several key reasons:

1. Lack of process monitoring and automatic restarts
2. No built-in load balancing or scaling
3. Potential instability with uncaught exceptions
4. No isolation between application and server environment

Let‘s examine each of these risks in more detail.

No process monitoring or automatic restarts

If you run your Node.js app directly with the node command and it crashes due to an uncaught exception or other bug, that‘s it. Game over. The app will be offline until you manually restart it.

In a production environment, unplanned downtime is the enemy. You want your application processes to be continually monitored and automatically restarted if they go down unexpectedly. This improves availability and reduces the impact of failures.

Consider this real-world scenario: Your Node.js application is happily serving production traffic, but a new bug is introduced in the latest code release. This bug causes the application to throw an uncaught exception under certain conditions. Without process monitoring in place, your application will crash and stay down until a developer notices and manually restarts it. Depending on your alerting setup and response times, this could translate to significant downtime for your users.

Now imagine the same scenario but with process monitoring enabled. When the application crashes, the process manager detects the failure and automatically spawns a new instance, minimizing downtime. Crisis averted!

No built-in load balancing or scaling

When you invoke your app with the node command, you‘re running a single instance of the application. This single instance can only handle a limited amount of traffic and concurrent requests before performance starts to suffer.

To scale a Node.js application horizontally, you need to run multiple instances, typically behind a load balancer that distributes incoming requests across the available instances. This allows you to handle more traffic and ensures better availability if one instance goes down.

With a single node process, you have no built-in ability to scale. You‘re limited to the capacity of a single instance, and if that instance fails, your application is down for everyone.

Let‘s look at some data to illustrate the impact of scaling. Here‘s a simplified benchmark comparing the request throughput of a single Node.js instance vs multiple load-balanced instances:

Setup	Requests per Second
Single instance	1000
2 load-balanced instances	1800
4 load-balanced instances	3500
8 load-balanced instances	6000

As you can see, adding more instances allows the application to handle significantly higher traffic loads. A single instance can only take you so far.

Potential instability with uncaught exceptions

JavaScript has a bit of a notorious reputation when it comes to error handling. If an exception is thrown in your Node.js code and not caught, the default behavior is for the process to terminate.

In a development environment, this isn‘t necessarily a huge problem. But in production, an uncaught exception can take down your entire application if you‘re running it directly with node. A single unhandled error can cause an outage for all users.

To illustrate, consider this contrived example:

function getUser(userId) {
  // Simulating an error
  if (userId === ‘123‘) {
    throw new Error(‘Oops!‘);
  }

  // Normal operation
  return { id: userId, name: ‘John Doe‘ };
}

app.get(‘/users/:id‘, (req, res) => {
  const user = getUser(req.params.id);
  res.json(user);
});

If a request comes in with a userId of "123", the getUser function will throw an unhandled error. If you‘re running this code with node app.js, the error will crash the process and take down the entire application.

In a production environment, you generally want more fault tolerance and resilience. Crashing the whole application due to a single unhandled error is not ideal.

No isolation between application and server environment

When you run a Node.js app with the node command, it runs directly on the server‘s operating system, sharing resources with other processes. There‘s no isolation between the application and the underlying server environment.

This lack of isolation can cause problems, especially as your application grows in complexity. For example:

• Your application may be affected by other processes running on the same server, competing for resources like CPU and memory.
• Buggy or malicious code in your application could potentially access or modify the server‘s filesystem and other resources.
• Upgrading or changing the server environment can be risky, as it may break application dependencies.

In a production environment, it‘s generally better to isolate your application from the underlying server as much as possible. This improves security, stability, and flexibility.

Better approaches for running Node.js in production

So if running directly against Node.js is discouraged, what‘s the alternative? Let‘s look at a couple of common approaches.

Using a process manager

A process manager is a tool that manages your application processes for you. It can handle starting and stopping your app, restarting it if it crashes, and scaling it across multiple CPU cores or machines.

Some popular process managers in the Node.js ecosystem include:

• PM2
• Forever
• StrongLoop Process Manager

PM2 is one of the most widely used. Let‘s take a closer look at how it works.

PM2 in action

With PM2, you start your application with the pm2 command instead of node:

pm2 start app.js

PM2 will spawn a child process to run your app and monitor it. If the app crashes, PM2 will automatically restart it.

You can also have PM2 run multiple instances of your application with a single command:

pm2 start app.js -i max

The -i max option tells PM2 to spawn as many instances as there are CPU cores on the machine. PM2 will automatically distribute incoming requests across the available instances.

Here‘s an example PM2 ecosystem configuration file that sets up multiple application instances:

module.exports = {
  apps : [{
    name: ‘api‘,
    script: ‘app.js‘,
    instances: ‘max‘,
    autorestart: true,
    watch: false,
    max_memory_restart: ‘1G‘,
  }]
};

Using a process manager like PM2 is a big step up from running directly against Node.js. You get automatic restarts, better availability, and easier scalability without a lot of manual setup.

Using containers and orchestration

For even more control and flexibility, you can run your Node.js applications in containers using an orchestration platform like Kubernetes.

With this approach, you package your Node.js app into a container image using a tool like Docker. The orchestration platform then manages deploying and running instances of the container across a cluster of machines.

Some key benefits of this approach include:

• Horizontal scaling: You can easily scale your application by running more container instances as needed. Kubernetes can automatically adjust the number of instances based on CPU usage or other metrics.
• High availability: Kubernetes monitors your containers and automatically restarts them if they fail. You can also run multiple replicas of each container to ensure high availability.
• Rolling updates: You can update your application by deploying new container images. Kubernetes can perform rolling updates to minimize downtime.
• Resource isolation: Each container has its own isolated environment, with its own filesystem and resources. This provides a high degree of isolation and security.

Here‘s a simple example of a Kubernetes deployment configuration for a Node.js application:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v1
        ports:
        - containerPort: 3000

This configuration tells Kubernetes to run three replicas of the my-app container, exposing port 3000. Kubernetes will handle scaling, failover, and updates based on this configuration.

Of course, running containerized applications in production is a complex topic in its own right. But if you‘re already using containers and orchestration, it‘s a natural fit for Node.js apps.

The case for running directly against Node.js (sometimes)

With all the risks and alternatives laid out, it might seem like running directly against Node.js in production is never a good idea. But are there cases where it could be acceptable?

Controversial opinion: yes, sometimes.

The key is to understand the tradeoffs and limitations. If you have a small, simple Node.js application that doesn‘t need to scale and can tolerate occasional downtime, running directly with node might be a viable option.

Consider these factors:

• Traffic and scaling needs: If your application has low, predictable traffic and doesn‘t need to scale beyond a single instance, the scaling limitations of running directly with node may not be a concern.
• Complexity and dependencies: Simpler applications with fewer dependencies are easier to manage without containers or process managers. As complexity grows, the benefits of isolation and management tools become more important.
• Downtime tolerance: Some applications can tolerate occasional downtime without major consequences. For example, an internal tool with low usage might be able to survive a crash and manual restart. But for customer-facing production apps, any downtime is usually unacceptable.
• Team size and ops capacity: Smaller teams and projects may not have the resources to set up and manage complex production infrastructures. In these cases, the simplicity of running with node directly could be appealing.

If your application fits these criteria, running production loads directly with node could be a reasonable choice. Just make sure you have proper monitoring and alerting configured to detect and resolve any issues quickly.

It‘s also important to have a plan for evolving your deployment approach as your application grows. What works for a small, simple app may not scale as traffic increases or new features are added. Be prepared to adopt more sophisticated tools and techniques as your needs change.

Conclusion and recommendations

In the end, the question of whether to run directly against Node.js in production is not black and white. Like most things in software development, it depends on your specific circumstances and requirements.

For most production scenarios, using a process manager or container orchestration is the recommended approach. The benefits in terms of availability, scalability, and maintainability are hard to ignore. If you‘re building a mission-critical application that needs to scale and remain highly available, these tools are essential.

However, for smaller, simpler applications with limited scaling needs, running directly against Node.js can be a viable option. It‘s a simpler approach that requires less setup and management overhead. Just be sure to monitor your application closely and have a plan for handling failures.

As a general rule, start with the simplest approach that meets your current needs, but be prepared to evolve as your application grows. Don‘t overcomplicate things prematurely, but also don‘t paint yourself into a corner by ignoring potential future requirements.

Regardless of your deployment approach, there are some best practices you should always follow for Node.js applications in production:

• Use proper error handling and logging to detect and diagnose issues quickly.
• Monitor your application‘s performance and resource usage to identify bottlenecks and potential problems.
• Keep your dependencies up to date and address security vulnerabilities promptly.
• Automate your testing and deployment processes to reduce the risk of human error.
• Have a plan for scaling and evolving your architecture as your needs change.

By following these practices and carefully considering your deployment options, you can build Node.js applications that are reliable, scalable, and maintainable in production. Just remember: there‘s no one-size-fits-all answer. Evaluate your options carefully and choose the approach that best fits your needs. And don‘t be afraid to evolve over time as your application grows and changes.

Happy deploying!