[Node.js] Why choose NodeJS (over other languages)?

1) What is NodeJS designed for?

NodeJS was designed to create real-time websites with push capability (similar to Gmail). That is why NodeJS works as a non-blocking, event-driven I/O platform.

1.1) I/O-based vs CPU-based Operations

  • Awesome at I/O-based operations 
    • As long as there's an asynchronous library supporting it - which they usually do.
    • Save the computing time for context switching between threads.
    • Don't need to worry about threading (or running out of resources of it) or too many client requests.
    • Good at concurrent connections that have I/O operations.
  • Horrible at CPU-based operations
    • It's important to understand that simple calculations, such as sorting or traversing an array, can be 'heavy' because you are utilizing 1 thread for potentially thousands of client requests.
    • Remember, you only have 1 thread of the event loop. So if you have 1 bad request can block your entire event loop!
    • Worker threads is NodeJS' approach for CPU-intensive tasks. But there has not been a stable version yet.
    • Creating processes is possible, but also more expensive (than if you did multi-threading in a threading language) and hard to communicate with each other.

1.2) IDE & Libraries

  • IDE not as great as mature programming languages, such as Java.
  • 3rd party libraries are not as great, such as relational database-related ones - when you compare it with rails, it comes with already matured Data Mapper, Active Record data access layer, db schema migrations support tools.etc.

1.3) Easy vs Hard language to code 

  • Easy to Pick up
    • Low learning curve - Javascript is easy to pick up because there's so much less things to care about: no threading, dynamic and weakly-typed data structure, everything is in JSON (no class definitions required)...
  • Agreement of Syntax
    • A 'easy' programming language is a double-edged sword. For example, should a defined variable equals to true when we are doing '=='? There are dangers in allowing that.
    • There has been many recent changes in Javascript API in the recent years, such as callbacks vs promises vs async/await. Your team will need to agree with the programming style of Javascript!
  • Poor quality code
    • Javascript is so 'easy' such that you can write really really bad code and it will still work. It is great if you're working on a small project quickly. But it sucks if you are working in a team, especially if this is a product that will live on.
  • Development Speed + JSON-support
    • If you are writing a web application, I think this is super important. In comparison to Java, where JSON serialization is a pain, javascript does this super well.

1.4) Javascript Everywhere

  • Most frontend developers already know Javascript. NodeJS is basically Javascript for server-side. It will be easy to convert a frontend developer to a FullStack for your backend programs.

1.5) Scaling Performance

  • Assuming you are writing a server-side web application, since you are not creating threads/client request, you only need to scale if you are getting a large number of requests.
  • Unfortunately, there are not too many good ways to scale:
    • Multi-threading via worker threads is an experimental module at the moment.
    • Multi-Processing via clustering is relatively expensive (compared to multi-threading - which you can do in other languages). 
  • That being said, you can always use a load balancer.

1.6) Large and Active Community

  • NodeJS has a large and active community of developers creating solutions and libraries on Github. 

2) Good use cases of NodeJS

Anything that is a pick-and-pass along, such as:
  • Chat
    • Pick up from one client and pass to the rest of clients in the channel.
  • Object Database
    • You don't need to worry about converting objects/serialization to JSON when sending results over HTTP.
  • Working with Messaging Queue
    • NodeJS is really good at handling concurrent connections. Since we are not creating threads for each client request, we can handle acknowledgements for messaging queue without much resources.
  • Data Streaming
  • Proxy
  • Dashboard

3) Conclusion

NodeJS is NOT a silver bullet - despite all the pros or cons, it highly dependent on your use case and expectations.

Some things that are for sure (or you should consider) are:
  • It was never created to compute CPU-intensive problems. 
  • It is great at web applications where each request does not take long to compute (I/O operations are asynchronous/unblocked, so it can be considered almost-zero compute time).
    • Traversing an array is debatable, depending on size of array and how many client requests are you processing.
  • 3rd Party library/IDE/Programming language issues - honestly, these are not a big problem as long as you have time and someone is reinforcing it in the team.

Comments

Post a Comment

Popular posts from this blog

[Redis] Redis Cluster vs Redis Sentinel

1) In-Depth Guides to Redis Cluster and Sentinel For more in-depth explanation for Redis Cluster or Redis Sentinel, please read my other posts: Sentinel:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-sentinel.html Cluster:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-cluster.html 2) Deciding between Redis Sentinel and Redis Cluster Similarities : Both solutions provide high availability for your system. 2.1) Redis Cluster 2.1.1) Pros Shards data across multiple nodes Has replication support Has built-in failover of master 2.1.2) Cons Not every library supports it May not be as robust (yet) as Standalone Redis or Sentinel Setup and maintenance is more complicated 2.2) Redis Sentinel 2.2.1) Pros Automatically selects new master in case of failure Easy to setup, (seems) easy to maintain 2.2.2) Cons No data sharding; master might be overutilized. Another distributed system to maintain. 3) So how do I decide? In
Read more

[Unit Testing] Test Doubles (Stubs, Mocks....etc)

Image
In unit testing, isolation is key. The goal of unit testing is to test individual components, and not an entire system . The class/object/function you are testing is System Under Test (SUT) , and the other components of the system are Collaborators or Dependencies. Test Double  is a generic term for any kind of 'pretend' object used in place of a real object for testing purposes.  There are several types of Testing Doubles. We will start with: Fake Stub Mock Command Queries Mocks vs Stubs And then: Dummy Spies Spies vs Mocks I) Basic Testing Doubles a) Fake Fake are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Note that Fake is a generic term - that can point to anything; usually mock and stubs. An example of this is an in-memory implementation of a database. This fake implementation will not access the actual database, but will u
Read more

[Node.js] Pending HTTP requests lead to unresponsive nodeJS

This is a recap conclusion to the potential problems of a NodeJS program I worked on previously. The program simulates thousands of clients navigating a website by sending thousands of http requests to a given API . The idea is to load test a particular API to make sure they can handle high traffic. Because we are simulating clients, it's important to keep track of the state of the simulated client as well. The problem with this program is it is buggy and becomes unresponsive from time to time (the only solution is to restart it). The problem was fixed by re-writing the entire program in Java, but it was regretful that I never had enough time to find the exact reason the nodeJS version of it failed. The following are potential causes I suspect: 1. Exceptions The NodeJS program was not written very neatly and stacked callbacks on top of callbacks on top of callbacks. This made it very difficult to keep track of exceptions and unexpected http responses are prone to happen. So
Read more