Tomcat vs Vert.x

Tags: , , ,



For the past few days I have been reading Vert.x documents. I know that Vert.x is polyglot, single threaded, non-blocking IO, modular architecture, high scalability.

Is there any other major differences between tomcat and Vert.x?

Also when we should use tomcat and when to use Vert.x?

Answer

Tomcat is a servlet container, so it offers you a platform that helps you to develop and deploy HTTP based applications like web sites or web services.

Vert.x instead helps you to develop and deploy any kind of asynchronous applications. It’s true that modern versions of Tomcat support asynchronous servlets, but Vert.x comes with a far larger amount of user friendly asynchronous APIs plus other goodness:

  • Complete Filesystem asynchronous API
  • TCP (server and client)
  • UDP (server and client)
  • HTTP(S) (server and client)
  • Shared data service (share objects between polyglot modules)
  • HA and Clustering
  • Cluster-wide messaging (event loop)
  • Event bus bridge (the extension of the event loop to browsers via SockJS)
  • A growing ecosystem of Vert.x modules
  • Possibility to embed Vert.x in legacy code
  • Leveraging the existing rich and solid ecosystem of Java libraries (Vert.x runs on the JVM, unlike Node.js)

Personally I think learning Vert.x is very useful. At work I reused the same knowledge with great success to realise three very different products: a zero-copy ultrafast Redis proxy, a JPA-backed REST API, and a reactive single-page web application.

Have a look at the example code, it’s pretty straight forward and the boilerplate is close to zero.

One more thing: where did you read Vert.x is single threaded? It’s not true! Vert.x has a very neat concurrency model that makes sure all the cores are equally used (again, unlike Node.js).

Enjoy!



Source: stackoverflow