• Good Practices for High-performance and Scalable Node.js Applications [Part 2/3]
  • Virgafox
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: jianboy
  • Proofread by: Calpa

Chapter 2 — How to Make Your Node.js Applications Extend Safely

In the last article, we learned how to scale node.js applications horizontally without worrying about code. In this chapter, we discuss the considerations that must be taken into account when extending the process to prevent errors.

Detach the application instance from the DB

This chapter starts not with code, but with your infrastructure.

If you want your application to scale to multiple hosts, you must deploy the database to several independent hosts so that you can freely replicate hosts as needed.

Deploying applications and databases on the same machine can be cheap and used for development purposes, but it is definitely not recommended for production environments, where applications and databases must be able to scale independently. The same applies to in-memory databases like Redis.

stateless

If you generate multiple instances of your application, each process has its own memory space. This means that even if you are running on a machine, when you store certain values in a global variable, or more commonly a session in memory, if the load-balancing server redirects you to another process during the next request, you won’t be able to find it there.

This applies to session data and internal values, such as any type of application configuration.

One solution for Settings or configurations that can be changed at run time is to store them in an external database (on disk or in memory) so that all processes can access them.

Use JWT for stateless authentication

Authentication is one of the first things to consider when developing stateless applications. If sessions are stored in memory, they will act on the single process.

To make this work, you should configure the network load balancer to always redirect the same user to the same machine, and local users that redirect to the same user always redirect to the same process (sticky sessions).

A simple solution to this problem is to set the storage policy for sessions to be persistent, such as storing them in DB instead of RAM. However, if your application checks session data for every request, then every API call will have disk I/O operations, which is definitely not a good thing from a performance perspective.

A better, faster solution (if your authentication framework supports it) is to store the session in an in-memory database like Redis. Redis instances are typically located outside the application instance, such as a DB instance, but work faster in memory. In any case, storing sessions in RAM makes you need more memory as the number of concurrent sessions increases.

If you want to take a more efficient approach to stateless authentication, look at the JSON Web token.

The idea behind JWT is simple: When a user logs in, the server generates a token, which is essentially base64 encoding of a JSON object containing the payload, plus the hash obtained by the signature, and the payload has a key owned by the server. The payload can contain data for authenticating and authorizing users, such as userID and its associated ACL role. The token is sent back to the client and used by it to validate each API request.

When the server processes the incoming request, it retrieves the payload of the token and re-signs it using its key. If the two signatures match, the payload can be considered valid and unchanged, and the user can be identified.

It is important to remember that JWT does not provide any form of encryption. The payload is only encoded in Base64 and sent in clear text, so if you need to hide content, you must use SSL.

Jwt. IO restores the authentication process with the following pattern:

During authentication, the server does not need to access session data stored somewhere, so each request can be handled by a different process or machine in a very efficient way. No data is held in RAM and no storage I/O operations need to be performed, so this approach is very useful when scaling.

Stored on S3

With multiple servers, user-generated data cannot be stored directly on the file system because the files can only be accessed by processes local to the server. The solution is to store everything on an external service, possibly a dedicated service like Amazon S3, and keep only absolute urls to that resource in the database.

Each process/machine can then access the resource in the same way.

The official AWS SDK with Node.js is very simple, and you can easily integrate services into your applications. S3 is cheap and optimized for this purpose, and is a good choice if your application is not multi-process.

Configure WebSockets correctly

If your application uses WebSockets for real-time interactions between clients or between clients and servers, you need to link back end instances to properly propagate broadcasts or messages between clients connected to different nodes.

The socket. IO library provides a special database connection tool for this, called socket. IO -redis, which allows you to link server instances using the Redis pub-sub feature.

To use a multi-node socket. IO environment, you also need to configure the protocol as “WebSockets” because long polling requires sticky sessions to work.

The next step

In this short article, we’ve seen some things to be aware of about how to extend Node.js applications, which can also be considered good practice for single-node environments.

In the next (and final) article in this series, we’ll cover some advanced Nodejs operations. You can find it here.

If this article is useful to you, please give me a like!

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.