Why do we use Node.js in our backend?

Ryan Dahl kicked off work on Node.js in 2009 on top of two years of research related to server-side web components. The journey of the runtime wasn’t a smooth ride at all but as of today the major component of its semantic versioning hit 18. The revolutionary premise of Node.js was “server-side JavaScript” because since its inception in 1996 JavaScript was strictly in-browser scripting language. At that time Django web framework backed up by Python was 4 years old. Similarly Ruby on Rails web framework based on Ruby was first released in 2005. It was about time for JavaScript to challenge traditional backend programming languages in their field.

What is the thing exactly?

Node.js is a JavaScript runtime or even simpler a program to interpret & execute JavaScript. Initial focus of JS was to add interactivity to web pages. Runtimes for it existed only as parts of web browsers. The journey of JS is fascinating: from a scripting browsers sidekick to ubiquitous multi-paradigm general purpose programming language. Node.js played a key role in the process of JS ascension.

Fundamentally Node.js didn’t do anything too fancy. It uses V8 JavaScript engine to execute JS in an event loop similarly to how browsers do it. Except it became possible to run any JS that way from the command line. And another cornerstone were APIs consumable from JS. These provide access to OS features like file & network I/O and many-many others. That opened infinite world of possibilities for usage of JavaScript on the backend.

So why do we use Node.js in our backend?

From my perspective the are following key aspects which determined the success of Node.js. These are kind of answers to the question “why do we use Node.js in our backend?”

JavaScript on the backend

Modern single-page application (SPA) enabler frameworks like Angular or React started shortly after Node.js inception. That led to explosion of complexity in the world of the frontend which previously mostly revolved around HTML/CSS and JS scripting as an addendum to traditional MVC web frameworks. Nevertheless the separation between frontend & backend devs was pretty clear even before that – JS for the frontend, Python/Ruby/Java for the backend.

Node.js changed that. It provided frontend devs reluctant to learning backend programming languages a way around the problem which kept them at bay from any backend work. Backend programming challenges are very different from frontend ones but still the ability to reuse JS expertise in the new domain was invaluable.

Non-Blocking I/O

Traditionally the work of backend systems involved processing of many parallel requests and downstream I/O (files, databases, caches etc). To handle that usually OS threads were leveraged at some level in the implementation what allowed independent processing of different requests. If one request issued a long query against database and waited for results that didn’t affect another quick one.

By its nature Node.js is single threaded – one thread runs the event loop and process handlers in it. Such design ruled out the possibility to block this thread to wait for I/O completion because all other work will be stuck until it’s done. By leveraging alternative kernel features Node.js implemented so-called “non-blocking I/O” – as soon as I/O request is sent the main thread is free to process other handlers in the event loop. When I/O request is done another handler is scheduled on the event loop to involve CPU in results processing.

Such approach yielded awesome results in terms of throughput. Moreover these days non-blocking I/O is enabled by co-routines in Go & Python making it usable beyond the Node.js ecosystem.

Strong community

NPM is one of the largest package repository hosting many-many reusable packages for Node.js. All these packages were created & published by project teams working on libraries for Node.js. The wide appeal of Node.js made this happen by building a strong community around the technology.

The future: do we still use Node.js in our backend?

I hope you have some idea on why do we use Node.js in our backend now. Node.js doesn’t show any sign of weakening despite Ryan Dahl now works on its “next generation” – Deno. Time will tell if Node.js should step down as the most popular JS runtime in favor of Deno but I bet they will co-exist for a long time.