 The following is a Coderland presentation about our newest attraction, the Reaktica Roller Cluster. Hello! This is Doug Tidwell for Coderland. This video is a quick introduction to Reactive Programming and the Eclipse Vertex Toolkit. Most of the Reaktica code is written using Vertex, 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 is my favorite definition. Reactive Programming is programming with asynchronous data streams. Actually, that's from Andre Staltz's Reactive Tutorial, which is awesome. 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 defines four characteristics of Reactive Systems. One, Reactive Systems are responsive. 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 Systems are 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 Q-length calculator component, for example, gets 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 Clémentes-Goffier's excellent book Building Reactive Microservices with Java. Available for free, yes, for free, from the Red Hat Developer Program. It's a great way to dig deeper into both Reactive Programming and Vertex. And speaking of Vertex, it's time to speak of Vertex. Vertex 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 Vertex applications can be their own web servers, much like the combination of Node and Express. And finally, Vertex 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. Actually, that was just me. Let's look at some code now. Well, that was fun, wasn't it? Let's look at some useful code. Here's a sample vertical that does two things at once, each of which is independent of the other. The Vertex starter package is available on GitHub at the URL on your screen. The vertical only has two methods, start and stop. We override both of them here. Start uses the Vertex method setPeriodic and create HTTP server. SetPeriodic defines some code that should be run in this case every two seconds, while create HTTP server, 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 Maven 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 every 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 control 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 vertical. Obviously the verticals 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 verticals. 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.