Tutorial: Reactive programming and Eclipse Vert.x
This is the second of a four-part interactive tutorial on reactive programming and Vert.x. The tutorial can be viewed in full at developers.redhat.com/coderland/reactive/.
The reactive system built in this exercise represents data about the Reactica roller coaster at Coderland, an imaginary theme park that showcases modern technologies and techniques. The Reactica system contains multiple components that use Red Hat AMQ, Red Hat Data Grid, and the Vert.x event bus to pass data asynchronously. The end result is a web UI that calculates the current wait time for the coaster based on the number of people in line, the length of the ride, and how many people can ride at once.
The web UI also displays a list of users. That includes park guests who are still in line, guests who are currently on the ride, and a few of the guests who have already ridden the coaster. The entire display is driven by a sophisticated infrastructure that illustrates the power and flexibility of reactive programming.
Your assignment: Build the web UI that shows Coderland guests how long they'll have to wait before experiencing the awesomeness of the Reactica roller coaster.
Repositories
Articles
Other Resources
Transcript
The following is a Coderland presentation about our newest attraction, the Reactica roller coaster.
Hello! This is Doug Tidwell for Coderland. This video is a quick introduction to reactive programming and the Eclipse Vert.x toolkit. Most of the Reactica code is written using Vert.x, and all of it creates a reactive system of components that work together to get something done.
So, let's talk about reactive programming. Here's my favorite definition:
Reactive programming is programming with asynchronous data streams. [Abraham Lincoln]
Actually that's from Andre Staltz's reactive tutorial, which is awesome [see red.ht/2Skub5J]. The key idea here is that we have producers and consumers of data, and they interact with each other by passing data through some sort of messaging system. Typically producers and consumers never call each other directly, they communicate by sending messages. In this example, we'll do that with Red Hat AMQ and Red Hat Data Grid.
The Reactive Manifesto [reactivemanifesto.org] defines four characteristics of reactive systems.
One, reactive systems are responsive. Uh, yeah. Every system is designed to be responsive, but in the case of reactive systems, what that means specifically is that the system remains responsive even if parts of it fail. When we deploy and run the final application, we can start and stop different parts of the system and everything else keeps working.
Two, reactive systems are resilient. Because the message passing we do is asynchronous, we never have a component waiting on a response from another component. Again, that means one part of the system can fail without bringing down the rest of the system.
Three, reactive systemsare elastic. If a component has a change in the amount of data it has to produce or consume, we can scale that component up or down as needed. If you think that sounds like a job for OpenShift, you're on the right track.
And D, reactive systems are message-driven. As we've said already, we're using asynchronous message passing throughout the system.
Here's a quick look at the architecture of the Reactica system. There are producers and consumers of data. They use AMQ and data grid to move data around. Also notice that some components are both producers and consumers. The Queue Length Estimate component, for example, gets data from the data from the data grid, it consumes that data, and produces new data that it sends to AMQ.
That's as much as we'll talk about the theory behind reactive systems. Before we go on, we'll take this opportunity to praise Clement Escoffier's excellent book Building Reactive Microservices in Java [see red.ht/2Srh3Mt]. Available for free -- Yes, for free! -- from the Red Hat Developer program, it's a great way to dig deeperinto both reactive programming and Vert.x
And speaking of Vert.x, it's time to speak of Vert.x. Vert.x is a toolkit for writing reactive applications on any JVM-supported language. We'll use Java here, but you can use other languages as well. The toolkit is lightweight, fast, single-threaded, and non-blocking. Your Vert.x applications can be their own web servers, much like the combination of Node and Express, and finally, Vert.x is modular, meaning that your application only contains the modules it needs. If your app uses Kafka, include the Kafka JARs as a dependency; otherwise, Kafka support won't be part of your application.
But, to this point, we've just been talking. (Well, actually that was just me.) Let's look at some code now!
[Code on screen: int x = 7;]
We'll, that was fun, wasn't it? Let's look at some useful code. Here's a sample verticle that does two things at once, each of which is independent of the other. The vertx-starterpackage is available on GitHub at the URL on your screen. [https://github.com/redhat-developer-demos/vertx-starter] The verticle only has two methods, start() and stop(). We override both of them here.
start() uses the Vert.x methods setPeriodic() and createHttpServer(). setPeriodic() defines some code that should be run in this case every two seconds, while createHttpServer(), as you might think, creates an HTTP server. That server simply returns some text whenever you open localhost port 8080.
Now clone or fork the repo and run mvn clean package at the command line. Run java -jar and the name of the JAR file in the target directory. You'll see a display like this: Notice that setPeriodic() prints a message ever two seconds, as we asked. Now use your browser or curl to open port 8080. You'll see a message that indicates which host invoked the service. Finally, type Ctrl+C to kill the code. Notice that because we overrode the stop() method, the stop() method is run before the code is killed.
That's the basic structure of a verticle. Obviously the verticles we'll work with here do much more complicated things, but you'll see this structure over and over. The start() method usually sets up connections to the infrastructure and possibly creates more verticles. From there, we let the code do its asynchronous thing.
So, enough background. In our next video, we'll take a look at the architecture of the system and see how the different components work together to generate the data we need to build the web UI.
Thanks so much for watching, and be sure to keep going with the next video.
For Coderland, this is Doug Tidwell, saying May all your bugs be shallow. Cheers.
