Do you know anything about Reactive Programming? Before discussing with Clement Escoffier, I didn’t. Now that I have, I can’t wait to try more playgrounds on it on Tech.io.
For now, you can find two playgrounds on Vert.x created by Clement on Tech.io:
Let’s discover Reactive Programming with Eclipse Vert.x!
[Thibaud] — If you had to describe Reactive Programming in a few words, what would you say? How does it make a difference?
[Clement] — Reactive programming is a way to implement asynchronous applications. When using reactive programming, you handle “data streams” and observe the propagation of changes. It can be seen as a “push” model, where your code reacts to events pushed by other entities (software, hardware, external entities…).
It’s a big shift in how we build software. Synchronous code, while being a bit simpler to read and write, can become very onerous in terms of resources when you need to handle a high level of concurrency. This is because traditional synchronous execution models use a “1 thread per request” paradigm. It means that if you want to handle 10 000 requests at the same time, you would need 10 000 threads, which is very expensive in terms of memory and drastically impacts your performance due to many context switches. Also notice that in IO-intensive applications, most of these threads are going to be blocked, waiting for IO events.
When you write asynchronous code, you don’t have to use the same paradigm. You can reduce the number of threads, and do not block these threads when doing IO. Indeed, instead of “waiting” for a result, you are notified when this result is ready.
Asynchronous applications are not new and have existed since the early ages of computer science. However, there is a small issue with asynchronous code: it can be very hard to read and write. There are many ways to deal with this, and one way is reactive programming. Instead of considering each event individually, you consider a stream of events. You also produce a stream of events. So another part of your code subscribes to these streams and is notified when something interesting happens. Using this abstraction makes the composition of asynchronous events easier to, for instance, chain asynchronous actions, or run several actions concurrently.
While reactive programming is a development model, we have several implementations today, such as Reactive eXtensions, or the Elm language.
[Thibaud] — What about Vert.X ? What’s your role in it and how many people are involved?
If you wonder about how Vert.x compares to more traditional frameworks, the first point to consider is reactive end-to-end. Vert.x promotes the reactive model before it becomes trendy. The Vert.x ecosystem gives you a huge number of asynchronous non-blocking APIs, offering almost unlimited possibilities. It makes Vert.x incredibly flexible – whether it’s simple network utilities, sophisticated modern web applications, HTTP/REST microservices, high volume event processing or a full blown back-end message-bus application, Vert.x is a great fit. Finally, and for me, it’s the most important point; Vert.x is about freedom. It does not tell you how to build your application, what’s the “correct” way, where to put your source files. Vert.x gives you the bricks to shape your system as YOU want. YOU are back in charge.
The Vert.x community is amazing and it is growing. Today, on the whole ecosystem, we have more than 1000 contributors, 19 component maintainers, and 5 core developers. I’m part of this last group and manage the different contributions we receive on a day to day basis .
[Thibaud] — You are also the creator of Wisdom Framework, a high velocity web framework to build modular and dynamic applications in Java based upon Vert.x. What impact will this experience have on the Vert.X project?
[Clement] — When I was building Wisdom, I switched from Netty to Vert.x because it was easier to use and understand in terms of code. However, it’s still an asynchronous model and is not necessarily easy to grasp. I’ve tried in the past few years to make Vert.x easier to use by providing tools, examples, documentation and learning material. My academic background probably helps. We made huge progress with our quickstart experience and more advanced documentation.
[Thibaud] — What do you see in the future for Vert.X ? What are the next steps?
[Clement] — Vert.x ecosystem continues to grow and will continue to grow with new components for different use cases. For instance, in the past few months, we have received a lot of contributions around IOT protocols, making Vert.x a great choice to build an IOT gateway. Before that, we built everything required to make reactive microservices. It’s important to note that it’s hard to predict the future in such a thrilling community. Contributors come with very interesting and novel use cases and approaches – and we love that!
In terms of core functionalities, Vert.x will continue to give you the freedom you deserve as a developer. But, as you know, with great power comes great responsibility – so we will continue to guide you to avoid common mistakes and pitfalls to make the experience from dev to production even smoother. We continue to improve the different languages and APIs we provide. For instance, we are cooking RX Java 2 and Kotlin co-routine support – both are almost ready! So stay tuned!
[Thibaud] — You chose to write a tutorial for Vert.X on Tech.io. What’s your feeling about the platform?
[Clement] — As I said before, Vert.x is about freedom. And once you benefit from this freedom, it’s hard to use any constraining tool. Tech.io offered me the freedom I was looking for. We were discussing with the rest of the Vert.x community how to improve our learning experience with a more “embedded” and “zero-install” setup. At the same time, we were looking for a very customizable platform because we can have seriously crazy ideas… and Tech.io made it.
With Tech.io, we were able to promote the learning experience we were thinking about. The developer starts an HTTP server in its code, and can immediately test it using a slick HTTP client – from his browser.
[Thibaud] — How can we improve the platform to see more reactive programming on Tech.io?
[Clement] — Without going into too much technical detail, it would be great to give a bit more flexibility in terms of syntax — sorry, I’m an asciidoc fanboy — and in the runner (configure timeout). About this second point, I can already work around the issue by providing my own runner. That’s exactly the type of feature that makes Tech.io great for Vert.x.
[Thibaud] — Thank you so much, Clement, for having answered my questions and helped us discover reactive programming through Vert.x.
Don’t hesitate to ask questions to Clement below; he’ll be glad to answer. In a few weeks, we’ll continue to explore more reactive programming with a focus on Reactor 3! To be continued!