4 Ways to Avoid Node.js Deployment Pitfalls on ‘Day One’ – InApps 2022

The recent release of Node.js 10.0.0, which will become the official Long Term Support release line for Node in October 2018, has helped to cement its place as one of the most-popular platforms for building fast and scalable web and mobile applications.

With over seven million Node.js instances online and 75 percent of users planning to increase their use of Node.js in the next 12 months, Node.js is no longer the “new kid in town.” We are now turning our attention from communicating why you might want to deploy Node.js to how you get the platform up and running, as we move past the getting-to-know-you stage. For Node.js developers ready to take their skills to the next level, this means delving more deeply into the practical details of how to optimize enterprise-scale Node.js applications.

Post-deployment can be fraught with problems as studies show, so developers need proven strategies and techniques for troubleshooting Node.js applications as they do when deploying any other production release. While a robust pre-production process can help minimize the impact of bugs, configuration failures and other avoidable problems; even the best preparation can’t always keep Murphy’s Law at bay.

A Node.js application will succeed or fail at translating promises and potential into real-world value, relevance, and business impact, of course, during the post-deployment stage. Many of the problems developers encounter — avoidable or not — also tend to surface during the first 24 hours after an application enters production use. The first 24 hours after Node.js is deployed are thus particularly critical.

Here are four common Day One Node.js deployment problems you may encounter — and tips on how to fix them:

1. Crashing Node.js Processes

Node.js is architected to run on a single process, which is a key reason applications built on Node are highly scalable. However, there are also trade-offs to this approach. Namely, when a code, dependency or host error  crashes the process, this essentially crashes the entire application. Using Node.js supervisors and managers to automatically detect and handle failures is the best way to deal with Node process crashes.

When troubleshooting a crashing Node.js process, also keep in mind the problem may involve the application’s hosting platform. Staying up to date on platform-specific guidelines for troubleshooting Node.js applications. Using Microsoft Azure web services and the Heroku platform as service (PaaS), for example, can save time and frustration during the troubleshooting process.

2. Exceeding API Rate Limits

Rate limiting, a common practice among web developers, can be used to restrict the number of user queries as an event-throttling tactic, or as a way to limit API requests. However, deploying an application can be a moment of truth for a developer’s use of rate limiting in a Node.js application. The actual traffic your application receives can differ considerably from predicted traffic, and once an API rate limit has been exceeded, the application will essentially freeze.

Caching, which involves inserting raw JSON-encoded data into the database, is a fairly simple way to adapt your Node.js application to any API rate limit issues. While caching does have a trade-off in the form of increased memory usage, it can be a helpful rate limit workaround. It also gives active users high priority and can reduce the number of API calls required.

3. Troubleshooting WebSocket Issues

In addition to Socket.IO.the most popular WebSocket library for Node.js, there are many different WebSocket libraries available for Node.js today. While each has its own API, all WebSocket libraries are built on top of TCP and do basically the same thing.

No matter which WebSocket library you use, any problem that impedes communication between your server and clients is an urgent one. Here is a quick-and-easy procedure you can follow to reproduce a suspected WebSocket issue:

• Step 1: Create a WebSocket server in its own Node.js process.
• Step 2: Connect to this server using the WebSocket client. This client should be running a separate process.
• Step 3: End the server process created in the first step.
• Step 4: Check the status code. If an error code of 1000 (normal) is reported, then this is incorrect, as the browser would normally report an error code of 1006 in this circumstance.

4. Denial-of-Service (DoS) Attacks

Denial-of-service attacks pose a complex problem involving multiple layers of protection across the networking stack. There isn’t much that can be done at the API layer, but appropriately configuring Sails, the most-popular MVC framework for Node.js, can mitigate certain types of DoS attacks.

Sails sessions can be configured to use a separate session store such as Redis, so your application can run without relying on the memory state of any one API server. This allows you to distribute load by deploying multiple copies of your Sails app across as many servers as required. You do need to place load balancers in front of your application servers that is configured to ensure incoming requests are always directed to the least-busy server. This significantly reduces the risk of one overloaded server becoming a single point of failure.

If you’re not using the long-polling transport enabled in sails.config.sockets, then Socket.IO connections can be configured to use a separate socket store (e.g., Redis). This eliminates the need for sticky sessions at the load balancer and the possibility of would-be attackers directing their attacks against a specific server.

Unpleasant surprises come with the territory when you build business applications, but it’s vital to minimize the gap between when a problem occurs — or even when warning signs of a problem appear — and when you learn about them. As a best practice, including application performance monitoring (APM) in your standard deployment process while ensuring it’s in place during the critical first 24 hours in production, can help to narrow this gap. APM can thus offer a tremendous leg up when it comes to rapidly detecting, identifying and troubleshooting common application issues.

The good news about Day One surprises is you will learn a lot about building better Node.js applications and launching your applications with fewer post-deployment issues. And while problems can and will continue to happen, truly serious issues will likely be fewer and further between.

For more best practices for deploying and managing Node.js applications, including how to prepare for production launch, download Advanced Node.js: Optimize, Deploy, and Maintain an Enterprise-Scale Node.js Application.

AppDynamics is a sponsor of InApps.

Feature image via Pixabay.