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


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?

ELK !! Like seriously?

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

Why use gridfFS if the file is not meant to be streamed back to the client and only used for processing? Just curious. We at our startup take in a video and generate meta data off it with AI. Summary, questions, chapters etc. (Everything patented) We need to only process the video and not serve it back. Even if we do need to stream it, I'm sure grid FS won't do any justice. Or would it?

Write a reply...

Load more responses

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 ...