 Well, hello and welcome to another Dev nation. I'm excited today to be bringing you come on come on Is our reactive expert here at red hat all things reactive and reactive programming? So I've certainly learned a lot from come out over the years and I continue to learn He is my mentor when it comes to reactive programming. That's how I like to think of it And more importantly, he's gonna show us reactive from the corkis perspective You guys have been hearing a lot from corkis in our last several episodes You're gonna hear more about that today because it is awesome So make sure you put your questions in the chat tab and for all those people who can't see and can't hear and even see me Right now refresh your browser. Just remember that tell everybody. All right. Well, thank you so much. Come on We'll turn it over to you. All right. Let's me Show my screen real quick There we go so My name is Clemence Coffier. I'm software engineer at Red Hat and in this presentation We are going to see how we can build reactive application with corkis so corkis is corkis is Full stack for Java that has been tailored for the cloud native environment. So that means that we are packaging more in terms of memory consumption and to start very very fast to be very fast to start The stack itself Proposed everything you need to build micro services And even to write function and to execute them in a serverless environment so corkis provides several benefits first it's provide a very nice developer flow with a very fast hot reload You're never entered it. You can modify your configuration run your tests having the hot reload all at the same time It's pretty your velocity is going to hit the sky As I said supersonic subatomic Java super fast to start very small memory consumption, and it's done It's also based on a lot of libraries that you are used to Like vertex or hibernate or a CDI and it's all there already to be used and finally It's what we're going to see today How corkis unifies imperative and reactive in a single start So but what does reactive means and Reactive is actually a very relevant world It started with a reactive manifestos that has been defined by type safe No light band a few years back that they find right to systems and reactive systems are distributed systems focusing on Responsiveness for this all your component of your systems are going to exchange messages and those messages lead to asynchronous code because you don't know when you will receive these messages and So you need to have a way to write code in an asynchronous manner This is where reactive programming Takes place. There is several way to build a synchronous code It go can go from spreadsheets because yes spreadsheets are actually reactive programming for example, you have a Formula that is observing a cell Inside your spreadsheet and if you modify your cell the formula is going to be updated so that it's reacts another way to build a synchronous code is to use events and even some loss like Interaction or sign-offs and stuff like that there can be low level you can use callbacks There is many way to build that you can use actors to Something that is coming to Java in the next few years Let's say is going to be fibers that will simplify or we've write a Synchronous code because we will be able to write it can offer synchronous manner, but it's going to be executed a synchronously reactive programming the pure active programming is based on the idea of Data flow and the pipe of data So you have pipes and you have data inside and you will have publishers that will Feed the pipes with data and consumers that we consume this data As soon as you have this you quickly have an issue if you have a slow consumer and a fast provider So for this we need some kind of back pressure protocol And this is where righty streams come into the place as righty streams define a non-blocking and a synchronous back pressure protocol Be aware that righty strings is very low liver and does not provide any operators and Implementing the righty strings types yourself. It's generally a very bad idea Fortunately, there is several implementation of righty strings that I want you to do that and two of them are part of the same family It's what we call right till extensions typically we have a rich of a two and reactors which are based on righty strings and provide lots of Operators so you can actually compose your program using these operators Okay, but I didn't define what reactive means so far and if you look at the Oxford dictionary reactive means showing a response to a stimulus There is another definition of this which is actually much more interesting for us It means acting in response to a situation rather than creating or controlling it This definition is exactly Where we see the difference between imperative and reactive? Because in some part of work world So the one you generally use well you as a developer control what will be called next Because what will be called next is a method you call or the next line and so on in a reactive world it depends on the messages or Stimuli you are going to receive and you are going to send so you are not really in control of the flow Your environment is in control of the flow Anyway, if we want to define if we want to take this definition we can say that Reactive is kind of a synonym for event driven no because well an event driven program is going to react to event failures And messages which are kind of our stimuli and it's fine But as soon as we have a event driven application We need to think about concurrency because potentially you are going to receive a lot of messages in a very Short-term window. So the first part of the reactive landscape is going to help you to build concurrent applications Here we found writing programming writing strings and both are kind of based on this non-looking and asynchronous idea but we are in 2019 and These days we are not building Standard on application who are building systems when building microservices which are living in a world That contains all their microservices all their siblings So we need to think about how the system is going to be a bit not only a whole the individual components are Going to handle requests and it's where We can see how reactive systems fit in this picture reactive systems is a Architectural style to be distributed systems with one focus one objective being responsive Reactive systems is based on four pillars and the first one is Message driven which should be actually be read a synchronous message. It means that all our components are going to exchange messages This give us two other Characteristics elasticity and resilience as soon as you use messages, you are going to send messages to virtual address Because of this it's very easy to have elasticity as when I send a message I send it to this virtual address and then I can have a queue or broker that will dispatch a load among the set of Subscriber and increase or decrease this number of subscribers depending on the death or of my queue So elasticity is kind of easy in that case resilience comes also from this virtual address ID because we can imagine sending the messages to one Component, but as soon as this component crash having a second one that will replace it Also, we can have a knowledge meant in on our messages meaning that the function processing to message can acknowledge and And and indicate when the message has been processed correctly if you're able to under messages Request and so on when under fluctuating load and when facing failures, you are actually building a responsive system systems that take care of what of Answering those requests in a timely fashion and This responsiveness is very important today for our users because users hate when we are failing systems One very important part to understand is that asynchronous are reactive does not meet multi-threading and when I say asynchronous message passing I don't mean taking a client That use a thread pools and you're in a request there and having this red pools taking care of the business No, that's actually is a very bad idea because Your concurrency is going to be limited by the number of threads you have assigned to the thread pool more threads you have More expensive is your solution for two reasons first each threads have a huge memory cost and Memory is not that cheap anymore on the cloud and the second part is actually it also have a CPU cost because most right you have more time. You are going to spend switching between you of these threats This time of CPU is going to be taken from your quota and taken from your quota is Paying your cloud provider for nothing So a synchronous and reactive is not about multi-threading. It's about never blocking and so relying on Unblocking IO to do all those exchanges Okay, but right now you probably have your microservices using HTTP And we're going to see why it's not necessarily a good idea and how you can switch to messaging so When we build microservices the idea was that each microservice is Independent and run in isolation which means that it should be able to run even if the other microservices are not there This actually felt short when we think about HTTP Because if one of your service is not there then the caller is going to fail and the caller is going to fail and so on Until you get the user getting the error. So of course you say yeah, but error should not Cascade that way and Netflix proposed or popularized a few years back circuit breakers So we should use circuit breakers to protect this to protect the failures to be Cascade and to bubble up to the users Okay. All right. Yes, a good record fix part of the problem However, tuning circuit breaker can be very very hard and most of the circuit breaker you use today's are using thread pools which leads to the Previous slides about being non-blocking and not using thread pools also circuit breakers can Provide fallbacks Well, fallbacks are nice, but sometimes are not very useful Imagine you want to have the balance or your bank account and because this microservice is not there It's going to provide a fallback with the default value for your balance. That's not really useful. So How can you Provide different way to do this and actually it's very simple just use messages and Messaging is there for the last 25 years more or less so There is a Less risk to use such kind of solution in the sense that well, it's there. We know to tune it. We know to use it If you use messaging, you have a few benefits first all the messages are going to be sent in a non-blocking Manor you can even have request reply because if you take protocols like and to pee or rabbit MQ They are supporting or request reply very nicely elasticity as I said can be provided by the same middleware by scaling up and down the number of subscribers and finally the resilience can be done Also the same way using annuletments on having a shadow Microservices that will take over when the first one crush Mentioning also all other patterns that are very important today. So I already mentioned request reply but imagine things like message stream or event sourcing and CQRS they are based on on messages and the ability for your microservices to consume well a sequence of message a stream of message and What react to it for each message or doing some composition of these tricks? It's also enable publish subscribe Which is very useful this day if you need to inform one micro service that something happen in an event-event manner like Every time a user logged in or logged out you want to send an event In order to make Aware of this event You could with HTTP but that will require that the sender knows who is interested by this event, which actually is going to break the The loose coupling So let's speak about quarkus now Quarkus Provide a solution that is HTTP messaging and streaming all in one So you don't have to choose you can really mix All of them and that's what we are beyond the idea of unifying reactive and imperative So typically you will have a synchronous HTTP at some point generally at the gates of your system and In Quarkus is going to be completely non-blocking in a synchronous right now It's based on the undertow and we want to switch to neti and it's a work in progress Once you get a request Quarkus is going to call your application called which is going to use generally resty Jacks RS and CDI and This code can emit messages These messages will be sent to a messaging middleware whatever it is and on the other side You can have another quarkus application that will receive those messages and do some processing of the product So let's demonstrate this imaging a coffee shop a Traditional coffee shop you go to the counter you order a coffee and then you have Well, the waiters or the barista that is there that is get your money and go to the coffee machine Do your coffee and bring that to you Meaning that during that time all those are customers have queued and will be served once I get my coffee This is typically your GDP world completely blocking. I wait to get my coffee Now think about Another type of coffee shop more in the line of Starbucks or narrow or cost a coffee In these coffee shops you go to the counter you order you pay then we give you a receipt with And so on with with an ID So to justify that you pay and as I said tell you that your beverage is going to be ready But later This is typically how we will do it in an asynchronous manner and we are going to build this so Our coffee shop said microservices represents a counter and when you place an order And you are going to be to get a response, but just with the other idea the order is going to be incurred into a Kafka queue which is orders and and then You will have Another queue another topic that is named you actually That will tell you about the state of your orders if it's prepared or if it's ready and so on The orders topics is read by baristas that will prepare your coffee and then send That to the queue topics and so you can get you can retrieve your your your coffee So the first things we want to build when we switch from this STTP world to this Kafka world is Switch to asynchronous STTP so the first things in the whole world will get a endpoint like orders that we get an order and I will use an STTP client to call my Coffee machine and barista to have this order and this return on beverage and I return that to my to my customer in a blocking manner If we switch to asynchronous instead of returning a beverage directly I'm going to return a future beverage what we call in Java a completion state Of course, this means that the processing must be a synchronous and this means that we are going to use an STTP client a true STTP client not an STTP client using Thread pool but really a non-blocking a STTP client which would pass this order in an asynchronous manner The fact that it's not looking is very important here because that means that we don't have thread pool And we don't limit our concurrency based on the number of threads which is our clients can order Okay, but we're still waiting here. Well, at least the customer is still waiting So we're still not where we want and you're right So we need to to improve a little bit our solution the first thing we will do is to return to the to the user's order ID, so like a receipt So if we call this method This endpoint to check service and point we pass an order immediately the counter is going to enqueue this order to To the baristas and immediately gives a computed order ID So we will turn immediately the second part is About sending messages because so far I didn't send messages to do this we are going to use micro-profile waste reactive messaging and in our implementation, we have something called emitters which will bridge the imperative world and the reactive world So typically I can use I can inject an emitter like this with at inject and at stream and this emitter when I call the send method of them is going to emit messages to a channel named orders and By configuration we can say that these channels is actually a Kafka topic Actually, this Kafka topic doesn't have to be named orders It can be named as you want and maybe you also have strong or weird conventions around Your cues and topics naming like I've seen one deployment where all the cues were named after a lot of the ring characters but in your code having a Channels or topics named Gandalf doesn't really mean anything. So anyway Here we have our enqueue missiles that will just send messages To this channel and this will go we will see on Kafka All right, but this was my coffee shop microservice. So representing my counter. We need to have our completion stage our barista microservice Our barista microservice is receiving from the orders queue orders to be Is writing to the queue to be so orders and queue actually challenge in this case We don't know. We don't care if they are to pick you or their behavior So this is actually how a barista is implemented It's as to annotation incoming and outgoing Incoming indicates that I'm reading from this channel and ongoing indicates that I'm writing to this channel and here This method prepare is called for every messages that has been sent on the order of channel And is doing some asynchronous processing on it because preparing some coffee take some time So Here one the code that we are going to show is actually taking some time to prepare coffee to or actually represent how it works The signature we use here, which is for each import I'm returning completion stage is one amount more than 30 of them So we propose many many ways to produce process and consume data some Pair message base so you receive a single message and you return what you want some are synchronous and some allow to Manipulate the streams directly so you can have a stream based operation like windowing and so on the last part of our demo is how we will display that the Drinks are ready and for this we are using the stream annotation again it's a qualifier and I'm going to read the channel beverages and By reading the channel beverages it means that I'm getting a stream and in that case I've decided to use a rectis trims publisher types Because beyond all the streams operation and message operation is certainly rectis trims But you don't have to manipulate it Here I've On purpose Decided to show that to you, but you can use every curative variable or you can use rectis trims operator So you have many different way to inject your strings and to display the Products the ones beverages that have been ready. I'm going to return this stream directly as a server sentiment Okay, so let's have a look at this demo So I have my coffee shop running here I have my Kafka worker running because I'm going to use Kafka. I will go to my swagger UI because Quarkus provide a very nice swagger UI based on open open API and I'm going to order some Expresso and because it's really Starbucks is a actually never were able to write my name correctly. So and So I called it and I get my express of clearance. This is my order ID and if it goes there, this is the last one And what we have here it means that First the coffee shop has in queue the order In the queue topic and we display it as in queue And once the barista took the order and prepared it. It's another message is to The queue to get to the queue topic and we will get it. So let me redo it From a second window so you can really see how it works and this time I'm going to change I'm going to send an express so to burr and actually if burr come new france and says that it's called burr It's probably going to be written like that, which actually means butter, but it's how we will pronounce it I'm sending it and See we immediately have the order in the queue And once Julie so our barista has prepared the The espresso it can get it and it's ready to be Doing We'll quit this. Okay So, okay about orders at work when I have a lot of uh Coffee order so I can order a lot of coffee We'll see that here So and one of the main difference with HTTP Is that all the orders are going to be in queue and one by one processed So it's not really a synchronous request reply Where the first will be served first and then the second one and then the third one and so on here We thank you everything And well it will be delivered when it will be delivered Okay So nice. We have seen how it works. So we we press an order this order goes to two uh two other Topics then we we also indicate that it's in queue the barista read it Prepare it and send the message to the queue topic with the ready state. Okay, but How can we demonstrate the reactive system benefits? Well the first one is To stop the baristas Because typically a barista can take a break or whatever and if I order coffee again My orders are going to be part of my queue But they will never pass ready because I don't have any barista that will Uh, uh, prepare them If I restart Julie Yeah, we start seeing that Julie is taking over and going to prepare all the pending requests Another thing we can do is to have a second barista that I named Tom And as soon as Tom is ready I can include lots of coffee And we will see that Tom and Julie are going to dispatch the Lord. So again, this shows the elasticity So which shows the durability so I'm resilient meaning that if the service is not there No problem. We don't lose the the request so we can process them once somebody is ready to serve them And the second part is elasticity by just starting another subscriber Obviously in our systems, this will be managed by auto scaling So let's back to the slide and conclude So we have seen The resilient part we have seen the elasticity part. So what we built was really reactive systems so Reactive systems is really a new way to build Distributed systems that really focus on responsiveness. Don't lose your state and so on. So it has elasticity resilience and non-blocking message passing as primitives Quarkus gives you everything you need to build reactive systems and to do that it unifies imperative and reactive It does not only let you build reactive systems It gives you a way to do that in a very simple manner where in your code You'll just have a few new annotations like incoming ongoing and so on that will give a very A development model very similar to what you are used to have So with this you can build crud rest and cli using the operative model reactive system and data streaming application using the reactive model and mix both Instead of your same application on same system I think we are already almost out of time. So if you have any question, I will take some right now And if you are more interested by this you can check out the quarkus.io website or chat with the team on Zulip and Of course, uh, follow us on on twitter So, okay, right. All right better now All right. So a couple questions. Okay is the demo code You got a github url for the demo code? So I don't have uber so that's going to be interesting. Oh Um It does seem like here. Let me try this Ah, that was working No, okay. I can take a full cache a shoe question based on uh On their priority. I think that we have a few uh made Is the source code of the from the demo available? Yes, it is available It's on my github repository. Uh, uh, so my my github nickname is cscofier And you will find a quarkus reactive demo and you have exactly everything and you have the instruction to reduce the the full demo Uh, now servlet filter capable of non-blocking request header updates So we ask as some servlets, um support Um, I don't know about the non-blocking request header updates. Um I would say yes. I don't see why we could not do it. So I believe we can but need to be checked Um Yeah, so is there a git repo for the demo? Yes, uh, so just check my github account and Is quarkus to make full reactive application. Can we use eric java or rector? So we support, uh, eric java 2 and a micro profile right extreme operator Which is very everything I did here. You can you can use every java 2. It's uh, it's It's It's flowy ball Your emitter can be a flowy ball too. So if you know how to java 2 you will be Fine Also In a jack servicing point we have seen that we return in, um a completion stage We can also return a single or I don't know about maybe but I believe it's supported too Um, so come on can we Yep Yeah, so i'm not sure if anyone can hear me but the We should just take one more question and then we're out of time and that's the web sphere mq question I think is a good one Yes So can we integrate with uh web sphere mq and as well as using gms. So what's your mq? Yes Um, you can so we have several connector for for msng the support mqp uh Rabbit mq kafka and a few others a course with web sphere mq Uh for gms, uh, we are working on it We start having a plan so as we have a plan is going to work very very soon Okay, well, I do think we're we have run over our time slot for today I'm actually looking up the github repo link for a reactive messaging demo is the one you said, right? Uh, no, it's another one. Uh, I can send that to you It's uh, it's very cool Active demo, okay. Don't see that one. But all right, we have reactive messaging demo but not reactive demo And the coffee shop demo too many repositories Things he found one. Oh, no coffee coffee. Sorry Uh, thank you. Great All right, well then we need to get out of here the uh, but thank you so much for your time today Thank you everyone for attending any questions and come on. Thank you so much Thank you very much