Node.js as Backend: Best Use Cases, Tools & Limitations
In 2009, a new technology made its humble beginnings in the vast universe of backend development.
Today, you’d be hard-pressed to find a web developer who hasn’t heard about Node.
Following its inception, it has split communities, triggered forum wars, and brought many to despair.
Think I sound dramatic?
Do a quick Google search. You’ll land on a gold mine of controversy. Some arguments you’ll stumble upon:
“Callback hell is real
Debugging is a bitch
And some are more… straightforward:
“Node.js is an unpleasant software library and I will not use it.”
Today I’m going to discuss:
- The current state of Node.js;
- Its best use cases;
- Its limitations;
- What we can expect from Node moving forward.
The state of Node.js as backend
Before we get into it, let’s just remind ourselves what Node.js is exactly:
Now I know the intro painted Node as a developer nightmare. Truth is it’s become widely popular. But don’t take my word for it:
Stack Overflow’s developer survey for 2017 shows that it’s currently the most used technology by developers.
To put it simply, Node has outlived the “just a fad” period and entered a solid maturity state. It has built a strong and ever-growing community & ecosystem around itself. In fact, its package manager, npm, is now the largest software registry on the web.
Over time, it has proven wrong many of the preconceptions people had in its early days:
→ You can leverage the same debugging experience you have in the frontend using node-inspector which packages Chrome’s native Dev Tools.
Folks at Joyent also know a thing or two about advanced Node debugging & profiling: their DTrace universal debugger was released a long time ago!
You can’t use it for enterprise-level server applications.
→ Such engineering can be achieved with Node.js: it just doesn’t have as many built-in tools taking you by the hand. Big players such as Netflix, PayPal, Walmart, and Yahoo! have all used it. More on this later.
→ This is true. However, tools like TypeScript and Flow emerged to provide that kind of language security. Google’s Closure Compiler can also do the trick here.
And the list goes on & on.
So let’s just jump into some of the best use cases & limitations, to get a better idea of Node’s positioning.
So why should you even consider Node.js as backend in your stack?
General advantages & characteristics
Let me fire some quickies for you:
- Tools like webpack help reuse code on both ends and stay coherent across all system levels.
Let’s say you need to do video encoding, you won’t go searching for an esoteric Node.js library: you’ll simply call proven tools in the command line from Node. Or if there’s already a Python library that can do the complex calculation you require, you can spawn a micro-service and call these functions through a REST API.
- The async/await feature completely changed the way we write asynchronous code, actually making it look and behave a little more like synchronous code. Supported by Node.js since v7.6, this feature came as part of the solution to the infamous Callback hell.
All of the above make Node.js great for the following use cases.
Use case 1: Real-time applications
Collaborative apps (Trello, Google Docs), live-chat, instant-messaging, and online gaming are all examples of RTAs that benefit from a Node.js architecture.
These applications function within a time frame that the users sense as immediate and current. Node.js specifications are the solution for the low-latency needed for these programs to work efficiently.
It facilitates handling multiple client requests, enables reusing packages of library code and the data sync between the client and the server happens very fast.
Use case 2: Single page applications
Even though these are an awesome evolution in web development, they come with some problems when it comes to rendering. This can negatively affect your SEO performance for instance. Server-side rendering in a Node.js environment is a popular option to solve this.
Use case 3: Scalability
Node.js won’t ever get bigger than you need it to be. The beauty of it is that it’s minimalist enough to customize depending on the use case. Performance-wise, that’s key.
Even its name emphasizes that it’s made to assemble multiple small distributed nodes communicating with each other.
Node’s modularity allows you to create small apps without having to deal with a bloated, overkill ecosystem. You choose the tools you need for the job and then scale as needed.
This scalability is not free from complications though, and if you’re not careful, Node.js can become… dangerous.
Node.js backend limitations
Put bluntly, Node.js allows you to easily shoot yourself in the foot. Configuration & customization come at a price, and if you’re inexperienced or undisciplined, you might lose yourself — or your client.
Contrary to a more conventional approach, you create the structure that supports your backend. That involves a lot of decision-making, meaning that you have to know what you’re doing and where you are going if your project scales.
With other languages like Ruby and its well-known framework Ruby on Rails, for instance, we were used to the paradigm “convention over configuration.” These traditional frameworks took developers by the hand and shun some light on the safe path.
With Node.js this goes head over heels. More freedom is given to developers, but the road might get dark and scary if you make the wrong decisions.
And then you’ll find out that “callback hell” is real indeed.
This doesn’t mean that you can’t build bigger server applications with it, but you should always keep these factors in mind.
Even the creator of Node.js, Ryan Dahl, eventually realized the limitations of the system before leaving to work on other projects. He was very transparent about it:
“[…] I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.”
The preconceptions mentioned earlier were all true at one point in Node.js’ short lifetime and still are to some extent. It has matured and grown enough that you are able to work around them if you take the time. The tools the community has to offer enables you to do pretty much anything.
Not so long ago, if you thought about putting together a JS full stack, the first thing that came to mind was the MEAN stack (MongoDB, Express, Angular & Node).
- Express.js is still the most popular Node.js framework out there. It’s a fast, unopinionated & minimalist web framework. It evolved quickly because it’s made simple & straightforward. It’s probably the one closer to Node.js’ basic ideas of a lightweight system with a modularity approach.
- Sails.js is a real-time, MVC framework. It was designed to emulate the MVC pattern of Ruby on Rails but with support for modern apps requirements. It does this through data-driven APIs with a scalable, service-oriented architecture.
- Koa.js was crafted by the team behind Express. Marketed as the “next generation web framework for Node.js,” it’s a smaller, more expressive, and more robust foundation for web applications and APIs.
The point of this article was not to get to an ultimate conclusion on whether Node.js offers the best backend environment. Nor was it to tell you that you should use it.
And I surely won’t get out there and say that it’s any better than other popular backend languages such as Java, C#, C++, PHP, Python, Go or Ruby.
Whether you like it or not, Node.js is visibly here to stay. ;)
You should never think of any framework as a silver bullet that will magically resolve all your problems. Node.js is simply another tool in the immense universe of web development. It’ll get the job done extremely well in some situations, but will be a pain in others.
After that, it’s every developer’s job to carefully think about the right stack for any new project. It’s important to know all your options and not to write off any alternative from the get-go.
Snipcart, for instance, runs on a .NET architecture, which also has its fair share of naysayers. Why did we choose it?
It was the right tool for the job, at that moment in time.
Here’s hoping this overview helps you make up your mind about Node!