I have been evaluating various Java based technologies by writing a news feed micro-service in those technologies and blogging about the Developer eXperience. In this blog, I will turn my attention to the first of many non-Java based technologies where I wrote yet another news feed micro-service implementation, this time in the Node.js programming language.
I wrote the feed, ran some load tests, then compared the results to the same load tests for the DropWizard version. I documented my findings in the PDF at the bottom of this page. Here are some answers to questions about the document below.
| Q: | You said that static vs dynamic type checking has a profound impact on SDLC. Which IDE did you end up using? |
| A: | I used eclipse for all of the other news feed micro-services but I used emacs for the Node.js implementation. |
| Q: | Why emacs instead of webstorm, nodeclipse, or Aptana Studio? |
| A: | A lot of the benefit that you get out of a full featured IDE comes from the fact that the IDE can intelligently parse the code and accurately reason about its types. Since that can't happen in javascript, the IDE just has to guess about types and frequently gets it wrong. |
| Q: | You say that you cannot compile javascript in a way that does type checking but isn't that exactly what the Google Closure Compiler is for? |
| A: | Not exactly. The Closure Compiler can perform type checking but only if you specify the types of everything via jsdoc comments / annotation. |
| Q: | Why can DropWizard code wait for I/O to complete but Node.js code can't? What would happen if you wrote a Node.js micro-service that did? |
| A: | In DropWizard (i.e. Jetty) every request has its own thread. Waiting for I/O to complete blocks only the request that initiated the I/O in the first place. In Node.js, there is only one thread per process. Waiting for I/O to complete blocks all requests queued for that process. |
| Q: | Basically, your recommendation is to go with Node.js if time to market is more important and go with Java if scalability is more important. Is that about right? |
| A: | That is a bit of an over simplification but, yeah, that is about right. Those are the main decision drivers for companies that must standardize on only one programming language. Some companies use the BfF pattern where the APIs, called by clients over the Internet, are written in Node.js. Those APIs, in turn, call more data centric micro-services written in Java. The Node.js services are more concerned about making life easy for the clients. The Java services are more concerned about protecting the underlying data repositories. |
| Q: | It sounds to me like Node.js is the winner. Sacrificing 16% throughput in order to develop micro-services 5 times faster is a good trade in my opinion. |
| A: | I never said that Node.js development is five times faster than DropWizard, I said that the Node.js code is one-fifth the number of lines. A lot of the extra DropWizard code is generated by Swagger. If you adjust for that, then the Node.js project is only 40% of the number of hand written lines of code. |
| Q: | You said you tried to get the Node.js service to log its performance data to Kafka using two different libraries without any success. Which libraries did you try? |
| A: | I tried with both kafka-node and no-kafka but just kept getting some kind of broker unavailable error message. I was using Kafka version 2.11-0.9.0.1 during these attempts which is the same version that works with all the other news feed projects. |
| Q: | How did you measure the performance of the Node.js micro-service if it is not sending its performance data to Kafka? |
| A: | I used Kong and the kong-logger-service to report the data to Elastic Search. The screen shots of the graphs come from Kibana with the query entity:outbound AND operation:POST AND status:200. |
| Q: | Would using Node.js cluster mode have improved that low throughput metric? |
| A: | The 16% lower throughput is with using cluster mode. I ran a load test of the Node.js service without cluster mode. That test resulted in 40% lower throughput. I do recommend using cluster mode. |
| Q: | Do you have any insight into why the Node.js service had 16% lower throughput? |
| A: | Not really. I did profile the service. Most of the CPU time is spent deep in the bowels of the Chrome V8 engine. About a quarter of the time is spent in JavaScript (Inline Cache) and 60% of the time is spent in C++ (I/O). None of my code even shows up in the profiler report. |