You Can Use Node.js for Enterprise Apps! No, Really!
There is a lot of FUD (Fear, Uncertainty, and Doubt) online about whether you should use Node.js to write complex apps. People tend to use the term “enterprise” to describe such apps, though enterprises can have simple apps and startups can have complex apps. Here’s one example: Node.js for Enterprise applications!! Are you kidding?
FUD #1: Node.js Is Single Threaded So It’s Slow
I’ve seen this claim a lot online, but I honestly cannot account for the logic behind it. It starts with a kernel of truth: Node.js is single threaded. However, this is an advantage, not a disadvantage. In non-event-driven frameworks, many threads must be created in order to handle requests in parallel. This places an artificial limit on the number of requests that may be handled at once. Imagine a server that is generally I/O limited due to an overloaded database. You could max out all your available threads on your server while it sits there waiting for a bunch of database queries to resolve. Requests that don’t need to hit the database are held up in a queue waiting for a free thread.
This artificial cap on parallelism doesn’t exist in Node.js. It can handle as many simultaneous connections as you have memory available for (and your kernel allows). And if you are running on a server with multiple CPU cores, just spin up multiple Node.js processes and load balance across them. Easy-peasy!
FUD #2: Asynchronous APIs Are Hard
The appropriate response to this is: put on your big boy pants and figure out how to engineer again.
People find asynchronous APIs daunting. This is understandable, most software is written in a synchronous fashion. However, asynchronous coding is not necessarily harder to write nor harder to read. Especially with the advent of Promises, there are genuinely easy to understand patterns to handle asynchronous needs.
The alternative is to chug along happily using synchronous APIs until the inevitable moment where you realize you need to do two things in parallel. Once you need asynchronous functionality you will be forced to look up how your language/framework supports threads. I can practically guarantee the thread API in your synchronous framework will have a harder-to-use API than Node.js’s asynchronous APIs.
FUD #3: Enterprise Apps Need Strong Typing
Let’s leave aside how bad strong typing can be when done poorly (if you really want to find out, go write a library in C++). In reality, if you are having problems figuring out what the types of variables are that you are using, then you need to figure out a better variable naming scheme and how to read other people’s code. You should always be able to find out what the type of a variable is by reading code that either produces it or uses it elsewhere. If you don’t have access to such code, then you need to read the docs more carefully or complain to whoever wrote the docs.
Relying on strong typing is a crutch. If you haven’t taken the time to understand the data passed to you, then you can’t reliably use it. It’s as simple as that.
Now I don’t mean to say that strong typing is bad. If you love strong typing, then keep on keeping on. You can even add strong typing to Node.js using TypeScript! But you can build complex, “enterprise” apps without strong typing.
And There Is More FUD!
I’m going to let the above stand on its own and then place a blanket statement that every other stated disadvantage of Node.js for complex apps is wrong. I should be free to mimic what opposing blog posts do when detailing why you shouldn’t write complex apps in Node.js :).
All that said, I also don’t want to make it sound like writing complex apps in Node.js is easy. It’s not easy in any language/framework. It takes proper architecting and engineering to make large apps work. Don’t choose Node.js for your next project just because someone said it was cool. Use a language you’re already familiar with, or pick one up based on its merits for the given project. Just don’t sweep Node.js aside because someone who doesn’t know any better thinks it’s crazy to use anything other than Java.