Julien Viet on Reactive Programming with Eclipse Vert.x, Including 3.5.0, History, and Future Plans

What’s new in Vert.x 3.5?

• 1:50 The key feature in Vert.x 3.5 is support for RxJava2 — we have supported RxJava1 since the start.
• 2:05 The other key feature is support for Kotlin co-routines. 

What’s new with RxJava2?

• 2:20 It has been rewritten with support for the reactive streams library. 
• 2:25 Mostly it’s the same API, but in a different package.
• 2:35 One of the key things is back-pressure support - it wasn’t added in the initial release of RxJava, and was added later.

What about Kotlin co-routines?

• 3:00 We had a very similar API already available called vertx-sync, and Kotlin support was added in Vert.x 3.4.
• 3:30 The zookeeper maintainer was interested in adding co-routine support and so added it for this release.
• 3:40 My job as project lead was to review and help improve it, but it’s a contribution to the project.
• 3:55 I'm going to talk at Kotlin Conf on co-routines.
• 4:25 JetBrains and Romain used the well documented co-routines support and added it into Vert.x.
• 4:35 It's well integrated into the compiler, and in the IDE - so it’s totally transparent to the user.
• 6:25 The key part is the integration of the Vert.x event loop with Kotlin co-routine support.
• 6:40 We also have support for specific types - read and write streams, for example.
• 7:00 You can use these as channels to read and write steamed data.

What’s the history of Vert.x?

• 7:35 Vert.x was created by Tim Fox in 2012.
• 8:00 Tim went to Pivotal to work on RabbitMQ.
• 8:15 If you take Node.JS, Erlang, messaging, actor model, Netty and shake them together, you end up with something that looks like Vert.x.
• 8:40 One of the goals was to provide a Node.JS-like model for the JVM.
• 9:00 Vert.x is based on Netty and uses its event loop.
• 9:10 Vert.x provides an asynchronous and non-blocking programming model.
• 9:15 Those are the kinds of properties that you need to use with reactive programming systems.
• 9:35 On top of that it’s a toolkit to write distributed applications.
• 9:40 It provides primitives like counters, shared locks, distributed data.
• 9:45 There’s an event bus which is used to distribute events in the application.
• 9:50 For example, you can use a bridge to route events from the browser to the application or between languages.

What’s a Verticle?

• 10:25 You can use an HTTP server or client in a Vert.x application.
• 10:50 When your application becomes bigger and you want to modularise the application, that’s when Verticles become useful.
• 11:00 A Verticle has two roles; to encapsulate logic, and to scale an application.
• 11:15 When you create an application, Verticles are used to create different parts of your application which communicate through the event bus.
• 11:25 When you deploy a single Verticle, it is given its own event loop.
• 11:40 If you want to deploy the Verticle to different nodes, they have their own event loops, so you have scalability.
• 12:00 Instead of sizing thread pools, you scale by modifying the number of Verticles deployed.
• 12:15 You can distribute your application and move Verticles in different VMs to different nodes, because the event bus provides location transparency.

What is the event bus?

• 12:45 If you’re in the same JVM, sending a message is just moving that message between two event loops.
• 13:00 It’s a very efficient way of processing messages - the event loop can be running on one CPU core, and off-load the message to another event loop on a different CPU core.
• 13:05 When you start to distribute your application, the cluster manager provides the topology and as a result can route messages to the appropriate location.
• 13:35 There are different providers for the cluster manager; the Hazelcast one is the default implementation.
• 13:40 There’s also an Infinispan provider, and contributions for Apache Zookeeper and Apache Ignite.
• 13:55 Once Vert.x knows where to send the message, it uses peer-to-peer communication.
• 14:05 The protocol is a custom one which uses prefix length encoding.
• 14:15 I would like to write a plug-in for Wireshark that decodes the protocol, but I haven’t had time.

What languages does Vert.x support?

• 14:40 Vert.x has been polyglot since the beginning.
• 15:05 When you use the Vert.x core API, it’s all written in Java.
• 15:15 We provide shims for different languages, and we try to respect idioms of the language as much as possible.
• 15:35 For example, the Scala support uses Scala Futures for doing asynchronous support.
• 15:54 When you use JavaScript, it will be a function - because that’s how you do that in JavaScript.
• 16:05 When you’re running on a JVM language, you’re using the Java implementation.

Why did Vert.x decide to be unopinionated?

• 16:45 When you are opinionated, you have to force people to do things in a certain way.
• 16:50 But you can take Vert.x and use it with Spring, or even Java EE.
• 16:55 Vert.x is just a library; it’s not framework - so we don’t impose certain protocols.
• 17:15 Vert.x is very modular; we have a lot of different libraries.
• 17:20 If you only use Vert.x core, then the only thing you are paying for is Vert.x core.
• 17:30 We try to keep the list of dependencies very low, because we don’t do classloading.
• 17:35 We recognise that classloading is a problem that we don’t want to solve.
• 17:40 As soon as you try to do classloading, there is always another framework that wants to do classloading.

Does Vert.x support Java 9?

• 18:50 It does in classpath mode, yes.
• 19:00 Most of the libraries work well with Java 9 - but there are a few libraries that don’t work well.
• 19:10 Those are the ones that do classloading.

What does getting started with Vert.x look like?

• 19:35 Vert.x is a set of libraries; it’s not a framework.
• 19:45 You can create a Maven or Gradle project, and add dependencies.
• 20:00 You can test with JUnit, and create HttpServer or HttpClient.
• 21:00 For users, we provide two GitHub projects that you can clone to get started.
• 21:30 We also have a GitHub repository that provides examples of the APIs.
• 21:55 The Vert.x website has a tool that you can use to generate a project.
• 22:15 Documentation and examples are important things provided by the Vert.x project.
• 22:40 We also have a gentle guide for developing asynchronous applications.
• 23:15 There’s an O’Reilly book, which shows how to create microservices applications using Vert.x.

What about authentication?

• 23:45 We have an authentication module that provides authentication.
• 23:55 We can use either Vert.x web for website authentication or for shell with ssh authentication.

Where is Vert.x being used?

• 24:2524:25 Whenever I go to a conference, I see Vert.x being used a lot in production.
• 24:35 There’s a list of companies using Vert.x on the website, which we created for Vert.x 3.0.
• 25:00 It tells a lot about the current usage of Vert.x.

What’s on the roadmap for the future?

• 25:35 Vert.x 3.0 was released a couple of years ago, and we’ve been developing point releases since.
• 26:05 Our mission is to provide a fully integrated reactive ecosystem.
• 26:20 When components are important, we try and provide a convenient API for the user so that they don’t have to worry about threading.
• 26:40 We can look to provide more database access, NoSQL and so on.
• 26:50 We don’t have out-of-the-box solutions for Cassandra or CouchBase, for example.
• 27:05 We’re starting to think about Vert.x 4.0.
• 27:15 Vert.x is an Eclipse project, and we have a good community of contributors.
• 27:35 For example, Vert.x for Scala was fully developed by a contributor.
• 27:55 When we start to think about Vert.x 4.0, we’ll involve the community.
• 28:05 Eclipse plays an important role; it tries to involve the community, even when the main commercial sponsor is RedHat.
• 28:30 We had a face-to-face meeting last year, and it was a good opportunity for both the developers to meet; but it was open to anyone, so we had contributors coming along as well.
• 28:45 With 4.0 we’ll look to do this again; to find out what we’re doing well and where to go.
• 29:00 It will be an opportunity to think about what works, and what doesn’t work and can be improved.

Mentioned:

• Kotlin
• Vert.x