Node.js is a new religion sweeping though the tech community. High-profile companies like Paypal and Uber use it to develop their platforms and it certainly deserves attention.
At Stratos we use a mixture of Microsoft and Google technologies to deliver our applications, but we have been following Node for awhile. If there’s an easier, cheaper and better way for us to deliver value to our clients, we want to be the first on that bandwagon!
It’s very simple to start a Node project. The learning curve is small and you can write productive code with minimal set up. This low barrier to entry is a major reason Node has gained such popularity amongst developers.
The idea is that you add complexity as you need it by using packages that you or others have developed. Node has a great package manager that makes it easy to find and maintain packages.
The Node community is extremely passionate about this technology and there are plenty of good resources available. A huge number of packages and libraries are being developed for Node, most of them open source.
But with a large contributor community comes a range of skill levels and it’s important to chose high-quality packages that will be sufficiently supported in the future. Support implications need to be factored into the overall requirements of a system. For larger commercial projects, established vendors are often preferred.
Node has a conceptually simple architecture. A single thread handles incoming requests on the web server. To ensure this thread doesn’t get tied up doing a particular task and hang the application, it delegates tasks to other threads to do work such as reading from disk or the database.
To make this work, Node forces developers to write asynchronous applications. This style of development can be harder for developers to grasp at first and the patterns of use have to be well understood to avoid writing code that is difficult to debug and maintain. The upside is that it can be capable of very high performance and scalability.
One downside of this model is that should a CPU-intensive action such as a calculation or reporting be performed on the main thread, it will block the entire application. There are workarounds but they require a knowledge of threading models and application architecture.
It is worth mentioning that the single threaded asynchronous model that Node uses can be replicated in .Net, which also fully supports asynchronous operations. It is not, however, required in .Net as it is in Node.
For line-of-business applications, reporting is usually a must-have and the Microsoft platform has a very good story around reporting with the SQL Server Reporting Services suite. Node applications, however, usually use a non-SQL database such as Mongo DB, which can make structured reporting harder to carry out.
From a performance perspective, in a real-world application the user experience is not typically dramatically affected by the technology that is used, be it Node or .Net. If you’re writing an application that needs to be massively scalable (e.g. Facebook) and it has very few complex calculations, Node is a good choice. If you’re writing a financial application like Xero, .Net is a better option. (Incidentally Xero is written on the .Net platform.)
The Bottom Line
It’s extremely easy to get applications up and running in Node. But writing applications that will be easy to maintain and scale is never trivial. Regardless of the language and platform, a strong knowledge of application architecture is a must. Node is not a silver bullet and it does not negate the need for experienced developers and architects.
There is little doubt that the .Net suite of technologies is initially harder to learn and be productive with. However once you become accustomed to working with a compiler and the benefits it provides like strong typing and compile time checking, it becomes difficult to imagine writing server-side code without it.
Should we be on the Node bandwagon? For the right application, we would definitely consider Node. However, with our deep understanding of the .Net framework and the types of client requirements we typically deal with, we may be running alongside the wagon for a little longer.
If you’d like to ask any questions about this article or if you’d like to find out more about how we develop software, contact us at firstname.lastname@example.org.