It started with a conversation regarding Node.js as one of my developers has been using it to write a RESTful API. We had spun up an Amazon EC2 server and RDS backend for the service, which is the beginnings of a content shaping algorithm. This rapid prototype has shown real promise and now we are looking at using it as the core to our Facebook Application Homepage. With this in mind I started to think about how this would work in a production environment. This is when I thought back to some recent experiences and quickly decided that Node.js as great as it is, really isn’t the best option for the team or company at this point in time. Here are my reasons why:
Support
Only one developer has any idea of how Node.js works and when there is a problem as there will be one when you are using cloud based hosting. This could be slightly mitigated by having a Wiki. However usually it is out of office hours during weekend support when you find out the Wiki is not quite 100% up to date.
Consistency / Learning Curve
Teams change and as we move forward we need to ensure that our code is written and approached in a consistent way. This will ensure that if a developer wants to get involved with different projects they can easily jump between them. It also ensures that if the person who wrote the code isn’t around supporting it is much easier. Yet another barrier to entry will also only reduce the ability to quickly up-size should the project or team need extra resources.
Agility / Speed
We are an Agile team and working in short iterations delighting our customers is what we do best. By being consistent we become more agile, it aids self forming teams and enables continuous learning. A common approach make it easier for the knowledge to be passed around which amplifies its effect. Working on similar projects allows my team to take those learnings and get faster at doing what they do. The libraries and helpers that are developed can be used in as many places as possible to reduce code duplication and increase testability.
History
My team inherited a custom written CMS solution that we have been supporting for the past 18 months. It was written using Apache Cocoon and GWT as a front end with an Adobe CRX NoSQL solution as the data store. Due to none of these technologies being widely known development was up to ten times slower than it should have been because of the learning curve and lack of consistency. We also chose to use MooTools as a JavaScript framework for our front end and this has restricted the interoperability of our site and it doesn’t get along with jQuery which is what the rest of the web uses.
Lack of a clear benefit
Node.js is a great solution if you have requirements for massive concurrency. However that requirement for our current problem as it will be cached behind Akamai. In this case there is not enough of a business reason to do something different.
As you can see I thought long and hard about this and I hope my conclusions make sense. I am really glad that we now have the knowledge of how Node.js works and when a project comes us that does have a clear benefit I will reconsider. However until then we are going to go with the obvious choice and rewrite this API in Spring MVC to be slightly less bleeding edge.
UPDATE Dec 2013: Looking back on the above post I still think it was the right decision at the time but the flip argument to all of the above is that it would have been great to learn some new technology and get the team enthused about this. Small distinct projects are a great way of trying out new bits of technology. Sure there is a risk associated if it doesn’t work out. However if you aren’t trying new things then you will never know when something better comes along. If I had to make the same decision again I would probably go the other.
Music to Write this Code to
Treasure Fingers brings the type of house sounds I like to the party every time.