This is the final post in a series of 3 about my first experiences with Node.js. In this post I will discuss my final thoughts from these experiences. If you haven’t read the first two articles in this series, you can view them here: Experiences with Node.js: Researching Node and Experiences with Node.js: Porting a RESTful Service Written in Java.
New Twist on
Old Mature Tech
In my experiences, the Node.js server versions I used were very solid. Honestly, I was very surprised by this. My early assumption was that server stability would be an issue. Not once through my testing did it randomly fail for reasons other than issues in my own code. Although my team jokes about its big selling point of being “fast”, I was pleasantly surprised by how well a single threaded process performed in this space.
The benchmarks I completed in the previous post put a single threaded Node.js up against a multi-threaded Java service and the results were very similar to one another. To my excitement, this on-par performance occurred while the Node.js service consumed far fewer system resources. After some feedback, I am planning on a follow up which will run the same tests against a multiple Node.js threads and a single Java thread.
However, my first benchmark of my Node.js service fell significantly short of the Java service. My investigation narrowed down the bottleneck to be in the Sequelize ORM module. I worry that the maturity of some of these plugins may prove to be an issue for developers. Modules should be thoroughly researched and tested before use.
On the flip-side, there are many Node.js modules that serve the purpose of increasing performance. I have plans to investigate them as I would like to see just how much power Node.js really has. I am left to assume that if more threads or additional node processes of Node.js were spun up, that it could dramatically outperform the Java service.
The Learning Curve
Unfortunately, I found that finding high quality tutorials and information on Node.js was difficult as these resources were scattered and many were already outdated. There was little published material when I first started this research. Fortunately, the library is growing quickly and there are many resources being published. The Node.js scene is quickly increasing in popularity and I don’t expect it to be so difficult to find good information before long.
The Module Mess
The best and the worst part of Node.js may be the modules. There are so many different modules available to extend Node that it can make your head spin. Using the Node Package Manager (NPM), these modules can be searched and easily installed. Unfortunately, many of the modules are incomplete or the projects have gone stale. It is very difficult to weed through them and determine what is good or worth trying. This process is filled with a lot of trial and error. Developers should take caution in using these modules. Research and thorough testing should be completed to evaluate any plugins that you might want to use.
In my research, the most popular ORM on Node.js, Sequelize turned out to be a significant bottleneck. This is very concerning that a popular module suffered from this type of performance issue on relatively small amounts of data. I hope that this mess will mature and the bad, dead or stale projects will be weeded out over time. Although I believe the open model for handling modules drives innovation, it also has the potential to cripple long term adoption.
Fitting Into Existing Infrastructure
Although not a significant focus of my research, the server teams will undoubtably want to know how Node.js will fit in to the existing infrastructure. I don’t see traditional server-setups changing things too dramatically from an equipment or services stand-point. Most monitoring software supports watching at the process level. Scripts could be written to easily handle toggling or communicating with the Node.js server. There also seems to be some modules and suites with some basic monitoring and support. I look forward to doing more research in this area. Some cloud services offer native Node.js support if you aren’t interested in hosting your own equipment.
Although I find Node to be a fascinating product, I believe that it will be hard for companies at an enterprise level to seriously embrace Node.js in the near future. Overall, the core Node.js project and its modules are in their infancy and are not very mature. The detailed list of performance updates and fixes released at a bi-weekly basis are enough to signal that the product is not ready for serious large scale application usage. If Joyent does not feel that the product is ready to be blessed with a version 1.0, how can any developer or server administrator feel comfortable running an important application from it?
Developing software against a product with a rapid release cycle can be a nightmare. I chose to update my node server 4 times durring the process of porting a Java service. There were 2 releases at the end of my research that I didn’t make the update to. By the time your software is complete, you could be working with a very outdated version of Node. No server administrator or developer should have to rely on a server that may need patched on a bi-weekly basis. There absolutely needs to be a stable release and patch cycle created before this can be deemed enterprise ready.
I also worry about the effort necessary to properly research and test plugins for use. Enterprise Architects and Project Managers will not be willing to give up the significant research time in a project to necessary to find and add modules when this is much more mature in other environments that businesses are already comfortable with.
I want to be clear: I am absolute NOT giving up on Node.js and I am not saying that it isn’t useful now. What I am saying is that before I can endorse using it for anything large-scale and serious, wait for the project to mature and the development to slow down. I expect this to happen sooner than later. There is plenty of love in the community for it and developers are very passionate about the product.
In order for Node.js to gain maturity, I believe that Joyent or someone strong in the community needs to better control module management, tutorials, information and the social community in order to provide some stability to the project. I don’t forsee the project strengthening until this happens.
Fortunately, the benchmark results gave me a strong reason to finish out the Java service port and test against the rest of the CRUD functions (create, update and delete) to see if there are any differences there. Some comments on my previous post raised some good points and I would like to to see the numbers by increasing the number of Node.js threads and/or processes. I will provide a followup post with my results.