Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Q&A With the Vert.x Team

DZone's Guide to

Q&A With the Vert.x Team

For developers looking to break free from their application servers, Vert.x provides an exciting new paradigm as the Vert.x development team explains in this Q&A.

· Big Data Zone
Free Resource

Need to build an application around your data? Learn more about dataflow programming for rapid development and greater creativity. 

For developers looking to break free from their application servers, Vert.x provides an exciting new paradigm as the Vert.x development team explains in this Q&A.

What unique features and benefits does Vert.x provide for traditional server-side developers?

Vert.x has a number of unique features compared to traditional development based on application servers that represent a total shift in development paradigm. A developer using Vert.x will tell you that this un-opinionated aspect is one of its strongest points since you are not constrained by any strict structure. You can develop what you think will better solve the problem you're facing.

Other developers, however would refer to its high availability and scalability out of the box as a unique feature since from the development perspective they do not need to change their code to scale from one to many machines.

Some developers would advocate Vert.x because of its polyglot aspect. Vert.x applications can be developed in Java, JavaScript, Groovy, Ruby, and Ceylon. They can mix several languages to always pick your favorite or the best fit to the task.

However this is not it, the reactive aspect will save hours of debugging sessions since with Vert.x you are guaranteed to run only on one thread and the typical thread safety/debugging issues are a thing of the past, or should we say, application servers.

How does Vert.x compare to other technologies like Node.js?

Both Node.JS and Vert.x have about the same performance curve. Vert.x uses a Java Virtual Machine, which executes code slightly faster than JS, but with higher memory consumption. Both Nodes.JS and Vert.x are implementing a reactor pattern based on an event loop. On this aspect, Vert.x handles several event loops so the application can use optimally all CPU’s core in a single process.

If we keep performance aside, the second choice to make is that of finding which programming language fits your project the most. Both Node.JS and Vert.x support dynamically typed languages such as JavaScript, however Vert.x also supports Java, Groovy, Ruby and Ceylon to name a few.

Dynamically typed languages offers ability to iterate and prototype quickly, while Vert.x differentiated from Node.JS by also offering static typed languages (Java, Ceylon, etc). Static typing offers unparalleled refactoring abilities and that you have only in Vert.x.

Most will probably find Node.JS to be easier to start with since being Vert.x a rather young project its ecosystem is not comparable to Node.JS one. Performance wise, from benchmarks it looks like Node.JS frameworks lack behind severely.

But this is not all, Vert.x brings more than just a event-driven model to the JVM; out of the box developers get cluster support, high availability and scalability over all CPU cores and network nodes in your deployment.

From the look of current state of things, with choice being made between Vert.x and Node.JS, Vert.x is more appealing as it is offering out of the box features that Node.JS lacks such as scalability, high availability, native distribution, etc. The learning curve is not that different for both platforms since they are both promoting an asynchronous model, and, with Vert.x, you are not limited to the JavaScript language.

What benefits does Vert.x provide over a traditional application server?

If we can describe Vert.x in 5 words they would be:

  • Framework

  • Un-opinionated

  • Reactive

  • Polyglot

  • Distributed

When you look at these words and try to compare against an application server you notice that you cannot do that.

Vert.x is a framework so it means that your application does not need an application server, in fact it only requires an installed Java Runtime Environment on the host machine. This simplifies a lot the OPS-side of the work. It is un-opinionated in the sense that the developer is king, she can decide which other component, library or piece of code to use. Vert.x does not mandate any specific structure or build tools. For example as a developer you are not bound to use a specific build tool, in fact you can use Apache Maven, Gradle, Apache Ant or even NPM or your custom scripts.

Now what really makes Vert.x different from an application server are the remaining items: Reactive, Polyglot and Distributed.

Regarding the reactive aspect, in an application server, the supports for is provided in the form of multi-threading. Each user-request is mapped to a thread, which takes care of responding to the user-request. The application developer writes his application as if only one user was using it. However there are disadvantages to this model:

  •  There is a computing overhead in constantly switching threads.

  •  There is a linear relationship between the number of threads and the memory used, because at minimum each thread gets a stack allocated to him. A stack uses memory.

  • Thread safety is always a pain point and hard to implement.

Vert.x takes a different road when building modern applications, one that accommodates more user-requests and longer-running user-requests by providing better CPU and memory usage. Vert.x addresses these requirements with asynchronous event-driven non-blocking I/O: it uses a single thread that handles all user-requests, but outsources all I/O operations so they do not block the thread.

With this model Vert.x can handle thousands of concurrent user-requests easily with very little memory.

Vert.x is polyglot which means that developers can use the language that best suits the problem domain they are trying to solve. Say for example that a team of developers has very strong knowledge on JavaScript then you can use JavaScript, however for some reason the team implementing some data storage service has better knowledge of Java or Apache Groovy then they should write it in Groovy.

And this brings us to the last point that Vert.x is by nature distributed. All services communicate over an event bus, this gives the developers horizontal scaling out of the box. Since Vert.x can support many languages the messages on the event bus are usually in JSON format and this is the key that allows all this flexibility. It’s also a key feature to implement micro-services based applications.

What are the best resources for developers looking to learn more about Vert.x?

Vert.x is quite new project so you will not find many published books about it. There are some, however the project is evolving quite fast and probably developers would find the project website http://vertx.io a good source of information as well the GitHub example repository https://github.com/vert-x3/vertx-examples.

If you're looking more into presentations and videos then on the project website there are a list of presentations done not only by the core team but also by community members. This should show that there is lots of interest.

Finally, there is a blog (http://vertx.io/blog) where technical articles are posted regularly. We can mention the “Introduction to Vert.x” blog post series (http://vertx.io/blog/my-first-vert-x-3-application/) that provides a step by step introduction to Vert.x and its ecosystem.

Check out the Exaptive data application Studio. Technology agnostic. No glue code. Use what you know and rely on the community for what you don't. Try the community version.

Topics:
java libraries ,polyglot programming

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}