Vert.x is an asynchronous application server – which may prove useful as architects rethink the server’s role in a world of powerful clients. Does the JVM have a role going forward? Some might say ‘no’ to the JVM. Many say ‘Yes’. Some of these might say: “Vert. x could be described as Node.js+ for the JVM.”

But let us view some from the Cholakian post:

One might say that if all Vert.x consists of is Netty+Hazelcast, that it’s nothing revolutionary. The reality is that Vert.x gets the API right, which most of the existing JVM tools get very…. very… wrong. Even simple services in Netty takes large amounts of code, an inordinate of factories, providers, and threadpools must be created just to do simple things. Mixing all this up with languages like jruby is just prohibitively painful. APIs can be as hard to design as implementations are to write!

On top of the API, the other half of the secret sauce is in Vert.x’s leveraging of high performance implementations of Ruby, Javascript, and Groovy. By integrating them into a single Vert.x executable, they’ve given developers the ability to write high-performance code on the JVM without knowing much about the JVM or its ecosystem at all. Vert.x can run any of those languages directly. Furthermore, since Vert.x is just a library, any JVM language can leverage it. On top of that, the entire universe of JVM libraries, concurrency APIs, and tooling is available to developers.

Like all things, your mileage may differ. The blogger notes : This model is great for large numbers of sockets and file descriptors, where it makes the best use of resources. However, it’s very confusing and complicated when it comes to day to day business logic, where simple, blocking, threaded code is a welcome comfort.  Read all about it as Andrew VC goes through the Vert.X/Node.js ropes.

Go to Source

Go to Source

Go to Source

Go to Source

Go to Source