According to the official documentation Vert.x is a framework that helps you to build reactive application. « Reactive » is defined more or less precisely in the “Reactive Manifesto” which describes what behaviour a system should have in order to build softwares able to meet today’s challenges. Today’s applications have to handle more and more concurrent connections, access growing data sources while meeting user’s expectations which are more and more exigent in terms of response time and availability.
Now we’re expecting that a website directly push information that may interest us without requesting it. Yesterday when we were on a forum application we had to refresh the page to see if something new has been posted. Today we are expecting that the page displays new data in real time without any user action. Moreover we’re expecting these applications being accessible through different ways on different platforms (web browsers on desktop and mobile, mobile applications). We must be able to stay connected every time, every where.
With these today’s requirements and features the traditional « thread per request » approach reaches its limits in terms of scalability and efficiency. Long connection polling for realtime notifications requires one thread per user which is not acceptable.
Like node.js, Vert.x has an event-driven architecture and implements the reactor pattern to handle concurrent requests. So the goal is to receive concurrent requests and to put them on a queue. An event-loop will dequeue each of these events and dispatch them sequentially to an handler. The process of these events by the event loop is synchronous – one by one. The handlers are asynchronous. Something very important to understand is that the event loop and the handlers are executed in the same thread. So the golden rule is that a handler must never block. If it blocks for some reasons (access to a database, file or external service) it blocks the process of all other requests, events.
A vert.x application involves small number of thread so it consumes less memory and lose less CPU time during context switching. Its event driven architecture will help you to create more scalable application than if you did it with another framework based on the traditional “thread per request model”.
Unlike of node.js, Vert.x will create as many event-loops as the number of available CPU cores.
An hello-vertx example
Let’s take the example of the the vert.x website homepage:
What we are doing here is to create a http server listening on the port 8080. Vert.x will transform all incoming http requests in events and put them on a queue. The event event loop will then dequeue one by one each of these events and call the registered handler. In this example java 8 lambdas is used to create one that just creates a response with an http header and “Hello from Vert.x!” as body. The end of the response produce an event which is queued before to be processed by the event-loop and dispatched to the handler that will send it to the client. Every thing is an event in Vert.x.
In real web applications handlers will probably access a data source or call other services. The operations of dequeuing of incoming events and the calling to the registered handlers are done in the same thread. So it’s why handlers are asynchronous and must never blocks!