10 things you shouldn't do while running Node.js in production

12Comments

Write your comment…

Hey, nice list there, thanks a lot! I agree with most of your points. But I want to add my little feedback :)

Not using a reverse proxy

Most reverse proxies are not able to fully leverage the power of HTTP/2 and other modern standards. Sometimes, there is trouble with reverse-proxies and (web-)socket connections. I think there are cases where you really want to expose your Node.JS application to the internet.

Maintaining global states inside Node web processes

How to maintain state really depends on the kind of application you develop. I work on an application which keeps alive websocket connections with some 500 devices. They have to be manageable over a separate GUI, so I do not have any other choice than to store the connections, if I want to reuse them (and send commands) based on the device-name.

@Reactum yeah, that might be one solution, but why not just write everything you need directly in Node.JS? Even with Go, the service will not perform any better as Node.JS will still be the slowest part in the chain...

Write a reply...

Dockers is also worth mentioning

Write a reply...

hey nice article. i am a junior node developer and i don't know any of the things you spoke of above. what references should i search for to start learning this from the beginning? im kind of clueless on where to start as you went over a lot of things. i created say a social media blog / video app with user auth using passport and tokens.

you mentioned using clusters? i guess all of this is in devops department? what do you suggest or where do you suggest i start to learn this stuff it all feels really scattered how can i lower my learning time and rate for this stuff?

Write a reply...

Lack of Monitoring

can you suggest a tool to send/log these errors or does the pm2 monitoring tool do this?

Write a reply...

I would like to add the following topics as what you shouldn't do in production:

  • Serve static assets not minified and gzip'ed (see grunt)
  • Disallow local caching for those static assets
  • Keep access logging enabled
  • Store uploaded files on disk folders instead of a virtual file system like GridFS
Write a reply...

Excellent post . i'm building a node app which is completely stateless and uses JWT for authentication. i'm planning to host the app on 10 servers each having only i cpu CORE (as it is stateless there is no need to bother about session sync) each server has nginx to frontload node app on that particular server . and all these servers will be front loaded by 1 load balancer . so my question is in my scenario do i really require cluster module ?

As far as I understood, even having only 1 CPU core, the cluster stills brings to you the benefit of having no downtime when reloading the application on a specific server. Yeah, I know... you already have other 9 servers to take care when 1 server is restarting the app... It may be a "micro-benefit", but it is still a benefit. (Specially if you start with one server alone before adding the others.)

Write a reply...

Something worth to read.

Write a reply...

Hi, sorry to bump up on an old post. But this shows up when I search for clustering in PM2.

I'm still new in nodejs. My question is, does it really needed in all production use case?

Yes I'm aware that it improves the speed a lot, but in my use case, I use chokidar to watch a directory, and then fork a child_process for uploading it to S3 every time new file added.

When I tried to run PM2 in cluster mode, and it does the same thing twice. How can I improve the app performance without getting this?

Write a reply...

HI Nice article Found very useful, If i use the cluster then how socket communication works.

there will be one main process which has the connection and distributes the requests to one of your workers. You do not even have to care, just use the socket connections as if there was only one process. You can read more about it in the official docs

Write a reply...

Some good stuff but I don't use the cluster module when running inside docker

Write a reply...

Thanks for this. I just recently launched a node website and this will come in handy!

Write a reply...

Also some thoughts from here:

Node.js is single threaded in nature

This is not entirely true, since the underlying v8 engine of course uses multiple threads. By default, these are 4, but can be increased. Threading is used for any non-blocking I/O (that is, file I/O, network I/O). And as you already suggested, not to do heavy lifting (=CPU intensive work), it means that node.js/v8 is already very well prepared for parallel processing and utilizing multiple CPUs/cores. Therefore, I would disagree that the clustering module is a must.

Not using Node.js Cluster

You already suggested nginx as reverse proxy, it should be mentioned that nginx can also be very well used as a load balancer for node.js applications. For a comparison see this link: keithcirkel.co.uk/load-balancing-node-js

Especially its capability to dispatch requests to node.js processes according to their current number of pending requests can probably be superior to the common round-robin approach.

Write a reply...

Join a friendly and inclusive Q&A network for coders

  • 🖥Pick the technologies you like & read great content through your feed.
  • 💬Ask a question when you want to learn more about anything.
  • 🚀Share what you know & build your portfolio.
Sign up nowLearn more

loading ...