Jakarta EE Tech Talks, 27 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Going Reactive with Streams in Jakarta EE | Jakarta Tech Talks - February 2019

Description

The old world of monolithic Java EE servers had the luxury of assuming a consistent state, due to a single database being able to enforce that with ACID transactions. In the cloud-native Jakarta EE world, these assumptions no longer hold, and new architectural models are needed to deal with state and ensuring consistency. At the core of these models is streaming, which allows the state to be reliably propagated throughout a cloud-native system, allowing eventual consistency to be assumed. MicroProfile Reactive Streams is a new spec that has been created to manipulate and handle these streams. Coupled with upcoming specs for messaging and modifications to existing Jakarta EE specs for Reactive Streams, MicroProfile Reactive Streams offers Jakarta EE users an opportunity to safely move into the new world of cloud-native computing.

///GET SOCIAL!
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Like us on Facebook: https://www.facebook.com/JakartaEE/
Join us on LinkedIn: https://www.linkedin.com/groups/13597511/
Tag us: #JakartaEE

Want more great Eclipse Community webinars?
Become a member of our Jakarta Tech Talks Meetup:
https://www.meetup.com/meetup-group-DAaStLqu/

A

Okay, so I think we're starting our.

A

A

Okay, let me just set things up here. A little bit give me a moment: okay, so um welcome everyone. I, don't see how many people has have joined, but hopefully you can hear me loud and Creole clear we're on our second Jakarta Tech Talk this time with James rapper, and he is going to talk to us about reactive, with getting reactive with streams in Jakarta EE. So James do you want to take it over share your screen and and start presenting yep perfect just for everyone.

A

Please feel free to use, chat after James finishes, we'll have everything open for questions and answers and I'm sure we'll be happy to answer your questions.

B

Okay, so thank you for joining. My name is James rota. If you're on the East Coast understands the afternoon, if you're on the west coast it's the morning, if you're inning in Europe, it's probably late in the evening and if you're, where I am in Australia, then I do recommend going outside and watching the sunrise. Well, you hear this webinar, so I work for a company called light Bend. We, the company behind the scholar program in language between behind our Kerr play framework and logon, and my role there is the open source software architecture.

B

Today we're going to be looking at some upcoming reactive specifications in Jakarta AE, focusing specifically on some specifications that are both finished and in progress in my profile that we hope will be eventually adopted into Jakarta AAA and can be used in popular Jakarta, AE or Java EE application service. Today,.

B

So the first thing we're going to look at is is what is reactive? What do we mean when we say we're going to bring reactive to Jakarta AAA we're going to then look at what reactive streams is, which is a particular technology for for doing reactive programming and we're going to look at exactly how this is being used.

B

Some completed specs and some in progress, specs.

B

So what is reactive now when a lot of people when reactive comes to mind?

B

Probably a lot of people will think eventually I/o, so things like completion stage and completable future things like if you've heard of reactive streams, the asynchronous handling of advanced icing of this back pressure, perhaps the java nuea IRAP eyes and the asynchronous event of an I/o capabilities there, and you would be right if you, if you thought that that's reactive, because it is but one problem that that we so today is- is that people stop at that, and they say event-driven IO is all reactive is and that's in no way.

B

True, reactive is so much more. In fact, if you just stop at an event-driven IO, you actually don't get much value at all. You you're able to perhaps use your hardware a little better about the full potential of reactive offers. So much more so reactive is a set of architectural patterns for building systems that are responsive, so responsive means when you go to the system, regardless of what else is happening in this, it should give you an answer.

B

It should work in within a reasonable timeframe and in order to achieve that, it needs to be resilient. So if there is a failure in the component in this system, it shouldn't bring the whole system down, it should be able to continue working even when failures occur and, secondly, it also to be responsive.

B

It needs to be scalable both up and down, because we don't want to it's no good to be able to just be having 100 100 machines running a system that only needs that one day a year, and so these are these properties of resilience and scalability underline what a reactive system should be and do these those tenets of reactive. It's perfectly suited to solving the challenges of cloud native systems, and in case you aren't aware there is something called the reactive manifesto which very neatly and succinctly summarizes what reactive is and why it's needed.

B

So you can visit that wwww manifesto dot organ in your own time, if you wish.

B

So, let's look at some of these challenges that we have in in cloud native computing. That reactive seeks yourself.

B

So quite a native opens many opportunities, the what what we can do when we go to the cloud compared to just running on our own servers is is far is very broad, but it also introduces many challenges, so I'm not going to talk about all the challenges, but some examples are. When you go to the cloud and you're running micro services, you don't have a single database, okay and because you don't have a single database, you don't have asset transactions on your data. Only on your global state.

B

Now you might have each service that you're that you're running might have its own database and within that database you can have acid transactions for updates, but because you have multiple databases when you need to update multiple services, there's no way to do that in an atomic way. You don't have acid transactions across all your services, and so consistency can no longer be taken for granted.

B

Another challenge is that, because you've got more services, you've got more Network and communication. You've got more deployment, configuration, there's more moving parts, and so there's more that you can get wrong, and so consequently, cloud native systems are inherently more fragile, they're, inherently more prone to failure. Now people often talk about going to the cloud and because you've got so many machines there, you can build a more resilient application, but that doesn't happen automatically.

B

If you don't carefully design and use patterns that allow you to take advantage of those machines to build a more resilient system, you won't end up with a more resilient system. You will end up with a far more fragile system than a typical traditional monolith.

B

Cloud native does offer offer great opportunities to scale on on most common clouds, the the resources at least compared to what you usually need, seemingly endless, but these, but scaling also doesn't happen automatically.

B

How do you do so horizontally if you just apply your normal patterns that you had with a monolith, you'll find you run into bottlenecks very quickly.

B

So I'm going to outline just a couple of principles in reactive: there are, there are reactive, is far bigger than this, but a couple of principles that reactive, the architecting reactive systems that we use when we architectural active systems that help to solve some of these challenges.

B

Probably the biggest principle in reactive, is isolating services, and when we say isolate, we mean ensuring that these services can't have an impact on each other.

B

So, let's just look at the moment at HTTP communication, it's very common when building micro services in the cloud to use HTTP, G RPC has also become in common, but these these protocols are inherently synchronous, doesn't matter if you're using asynchronous I/o you're still doing a request on the remote system in a response, and if that system isn't running at the time, if it's not available, if it's not responsive, you won't be able to proceed with your operation.

B

So HTTP depends on both services involved in the communication being responsive, and this offers an opportunity for for fragility because of if one of those services goes down then effectively both services down. You can't achieve the operation that you need to if you use an HTTP to communicate between them, and this gets worse if you start involving more and more services, because each service that that has an HTTP call done to it, whether it's in sequence or transitively, is going to impact the overall availability of the system.

B

So when you use HTTP for communication between services, you don't have isolation. Okay, HTTP is not a reactive, architectural principle.

B

So you might think well we'll use a message broker to to communicate between services and that's um that's a good idea, and so you might as part of your operation, you might update some state in your local database and then publish a message to a message: broker, there's still a dependency here, because it means the service that is trying to complete.

B

The operation must be responsive at the same time as the message broker and if, for example, that service does an operation and then tries to publish a message to the message broker and the message broker isn't responsive, then that operation is going to only partially complete. Whichever order you happen to do it in maybe you disable a CalPERS and publish to the message broker first and then commit my transaction and let's say that this I published to the message broker succeeds. But then you, your database transaction fails.

B

Then you you'd still have a partially complete operation, and so it's better because usually it's easier to keep a piece of infrastructure like a message broker available, but you still don't have complete isolation. There.

B

So what we really wanted to try and do is make all operations asynchronous and- and this is done using CQRS. So if you can separate your commands, so the things that come in and update your local state from queries, and that includes publishing messages to a message broker.

B

Then you end up having no dependency between the responsiveness of any component and you achieve full failure and scale in isolation and are able to take the full advantage of your cloud native platform.

B

The second principle that I want to talk about is adopting programming made models that manage failure.

B

So, in a traditional system, in a monolith, perhaps running Jaguar, AAA or or not acid transactions are there to handle failure for you, a developer doesn't need to explicitly handle all the failure conditions. They don't need to anticipate all the possibilities. What happens if something else tries to update this at the same time? What happens if either my service or the database goes down halfway through.

B

They don't need to worry about what do I need to clean, but cleanup. If there is a failure, what compensate in actions do I need to do?

B

Do I need to retry as a transactions handle that for you, but, as we said before, in cloud native systems, we don't have asset transactions at a system level, and so the moment that we need to do an update that involves multiple services.

B

We no longer have anything that managers failure for us, but we do want something that manages further for us because we don't want to have to manually implement handling for all the permutations of failure conditions that could happen, and so we need a different pattern for managing failure when there isn't manual one that that we can take for granted that we can focus on solving our business problem.

B

So I might I think I had a problem with my heads up there, sir streams have a cloud native equivalent of acid transactions.

B

B

Streams are an architectural pattern that we can use to be able to not worry about failure anymore.

B

So, let's take a look at this reactive streams you may have heard of is is a an approach to scrape the streaming, that is reactive, both from a programming perspective and an end from a systems architectural perspective at a high level.

B

Reactive streams offer a declarative way of describing work to be done, and this a declarative way of describing work is important, because what you don't want to be doing is saying: okay, I'm, going to, for example, read some message and then I'm going to process it and then I'm going to send a message here, because, if you're, the one that that's controlling what what's done when then you also have to manage the failure. Rather you don't.

B

What you just want to do is declare well here is my processing for those messages and I want to let the infrastructure go and handle lifecycle and failure and retries for me and distribution as well, because when we go to the cloud, we will potentially have many machines, and we don't want to have to to manually spread that word across their machines ourselves.

B

Reactive streams offers asynchronous handling of events, so it ensures that we have efficiency of resource use. If we, we can run many streams at once without consuming many threads.

B

And reactive streams, also propagates back pressure and back pressure propagation is very important because without a back propagating back pressure, there's no way for a downstream processor or consumer of data to be able to push back to upstream processes and say: hey I'm, not ready to receive more data. Yet can you please slow down? There are some api's in Jakarta ae at the moment that offer asynchronous handling of events without that pressure, and so the websocket api, for example.

B

There's no way to go back to a WebSocket and say: hey: can you actually push back on the TCP connection to stop the client from sending me Danny? You have to handle it all and if you can't will, are they going to run out of memory or you're going to somehow or you just have to fail.

B

So, in an implementation level, reactive streams is a specification effort that was started by light band, Netflix and pivotal and others in 2013. That's 2013. When the initial contact and discussions were made and then in it was worked on through 2014 and finally released in 2015, it was adopted in Java and JDK 9, and so you can find this today in the Java util concurrent flow API.

B

It's considered a low level integration API, so so so the interfaces in in Java util concurrent flow. There are four interfaces: publisher, subscriber subscription and there's also processor, which is just a implements both publisher and subscriber and there's only I think seven methods across these interfaces.

B

But these interfaces intended for use for integrating between different asynchronous streaming libraries. So if I have a database that is able to a synchronously stream, eros and I have a HTTP client that is able to asynchronously stream out but and then I have a stream manipulation library.

B

That's able to able to do a seamless transform of transformations that that should convert these rows to bytes I can connect all these things together using reactive streams, even if the authors of these technologies had never heard of had never heard of or tested each other against each other, and that's what reactive streams offers it does require.

B

High level user facing ap is an important point to make is that users should never implement reactive stream interfaces directly themselves, if you're using reactive streams- and you find yourself implementing a publisher or subscriber, then you're probably doing things wrong, because there's there's, even though it's only a few interfaces and about seven methods, the spec for reactive streams itself has a 40 or 50 individual requirements. There's a TCK that get that can be run against against. This is an implementation which includes around hundred tests and getting them to pass is is a lot of effort.

B

It's a lot of concurrent programming merit dealing with memory barriers. It's not intended for users to implement directly themselves; rather, they need a high level user facing API. Unfortunately, they are. There are plenty out there, so you have your connectors to databases, to message brokers to to HTTP clients that then implement reactive streams, and you also have streams, manipulation, libraries such as ARCA streams, Eric's, Java and reactor. So when you do work with the reactive streams you can bring in these libraries and do whatever transformations you need on the streams.

B

Of course, when it comes to Jakarta, a a a challenge here is that these are all vendor libraries, proprietary libraries. They may be open source, but they're, not standards, they're, not something that can just be included in a Jakarta, AAA implementation and so to address this in micro profile, I'm going to introduce our first specification and that's Mike profile, reactive streams operators.

B

So this specification is a high level user facing API for manipulating reactive streams.

B

We've just released 1.0, so you can use it. There are a number of implementations out there that you can try. It draws inspiration from Java util streams. So if you're familiar with Java util streams, then a lot of the methods are the same. The scope of what methods are included and what aren't are the same? I should point out that, even though the api's looks similar, the unlined of of what you're actually doing is is very different.

B

So Java util streams is about manipulating collections of of things that are usually in memory or their sum or they're calculated, somehow on-the-fly, potentially in parallel. It's about bulk processing operations. Of that don't involve IO reactive streams. On the, on the other hand, is about fundamentally about handling I, about being able to process things asynchronously about being able to push back up the stream with back pressure.

B

Reactive streams, the implementation combines the best of ARCA streams, our extra hand reactors, so every feature that we added. We looked at all those three of these popular implementations and we looked at okay. What naming convention do they use? What are their? What are their edge cases, how they handle different things and try to come up with whatever was was common and and whatever seems to to fit best based on the experiences of those learners, and we have three implementations so far. So there's one: that's our custom supposed one!

B

That's our X, Java based and we've got another one that doesn't have any dependencies, so it's been implemented from scratch and the intention for that one is if this was to ever to be adopted into the jdk itself. That might become the reference implementation.

B

So what I will do now is take a look at some of a P I docked for these. So here is processor builder. This is for a process of builders for building generic transformations. So the kind of methods that you have are things like map. You can see. We have these diagrams for what it actually looks like. So you have an incoming stream that has elements 1, 5, & 3, and if the map transformation is to multiply it by 10, you get out 10, 50 and 30 an example of flat map.

B

We can see down here. Other ones filter, so filter everything, that's less than 3, and so these are. These are the kinds of operations that we have skip, 3 elements, so the first 3 skipped and then you get 2 & 4 out now. I could give a demo of these, but chances are if you are familiar with Java 8 and went to any conferences around the time. The Java rate was the laced. You've, probably seen plenty of demos, of Java util streams and.

B

That's not much different from just using microphone reactive streams, operators in isolation. The code looks very similar to the same sort of methods and using reference frames operators out of the context of actually doing asynchronous I/o process in really isn't interesting, you're much better off using java.util streams. So before I give a demo of this, this API I'd like to move on to the next spec, which is something that actually uses and provides a use case for those operators to do some higher processing and that's micro profile, reactive messaging.

B

So it's it's a reactive streams based messaging API messaging, as in communicating through a message broker or through doing messaging peer-to-peer.

B

It essentially provides two annotations incoming and outgoing. You put these on methods in a CDI beam, and that declares this. This method provides something that's going to handle incoming or outgoing messages.

B

It can be connected to any messaging provider. So we have implementations for Kafka impp and q TT JMS it there's there's there's as it's been designed, so that it's not tied to any one messaging provider.

B

The spec is currently in development and we're targeting micro profile 3.0 for it, and so I'll now move on to a demo. So I've got an application here. So this is an online option and it's somewhat like eBay, so I'm just going to create an item here. I want to auction off my bike.

A

It is if then you're going to check the chat as well with some questions that would be great or maybe afterwards, after the the the demo I'll.

B

Do it afterwards.

A

B

Thanks so I've created an option: it's I'm selling, my red bike, I'll start the auction, and now it's very secure authentication got a log in as a different user, I'll place a beard, $10 bead, you can see.

B

Currently that's been accepted with a price of 50 cents and then, if I go and log in as someone else now, let's say this: John user goes and they're really interested in red icons, so they search and my black comes up now you see here, the current price is not listed and the reason is because I have failed to implement something in this service. So we have a number of services implementing this application and there is an auction service that or an item service that holds the details of the item.

B

There's an auction, a bidding service that that controls, beads and there's a search service that implements this search screen and the way the search service gets as information is by subscribing to kafka topics that, from both the item service, to get the information of the items, as well as the bidding service to get the current price.

B

So if we go and have a look at the code, this is where it's subscribing to the bidding service. So you can see here. Current we've got this incoming annotation and it's saying I want the bidding Benevento topic. This is returning a subscriber builder. So this is the micro profile, reactive streams, operators API. Here it's going to build a subscriber of of bid events, and then we create the Builder here and you can see we're doing nothing with each message.

B

So obviously we we haven't implemented it. Yet we have implemented here up up here. The item event processing. So that's why the item appears and the search index at all, but the prices and the Piron, because we haven't yet implemented handling of the bid events which contain the price in them. So why don't we do that? So the thing that we want to do when we receive a bit of that this some service actually persists its data inside elastic search and elastic search works with documents.

B

So we want to first convert our messages using the map function into documents, so I've already created a method to do that clear event to document now. This method actually doesn't want to handle all events it. There are some events that don't need to be to persist anything as a result, and so it actually returns a type of optional. If the event is not one that it's interesting, it will return an empty optional.

B

So the next thing we want to do is filter out all those empty, so we use filter to do that and we'll use optional is present. So if, if that method returned a document, then it'll still be in the stream, otherwise that after this filter operation, there won't be any element in that stream. For that now next thing, so our message is still wrapped inside an optional, let's unwrap it using optional.

B

Yet so now we have our our documents that are preferring to our stream, not as optionals just as stretch elements, and so now we can actually handle them. We will use flatback completion stage, so we have a reactive or an asynchronous elasticsearch store here.

A

B

Order index store that store and we'll pass in the document.

B

It's passing the message there message: dot get payload now. The result of that store operation is a completion stage of done, which is just a unit operation. We're going to map that to convert it back to the message, because after storing it, we want to then acknowledge the message from the Kafka queue.

B

So we now have we've stored it, but we've still got our stream of messages, so we can do completion stage and we can invoke the the act which once again, is an async.

B

Which is why we use mess flatmap completion stage and after that, we've actually done everything that we need to do so. We just terminate the stream with this null up on on it on each major element, and then we can return that as a subscriber of message, events so having implemented that I've got this application, then, in the background logon automatically detects changes to corrode recompiles and restart services.

B

I should mention that this application is written in in log on which is a reactive, local services framework, so that should have reloaded, and if we do the search again, we don't see the current price and the reason is because there's something else that we haven't implemented yet, but before I get to showing that I'll move on to the next slide.

B

So another thing that's come up in discussions of recent in in micro profile is the possibility of a say, QRS, spec now say: QR S stands for command, query, responsibility, segregation, and it's about separating the responsibility of handling commands from the responsibility of handling queries such that they can be handled in different databases. They can be scaled in apparently, and, more importantly, what we're interested in here is. We don't want them to be able to impact each other.

B

So if a query fails to, if the query handling fails for some reason that shouldn't stop our commands from being processed- and you would have earlier in the presentation- I talked about how about how we can handle about how, if you publish directly to a message broker after you do an operation such as an update on the database, then you have a level of coupling with your message: broker.

B

Heater CQRS can be used to to decouple that your your persisting of your handling of your command from then publishing those events to the message broker, so they can update queries.

B

So, let's take a look back in our service and we're going to move now into a different service into the bidding service, and this is the code that I've implemented that publishers they're involved now I'm not going to show the actual persistence for the bidding service, but what the bidding service does is when it it's using event sourcing and so, rather than storing the current state of an option such as you know it's.

B

This is the current price, and this is the current winning bidder and the current fee option is still running rather than store in that state. It simply stores all the events that happened and computes the state from the events so oxygen started. This bid was placed. This big was placed, the auction is finished and because, when it does that it stores those events in an event log that event log can be consumed, asynchronously it by another process.

B

In this case, this publish event log method, and so we have this decoupling from the persistence where these, where, where these events was were persisted and and the thing that then goes and in another process potentially on another machine and a different time, goes and reads that event: log and publishers, adapter Kafka.

B

So you can see once again this this time, it's not a subscriber, it's a processor which means that transforms messages. We we create a builder and we filter them to our publish the ones that we want to filter, and then we do some transformations on them and we end up converting these incoming messages of the auction event. That's what gets persisted to the database to these bid event, which is what we are not publishing to cover and what we're missing here is annotations to be able to declare this.

B

So these are the reactive messaging annotations, and here I'm saying the provider is the event log. So this is so. This isn't actually getting messages from a message broker. Here it's getting messages for our database from our CQRS event, stream and they're, going to be used as incoming messages and then outgoing. We will publish to the bid event queue in Kafka and so now I've made these changes and when, when Logan picks that up recompiles where he starts my service, I can go, I can hit Search and hopefully it should just show the current price.

B

I'm not sure why it's not doing that.

B

We'll try posting another bid just for good measure.

B

As of the price, now there is is published now, unfortunately, I've, given this demo a number of times before, and what happens there is, is the current price just comes up and I'll have to go back and work out exactly why I didn't come up? Then it possibly. There was a something wasn't connected to Kafka, sometimes in development of own Kafka than a bit clinically, but I'm, an important thing to to that.

B

If the demo works, or what have demonstrated is that we actually had a self-healing system there when, when I am at some stage, as you saw, I hadn't even implemented the publish. Now, if we had published directly to cuff go after do an hour operation, then we would have had our system wouldn't have ever got that those current price, those bit events, because if because they were lost in history, you can't republish. You can't redo something from the past, but when you work with streams, when you take a stream oriented approach to the system, then.

B

You can resume you can resume that processing at any time, and so you get this. These self-healing profit probabilities where the stream itself is what continues pushing your your system to be to be consistent.

B

And so that's the end of the presentation. There are some links here that I've got. You can see the microphone reactant streams. Operators spec is the documentation for the operators which I showed before and the microphone reactive messaging spec, so I might check. If there are questions now, I can't actually see any any questions in the chat. Oh.

A

You don't yeah.

B

You want to write the rap to me.

A

So um let me see trying to figure out if I can point to you the questions, but nevertheless, so one of the questions that we have is what is CQRS and then you know the link was provided for for that. But if you wanted to go over that, did you have any comments so.

B

Yeah I did mention CQRS early in the presentation without explaining and then I did explain a bit more detail later, but just to go over it again.

B

It's command query responsibility, segregation and the idea is to separate your commands, which are your right operations from your queries, which are your raid operations, and so what you end up with is you do some comma? You handle your write operations and then you have a stream of events that are the output of your write operations, whether it's event, sourcing, where the events themselves are what you persist or in addition to doing some updates on the crud database. You might persist some events to an event table.

B

You can then consume those events. Usually they will have some sort of offset, and so you can track where you are in to the offset, which means when you fail or when something goes wrong. You can resume from that offset and it allows you to to be able to do that processing on different on different machines. You can use different database technologies.

B

So an example here I'm using events or I'm using elastic search for the search service, which is a different technology to Cassandra, which is what's being used in the item service and bid service and and because it's streams based. You can take advantage of the fact that you can let the infrastructure manage your streams for you to manage your favorite, but the failure rate rise, distribution.

A

Right, another question is, is do you support or is this working with vertex? Yes,.

B

So I'm vertex, one of the implementations of reactive streams operators is, it has been implemented by Red Hat on our X Java, with will also support in in vertex and indeed the the red hats messaging. Implementation is built on vertex, so the work, the work that I'm doing is with arca archa streams and and log on.

B

But if you go to Red Hat's micro, profiler implementation, you'll get support on on vertex.

A

Another question is: what is the benefit of using this over the plane, Kafka streams, API.

B

Yeah so Kafka streams is Kafka Kafka, you can do Kafka connect, but it's very limited, Kafka streams. They say they support event sourcing, but they only support something that looks vaguely like event sourcing. It doesn't support commands, it's just events that must be handled and can't be rejected, which is a fundamental thing of insourcing, is that you can validate and reject commands.

B

So if, if you need to do cuff go to Kafka processing, then then Kafka streams is great, but what this gives you is is is so much more you can, as you saw, you, can, connect and an event log in a database to your to your to.

B

To to cough like you, it's also there's no Kafka specific code there, although in or there doesn't have to be any Kafka specific code in your application. So you can, you can have you, can do your vet Kafka to clavicle vent processing without being tired to cover and be able to move to different message brokers, for example, the cloud technologies like Colossus or as or event hubs are very Kafka like you.

B

Can your your code will be portable to those so so this allows you to to do things without the vendor, locking that you get with Kafka streams.

A

Okay, let me see I.

A

Need to thank micro profile, eclipse micro profile, community, for kind of answering questions and and and also they're they're, quite active in the chat as well. So let me see I think you already said that the the example you provided is on the github is that right yet.

B

The the example happens itself I think I have a version of it, which is a bit different from another presentation, but I can publish it to two to github, yeah I'll, publish it to this is where I'll publish it to.

B

But that doesn't exist yet, but Jakarta Hey reactive, just streaming.

B

That's where you'll be able to find it probably five minutes after this presentation is finished.

A

That's fantastic! Maybe if you don't mind put it on the on your last slide, so umm people can view it from that perspective as well and have the link there. Okay, um any more questions, comments for James.

A

We want to keep James around to answer more questions, so please, if there are any questions or comments whatsoever on the talks, please put it in the chat. We're super excited to see you that you down, then, and then that there is activity on the chat.

A

Ok, so if there isn't anything else, a reminder that in a month we will have another call I'm just about to set it up, I'm hoping to either have a Malaysian or Sebastian nur to have their talk talks, so stay tuned and kind of monitor for the date and time and in the meanwhile I want to thank James very, very much.

A

It is greatly appreciated and yeah we'll stay in touch, and we know where to find James if we need him to, you know, provide more information with regards to streaming or reactive streaming or anything else bye for now and staying warm particularly asked on the northern hemisphere, where it's so freezing okay.

A

Thank you, everyone and we'll be in touch. Thank.

B

B