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

Like most technologists, I find great joy in learning new technologies… or mature technologies with a new twist. [Note that I am using mature in place of old here. I don’t want anyone away with the idea that is old and washed up. That most certainly is not true.] Writing JavaScript applications in a context other than a browser is very interesting and proves yet again that the language is capable of so much more than showing and hiding sub-navigation menus. If you haven’t had an opportunity to pull down Node.js, I highly recommend any developer trying this out. It may drastically change the way you look at and think about JavaScript.

Overall Performance

In my experiences, the 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 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 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

I went into my Node.js research assuming that because I already know that it would be easy to pick up. Working with JavaScript in a different context was a significant shift and required a lot of research to understand how to work in the new environment. It is true that creating a “Hello World” app was easy, but adding a web server and pushing content out through HTTP required research and understanding that you wouldn’t have coming from the browser world. Because you are working in a different context, the APIs are different and developers will need to learn them in order to work with Node.js.

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, 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.

Enterprise Readiness

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 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.

With all that being said, enterprises should keep a close eye on Node.js. I don’t see server-side as a fad. This is a viable technology that is quick and nimble. This space will undoubtably evolve and mature dramatically over the next year.

Final Thoughts

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.

Keep a close eye on this revolution. Meanwhile, I would get your Java teams onboard with learning JavaScript!

Next Steps

Fortunately, the benchmark results gave me a strong reason to finish out the Java service port and test against the 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.