Reactive Systems: Reactive Microservices End-to-End with gRPC

Reactive Systems: Reactive Microservices End-to-End with gRPC

Recording: Reactive Systems: Reactive Microservices End-to-End with gRPC

everything is always posted to function on that TV YouTube channel welcome everybody I'm your host Alex ich rubber off the founder and organizer of the reactive systems Meetup we started in 2015 after scaled by the bay conference the first talk was given by John's Bonaire and it was called live beyond the illusion of the present and I'm really excited that that image is on the me table it's really kind of boosted in the philosophical context right it's not just the technology were talking about we're talking about ways to to write systems and I think this paradigm again even more important as systems are in the cloud we see a lot of different requirements we see a lot of a bissell is a distributed system for everyone everybody now needs to grapple with the surveillance systems and our reactive is basically a way to write these applications but it's never by itself right it's never just it's it's a data part pipeline it's it's connecting different pieces so what folks are finding that they really need to change the way they think about writing this applications because if you do it in a legacy context you know if you do like a reactive piece then it just becomes harder for others right and doesn't show you much benefit so what folks are finding they really need to rethink the way they do this so in kind of them this context there is a new linux foundation called reactive foundation it was announced last fall and basically i'm going to be helping the rocky foundation to properly ramp up and the tagline for it will be cloud native applications foundation so if you can think of CN CF as a operators view of distributed systems that's how you basically turn on and off computers in the cloud and connect them right and do it fast and a kind of in the reliable fashion reactive foundation or CAF will actually help folks write applications which run on top of those platforms so I think reactive is a core technology but we are not limiting itself to purely kind of you know reactive streams or actors or FRP or iakh GS we're not going to kind of spend a lot of time nitpicking definitions we really are interested in football approach to to writing cloud applications and reactive is we firmly believe is one of the best ways we know so far I think our communities actually have probably the most combined experience you know going back decades from Erlang and kind of other things so I think we're a very good position with these meetups especially becoming global but we also welcome streaming alright we also kind of welcome all kind of waste how do you think how do you reason about these things and so if anybody is interested in kind of advancing this we'll spend the month of May and of properly ramping up will be some announcement later on but feel free to reach me if you want to speak if you want to if you have projects if you have things you want to open-source let me know so that's that's the preamble also the logistics as I mentioned please ask your questions on slack Ryan probably will be kicking it as he speaks when he has a good moment for this and he can take it during the talk he can defer it until the end in the end we'll just have regular Q&A right so that's about it and also we usually have two Talk's today we have one talk if you feel empowered to share what you are doing if you want to lead the discussion we just had a great shot with subrahmanyam pune about telecom users of reactive before we started if you guys want to continue talking we'll just open the floor but also there is a sign-up sheet it's in the slack it's a short URL basically listed here so it's just a Google spreadsheet and what we could do we could basically have talks there is a conference format but you know converse or Amitabh Sokol and meet up so if you want to present just add your talk in there and we'll review at the end of Ryan's talk if anybody wants to speak doing lightning talk or lead the discussion you know it's pretty open so with that I am very happy to introduce Ronnie Shella he is the leader of the reactive G RPC projects he is a Salesforce which is a great member of our community and with that Brian take it away so you know alright let me get myself sharing I hello everybody so my name is Ryan Michelle oh and as Alexi so introduced I'm at Salesforce and I can be talking about reactive micro services end to end with G RPC it was a great segue talking about how reactive programming is not something that exists in a vacuum just totally true because one of the challenges I've experienced working with reactive programming is you have a thing you build this really beautiful reactive pipeline but then much like pure functional programming languages you have to do input and output and that's where it always breaks down so G RPC and reactive programming work really well together to build micro services in a purely reactive fashion so that's what we're going to talk about all right so quick show of hands using the little show of hand reaction buttons here in and zoom how many people are familiar with G RPC all right I've got a couple fantastic now how about how about rx Java or spring reactor yeah all right we got more for that I expect that from this crowd wonderful all right so gr PC is the integration of rx Java or in this case or also spring reactor it works for both and the G RPC remote procedure call system so a little bit about myself I am a G RPC practitioner I use it my day job I contribute to it I own a gr pc g RP c java contrib where II built reactive reactive G RPC and I'm a strong and through evangelism GI PC at Salesforce I'm also a reactive programming enthusiast and I enjoy using it I enjoy talking about it and I really find it as a very powerful technology for making software easier to understand so what are we going to cover in this talk a brief history of Micra services at Salesforce which lays the foundation of why reactive G RPC exists at all a brief overview that of G RPC and rx Java but reactive programming in Java in general talk about some great demos I'm gonna go down deep into the backpressure models involved because this is reactive programming over the wire back pressure gets a little strange and it's a really interesting topic to get into and then we're gonna add with a really cool demo showing some of the really some of the capabilities compelling capabilities of reactive GRP C and G RPC in general all right so we're reactive G RPC came from a little bit of history Salesforce it's all over a 20 year old company now and we've got an enormous monolith and we've been slowly working on breaking up our model over the years we started in the beginning breaking out micro services and just having them you know with the spoke REST API or every you know where every interaction was hand written by a developer on both ends every in a good every every curly brace was negotiated usually in like Google Docs or something and we decided we needed something a little more structured so we went that time we went to Apache thrift thrift gave us a lot of the structure we needed but at the time thrift had some awesome issues involving in a port usage and not really having great use for headers and I know a lot of these things have improved interrupts over the years but we saw the opportunity to go with GRP C and G RPC really improved our our capabilities additionally right around the time we started adopting G RPC we adopted Micra a service mesh technology and G RPC and meshes go really well together we've grown that out we have I can't I don't even know how many microservice is now but we started with one and now we have many and it's been a long and fruitful road so GRP see a little bit about it their headline they call themselves a high-performance open-source RPC framework all those things are in fact true G RPC is very performant on the wire mostly because it's on the wire it's binary so it's open source entirely all the source code is entirely available and it is an RPC framework so unlike rest which is generally thinking or thinking about the world in terms of data structures upon which you can perform for operations G RPC thinks of the world as an unlimited set of operations to be performed on arbitrary data structures that's really really beneficial because it gives you a lot more flexibility and a lot more expressivity and describing how you build a micro service under the hood G RPC isn't I was built on protocol buffers in HTTP 2 so it's about as standards-compliant rock-solid as you can get on the HTTP 2 protocol is what it uses on the wire so it's not special like say how thrift was special and it's protobuf so it's an HTTP to message with a binary serialized protobuf under the hood protobuf is a really rock-solid binary serializer for google so the three big features of GRP Sivan made it really compelling for us to use our first at its contract first so you start with the protocol buffers interface definition language specification for a service and you go backwards and generate all of your language specific stubs it's polyglot so G RPC has code generators for 10 native programming languages first party languages that come from Google and there's community support for a number of additional languages on top of that so we're talking about things like Java and c-sharp Golay C++ Python JavaScript the list goes on there's a whole cottons now out there well there's an ever growing list of gr PC compatible programming languages that you get dynamically generated stubs for based on the protobuf IDL one of the final really compelling features that we found useful at Salesforce is the G RPC is built on HTTP 2 which unlike HTTP 1 HP 2 is a natively streaming protocol makes it also makes it starts to make you think in reactive terms when you start thinking about the streaming aspect of it gr pcs has unary and bi-directional streaming capability so you can make a service that is instead of a simple one-to-one request response you can go one-to-many or one-to-many stream or I send you a stream you send me a stream and we just stream a stream to each other the server I can send the server a stream and then it can send me back a response of how many messages I sent it the there's basically all sorts of possibilities with it so I know this is a reactive group and most people here are familiar but as a quick overview what is rx Java and reactive programming in general and design come to understand it there's an API for asynchronous programming with observable streams unpacking that the idea is that everything is a stream this was one of the I think original like crazy ideas that made reactive start taking off so many years ago that everything is a stream the clicking of your mouse as a stream the typing on your keys is stream of keyboard events movement is a stream even requests coming in off the network can be a stream requests coming to a micro service can be a stream requests coming in from my own RPC request can be a stream so attached to that stream we have the idea of filtering combining and transforming different operations that you chain together to create a new stream built on the original stream so as an example rx Java for example has a debounce operator that takes a stream of events and and over time so you know if if the user clicks a mouse too quickly you don't get every mouse click you only get one every ten seconds also you have things like Map Reduce where you can take you can take an object or a message of one kind and transform it into another in a streaming fashion and then you find the end with subscribing which is reintroduce an observer the observer is what actually looks at the strain the interesting way that these technology is set up is that you end up designing the stream in code or you designed the pipeline in code but you don't you know unlike imperative code where you write a for loop and the for loop executes as it goes this is kind of declarative you declare the structure of your system of your pipeline and then when you subscribe to it events that pass through the pipeline get transformed as they go through so for example I've got this little picture here and the own mouse mouse clicking and then we want to debounce it so that you you know don't get too many mouse clicks we want to map them and to map them from mouse click events to robot movement events and then send that to the robot and so in traditional java sense you would write this and it'd be a for loop and now keep bouncing the mouse would be terribly complicated because you'd have to keep a timer of every mouse click and how many times something's happened and then sending that you have to then transform those messages inside your for loop it just it'd be gross and nested loops and timers and all sorts of stuff you're really just you end up having the though subscribing transforming filtering all that code blended in with your business logic becomes very difficult but when you put it in terms of reactive you get something as simple as this which is just observable create an event stream from mouse click events they bounce them over a one minute one second time unit map Mouse events to robot commands and then the robot subscribes to that and every time we get an event we pass it to the robot do operator so we've been able to you know with a few lines of code and infinitely able to express this very high-level concept and all of the gunk of writing Lou some timers and tracking and thread management's and all that kind of stuff all just fades away behind a very clean reactive API so talking about G RPC we've talked about reactive programming in our extra but what if we brought them together a stream based RPC protocol with a stream processing library well this becomes a really powerful combination so we put together reactive GRP see what reactive G RPC is a set of additional stub libraries for G RPC and a protobuf compiler plug-in that generates those reactive stubs for Java based on the contents of a protocol buffers interface definition language specification are there any questions so far about just what is GRE active G RPC and rx Java or what kind of a very highest level looking slack give you all a couple seconds and I guess you boys if all right if you'd like people to you know if you feel like people cannot just ask feel free to invite people to ask yeah yeah go ahead and ask or on asking slack either either one works all right I will go up go all right so let's start with our first of all demo and I'm just gonna show some basic G RPC and then compare that to basic reactive G RPC so we're going to see a little bit about the protocol buffer IDL take a look at the per talk code generator and how that gets wired and a java project using maven for those not familiar with our X Java notation single tea and flowable T is how we describe a stream of exactly one thing or a stream of an open-ended number of things all right so oops I'm gonna get to there we go so let me bring up our hello world demo so starting with the basics let's look at the protocol buffer specification for this very simple hello world so hello world what we've got here is protobuf which allows us to specify the data structures and operations that make up a service we've got a little greener service we have hello requests and hello response there's trivial as you can be there just a data structure with a single string over that we're just describing three operations one is greet which is a basic unary operation receives a hello request returns a hello response but now we're starting to get interesting we can look at multi greet and strain greet one receives the hello request returns back many an open-ended number of responses and streaming actually is a bi-directional e streaming service of requests and responses so to make that simple what we end up having to do is there's this big block of Maven palm also available for Gradle you can this information about how to put this together from the gr PC and reactive gr PC sites but importantly what we're doing is we are setting up reactive gr PC as a pro TOC plug-in proto C plug-in for the proto C compiler and so will get generated code we had generated reactive code for rx Java and for this case we're telling it we want to do our X G RPC generator which is going to be the RX Java one so let's take a look at the basic G RPC service implementation so G OPC servers are very really simple to put together you basically just create a server builder give it a port add a service and start it it's very simple from a Java perspective implementing our unary is service is also pretty straightforward you can already start to see some Inklings of GRP sees stream based API coming in under the hood so we make our unary response we're just going to do simple hello world so you just return on next and then we complete the response stream and we're done if we want to do that with multi okay you want to do one-to-many we can say take our request to send back multiple responses and then complete so that's a stream but things start to get a little bit weird when you want to do bi-directional streaming the programming model completely changes and now what we have is this we have to return an observer and it actually like switches the programming model around it's not nearly as clean on the client side if we actually want to make the call synchronously calling G RPC is incredibly simple create a stub tell it where the server is in this case we're not going to use encryption we're just going to build it create a stub off of that which is a generated stubs are our type safe to the language that they're in and then we can you know simply build a request and call our service but doing blockings not all that interesting what we really want to do is asynchronous and suddenly once again the programming model entirely changes now that's not great so we have to create this response observer we have to do all these crazy steps go backwards we now have to look send messages to our server and indicate completion and then get responses back and the response is actually happening in a different part of code like this is the exact kind of like mixing of idea a mixing of layers of concept between the business logic and the plumbing junk that we're trying to observe our trench Rob trying to get rid of by bringing in reactive programming so if we look at the RX alternative suddenly things start to look really familiar we want to make our service well now our service our unary service is simply so a function that takes a single of hello requests or returns a singer' returns a single of hello response we can do our MIT we'd you know our simple what we'd expect it's yeah map our request to get its name map the name to a new string map the map the string to a response object and that's the Ritz the single there that's the stream we're going to return but now when we have to do multi or we have to do fully streaming like it's just functions that take singles and return flowable functions that take flowable and return Global's so now we get basically turns your G RPC service just into a your G RPC service is now a composition of reactive operations rather than loop's and object management and all that other gall another gobbledygook Clank calling it as well if you look at the async client is just as straightforward in our case we do you know you want to call it requests we do we map our map the operation so we actually call the stub and then we map the response so I we just armed the hell hello request we can do the same thing with streaming responses and we map and then subscribe and we can even do it with bi-directional streaming where we create a flowable of multiple items map them to requests map them through their saw through the service response and then subscribe to the Bosco subscribe to the console so we're able to have a micro service call that's just a another stage in a reactive pipeline so from this little code demo what we saw was at the hello proto defines the operations and data structures that make up your make up a service the proto C compiler generates Java stubs from the proto during build and the client-server our general down those generated stubs the reactive G RPC generates rx Java stubs which are easily extended extended by the proto protic compiler and then rx Java makes writing streaming services as simple as chaining together reactive operations going back any more questions I don't see any in slack anyone want to ask live uh yeah question here this date yeah when you're doing that as Stubb is that calling like a factory is that a constructor what is it ah there we go it's actually pretty straightforward stub so as is a converter it's a conversion function so I think it's our java parlance i think they call it a lifting function but the stub itself is just a function that takes in in this case a single of proto requests and returns a single orphan are this one is a flowable of hello response so as is a function that lifts basically allows you to take any function that accepts a you know accepts a stream of one kind of thing and returns a stream of other kinds of thing and it kind of serves as an adapter between the two and that's what the the stub the stub actually creates this adapter is that what happens we're looking we're looking at the stub code right here so let's you know this is generating this is the degenerative stub code that has this signature that is compatible with come on out of the way slack anyway the signature is compatible with these lifting functions provided by gr4 by reactive G RPC and by spring reactor God okay that make sense things yeah so that's how we're able to get this continuous flow and actually it's pretty neat in reactive G RPC and some of the testing our unit tests I have I have tests that show that you can actually chain because of the chaining nature of this you can just chain together in a reactive pipeline one call that calls another call that calls another call that calls another call even you know dine out you know even taking into account that yeah these service changes channel changes the response type request type the response type that response type becomes the request type of the next service it's pretty powerful and because it's reactive from top to bottom I'm actually about to jump into back pressure reactive G RPC respects back pressure so when you've chained together multiple micro services calls particularly streaming ones the back pressure will stream through all of those in-and-out calls in order to correctly apply back pressure across the entire stream of the entire pipeline of micro service calls it's it's really cool to watch when it okay all right so let's talk about back flexure so back pressure is have downstream consumers signal to upstream producers to slow down if you've never seen this there's this classic episode of I Love Lucy where what we're seeing is a little clip from it I will in this episode of Lucy she's responsible for making up packaging up these little candies as they come down the conveyor belt everything starts out fine she's able to keep up but the conveyor belt keeps going faster and faster and more candies keep coming down the line and suddenly she has no way of signaling to the upstream producer to slow down chaos starts to ensue if this is in your code this is how you get out of memory errors this is how you get threadlock let's say you get all sorts of crazy things and start start piling up in your code and you end up with all sorts of breakdown because there's no way for the consumer to signal to the producer hey back off stop sending any messages let me prove let me deal with what I have all right so in GRP reactive G RPC we end up having three different back pressure strategies working together on the wire there's HTTP to providing back pressure then there's G RPC which is providing G RPC is internal implementation of back pressure and on top of that we end up having rx Java or spring reactor with their own independent back pressure back pressure implementations and all three of these have to work together and are coordinated by reactive G RPC I'll mention producer and consumer normally when you're thinking about micro services you think you know so client and server the client and server don't necessarily make sense because the stream might actually be flowing from the server to the client or from the client to the server so we'll just use producer and consumer to keep the the nomenclature straightforward so the HTTP three level back pressure is stream based so flow control is the based on streams of bytes not messages and multiple streams can exist within the same HTTP 2 connection and they're all multiplexed together so would G with hep-2 starts with an initial what's called the flow control window which is negotiated with the connections is established the defaults around 65,000 bytes and what happens is both the producer in consumer are keeping track of the size of this window and so the producer will send bytes until it run until it's exhausted the width of that window in which case it will just it will practically stop sending data the consumer is reading those bytes offer and from its queues and when the consumer is ready for more it sends a window update event asking for more bytes by expanding the size of the window and so the producer will go back and forth the producer will send bytes until the window is exhausted the consumer will update the size of the window which then triggers the producer to send more bytes it's a very straightforward just back and forth protocol but remember this is just bytes it has no concept of messages it has no concept of request or response objects and it hasn't concept of like you know things in Java now built on top of HTTP 2 is G RPC and G RPC is message based it deals with serialized protocol buffers buffer objects so on the producer side there's something called an unready handle or buried deep inside G RPC and its job is to serialize protocol muff buffer messages into binary streams and hand them off to HTTP 2 up until the flow control window is exhausted when that happens back pressure kicks in and the Andrej handler loop gets closed down when a window update is received by the HTTP 2 layer that gets that triggers the on ready handlers ready triggers the unready handler to start its loop back up and it will keep going doing its loop of serializing messages and putting them into the HTTP to send buffer up until the flow control window is exhausted again on the consuming side we have ERP seekin some part of the gr PC consumer stack it's calling a request so a service consumer called ends up calling request 1 or request 2 or whatever from the underlying GRP cos the underlying HTTP 2 and this results in deserializing a protocol buffer message when enough bites have been received and giving that to the service so consumer calls requests G RPC then request 1 the the server sorry the G RPC machinery and deserialize a message and calls the services on next so you learn this consumer side you end up with this loop of request 1 get a message request 1 get a message which looks a lot like what you see from other reactives and then at the RX Java level these are message based flow controls over Java method indications rather than over byte streams on the wire so consumers call a request one which passes through the operator chain recall delegating down request one request one request to one all the way down to the producer which then produces a message producer calls on next which propagates back up through the chain and all of the intermediate operators have their opportunity to do what they need to do whether it's mapping reducing to bouncing whatever all of that happening through the mediation of these requests and on next obviously rx Java and spring reactor are dramatically more complicated under the hood but this is the basic gist of it now when you pile all three of these different different flow control technologies on top of each other they get the they have to make them all interact and when ends up working with G are reactive G RPC is that it's not one flow control system from end to end like it presents itself is that because it's reactive on a reactive on the client and reactive on the server and you'd think I call on next one on the client I'm going to get the Purdue to the server is going to produce message for me but that's not exactly true what you have is this loop over here on the Left which is on the producer side where the G and the the part in orange is kind of the active part the driving this loop the gr PC on ready handler is pull is polling or put is pulling through the reactive stack to pull the react you know yeah the reactive pipeline pulling messages out and putting them into HTTP 2's flow HTTP to send buffer up until the flow control window closes on the other side you've got your reactive observer which is pulling messages up from G RPC requesting one and then getting a message deserialized from the receiving sides HTTP buffers and in the middle over the wire is this binary flow control system opening up flow control window to request more messages the result is three different flow control systems all interacting with each other it appears to be one consistent flow from end to end but it's actually a little more subtle than that any questions about how reactive G RPC g RPC or HTTP to work and their interaction the flow control and back pressure you I think we have a question of the slack yeah looking a decent observability tool can you clarify about that I do have a demonstration which will come up next which is actually seeing backpressure live so that's what you're asking I'll show that that's pretty cool all right wonderful so this little demo here is going to show an applicant show a little program we're gonna have the SLO producer so the producer slow consumer the consumer is going to be the light orange light it's kinda all it does is read a read a message from GRP see through the through real reactive and it's got a delay in it so it just sleeps a couple of milliseconds I think like 100 milliseconds between every message the producer on the other hand is fast it's going to crank out messages as fast as it possibly can all right so let's take a look at this when we let this thing run there it goes all right the producer or so the consumer is the light orange line on the bottom that's consuming at a pretty regular rate you can see the jumping of the producer side every time it producer jumps is when an HTTP flow control window gets opened so when HTTP 2 requests more bytes and that causes the that causes the producing side of reactive to spin up and produce basically produce as much as it can as quickly as I can up until it fills up the HTTP 2 buffers and HTTP 2 pauses on the gr PC consumer side it's pulling messages at a constant rate out of those buffers see if we go and take a look at some of the code for that that demo is the backpressure demo so we here back pressure controller all right so this is actually a G RPC service what we're doing is a little proto send numbers is all it does so it's it's a service that is told how many to return and that returns a stream of number objects and so it's been find quickly produce numbers okay so there's a JRPG server in here this is oh right this is uh this is what actually subscribes when I clicked that button this is what happens we reset the graph then we're gonna create a single of five thousand this is we're going to tell the this is on the client-side map that to a number or a number of requests we're going to send it which was going to call that send numbers API we're going to map the respond results here we're doing a very simple zip with a delay of three milliseconds in this case this is just forcing this is forcing the forcing the subscription and the consumption of message is coming through that zip with to wait for a three millisecond delay and then leveraging one of the benefits of reactive we can switch our thread context over to the JavaFX scheduler and then we're going to subscribe by updating the UI and adding adding a point to our our graph on the producer side so this is we are where are we overriding we are overriding send numbers here we go from our stub because our controller actually implements the service itself where there we go implements extends our back pressure demo service implementation base on the producing on the sending side we're gonna split a simple flowable of numbers basically we've been asked how many we're going to return in our service so we're going to how many where do we get sorry all right so yeah we end up forking it and returning so all right yes we process the request publisher there we go that's what it is so we're just doing a simple flat map so we receive a request from the client and that's the client is the UI in this case we receive it we extract out we map the number to get the number so we extract out the NA of the value that was requested we flat map that into a new publisher for a range this allows us to basically print this allows us to produce 5000 messages and we're going to do that as fast as possible because there you can tell there's no governor in here slowing it down and we're gonna split that with a share and then we're going to observe it on one side to update the UI while also returning to the returning the results back via the service call the request someone was asking being new to G RPC the network traffic the network traffic is actually gonna be less chatty than the rest because it's binary serialized protobuf over the wire so all of the metadata about the structure of the message is thrown away all right so going back to our demo the important point is that the producer side of it here is producing as fast as possible the consuming side of it has a delay built in and we're not buffering or well we're not buffering for infinitely if the producer was producing as fast as it could and the consumer was consuming at a slow rate and there was no back pressure these two lines would just continue to diverge but the fact that the producer is being stair-step like this and showing the back pressure is being pushed all the way over the wire from the consumer through the G RPC stack down over HTTP to up through the producers G RPC stack and then up through the producers rx Java to the RX Java subscription and pushing that back pressure all the way from one end of the wire all the way to the other and this is using the network stack under the hood it is actually passing through TCP I can find that code do initialize there's a stub and there's a port yeah we are doing we're building a port on 9000 so this is actually even though it's all in the same process it is doing a full out to the network stack and back just to demonstrate there's no hand waving we really are serializing messages over the wire and getting back pressure from end to end oh alright so questions so far there was a question about chattiness in that case chattiness is really based on how you design your API you can make very chatty api's with very small gets and sets or you can make very chunky api's with very complex operations sending large complex data structures back and forth it's really up to you G RPC does lend itself to building really um like api's that are the right size for what you need to do now rather than forcing you to build a chatty API like you get with rest any more questions anyone got anything they want to ask over the zoom um yeah flat mesh flat mat publisher what does that do in simple terms flat mat publisher that's this right here pretty straight a simplest thing that it does is it takes an input in this case the input is of there we go we can look at that it is a function that extends our sorry in simple terms what it ends up doing is it takes for every message that comes in through the input side it's going to creates its going to concatenate together the results of a publisher so what are we doing here this statement here says given a number I want to return a flowable global net range which makes a stream in this case integers from zero to I we're then going to flatmap that which means that if we would do this over again we'd say we did one to five we could end up getting something like 1 2 3 4 5 then it resets and the next iteration goes 1 2 3 4 5 and then it concatenates the next one 1 2 3 4 5 what does that make sense so every to the Mettenberger go ahead produces a series of numbers in his flow range yes and so like ice is like a single object like a flowable exactly a drug so okay one number one input message produces many well one or more output messages and it basically produces the resultant stream is a stream of those streams all concatenated together end to end yeah yeah that makes sense okay cool thanks yeah all right so let's look at our last really neat demo which is applying reactive G RPC in a bunch of different ways got a little IRC chat like application that I built it's three different come out three different user interfaces command line Java FX and Android all three of them are using reactive reactive GRP C and G RPC just to demonstrate how this technology can be used in a lot of different contexts how the basic architecture is three different messages three different types of UI is all interacting with the server there's two RPCs one is to send a chat massive chat message to the server and you get back nothing when the other is to subscribe to an endless stream of messages so this is a new way of the than kind of a new reactive way of thinking about an API is that I'm subscribing to an endless stream of messages rather than having an observer like rather than polling the service is there anything there was anything new I'm just going to subscribe and the server is going to push messages down alright let's look at this you start up my server here this is a simple spring boot server running on 4G our PC port quad 9 the my Java clients going to start up and I'm going to start my JavaFX UI which is probably all perfect and I can start chatting between them you can see we're communicating okay and then if we come here on my little Android simulator there we go all works yes all right they're all chatting with each other wonderful okay so three different platforms mobile desktop server and command line all working together using reactive technology if we look at the code for this like it's a it becomes really really pretty simple so back pressure demo the server one the server is very that's the so that's the G RPC server side very straightforward just create a server start it put out a port the service itself is prone it's almost trivial we're going to use something Rx Java construct called the publish subject which is a thing that can be published to and subscribed to so it kind of it ends up working as a pub sub bus in memory in our case here our posting message side is as simple as broadcasting a message so this is when the users post a message we're going to our message so put our message on to the broadcast pub/sub and then we're gonna write out a log message and we're just going to return an empty so we create this pipeline that's gonna do that piece of work whenever a message comes in and when a when a client calls get message and starts to subscribe it's as simple as subscribing to that below a broadcast and returning that subscription back to the back to G RPC so now anytime a message is put on to broadcast the streaming G RPC service is subscribing to those changes and pushing those changes out to the clients you and if you look at there you go console Java this is where the real power of reactive starts to shine is that the keycode of subscribing to incoming messages and writing them out to the UI Publishing messages so every time what we're going to do is observable we're going to then create a stream that starts with the words so-and-so named joined and then continues with a concatenation of listening to this iterable which is going to pull from the console so what I did is I made a little helper class it just creates an iterator that reads from the console over and over again and so we can just subscribe to that open-ended iterable and that becomes our stream our stream is just this continuing stream then finally when that stream ends because the user types quit we'll concatenate it with it left message it's is the user left we're going to transform those strings and MSG RPC messages we're going to flatmap them so we're gonna transform them to the actual sending of the message and then lastly if there's any errors we're going to subscribe and if there's any errors we'll print them out so we've a stream that just starts with thinking about a chat program as a stream of chat messages that get published to the server through this through this G RPC call right here on the receiving side we're also going to create one where we call you were to start with an empty because it doesn't matter what the input is it gets where we subscribe to the server to its get message stream remember that's the one that's being pushed to us filter the ones out that aren't ourselves and then print them to the console so we've set up instead of having a chat application made up of a whole bunch of loops and flow control and what that what not we've redefined chat as a stream of messages going from the key to a stream of strings transformed into messages and published out through a micro service and then a stream of strings coming from a micro service and printed to the console if look at the JavaFX client as well it's a little different because we're binding is a JavaFX api instead of the console but it's basically the exact same pattern we have a stream of incoming messages which we're going to subscribe I mean we can subscribe on the i/o scheduler and then we're gonna pull those messages and we're going to call the service and subscribe to its result stream from that we're going to pull out the message and from the message from the message stream that we get out we're going to subscribe by putting those messages into the text box on the sending side we have a stream of button clicks in our case which is clicking that that send button there in the UI well that button becomes a stream of button clicks then we then map the button clicks through a function that gets the text from the textbox map those strings into messages those messages through the microservice that's through the service that sends the message to the server and then we just subscribe and when we get a response back from that we clear the text box rival departure messages is similar so once again we've rethought a user interface as in terms of in terms of stream of events coming from the server that make modifications to the UI and a stream of UI events that then get mapped to micro service requests and sent to a service and then finally when you switch over and do this in Android you know Rx Java reactive reactive G RPC and G RPC all work on the in the Android ecosystem so we have the exact same thing subscribing to incoming messages by turning the messages from the server into a stream of messages that we observe on a particular scheduler and then subscribe to the results of in this case push them out into the UI user interface of Android and on the publishing side we have a stream of click events from the Android UI that we observe through map those click events to pull out information from the user interface convert those into requests send them out into the send them out across the across the service and then when we get a response back from that we clear the text box so the same pattern of recasting how we think about complex iteration into a stream processing on a stream of events works across all these three different platforms and it's the same API it's the same technology whether you're in console server desktop application or mobile it's a really powerful paradigm it's a great way of thinking about building software so that's always reactive GRP CA making making a chat server basically trivial the right working on command-line JavaFX and android so to cam so to conclude what we have is that g RPC makes micro service is really easy starting with the proto IDL which is the single source of truth for your service we're able to generate code across many different platforms and use a technology that works across all different operating environments we bring in our X Java which is a different way of thinking reactive Rx Java or spring reactor we think of the recast the whole world as a stream of events and when we have a stream of events we can now think in terms of function composition rather than iteration and if and then and else so reactive G RPC bridges these technologies together and make sure that flow control works end-to-end and automatically pushes back pressure from producer to consumer even across the wire so why do you want to use reactive GC @ g RPC the technology is asynchronous by default everything from top to bottom is async so you never have to worry about that they sink to synchronous impedance mismatch where you're secretly blocking on something that you didn't know about it gives you a unified programming model across multiple different platforms give you a simplified programming model all of the iteration all those loops and nesting all gets just turned into a simple stream of operations concatenated together through function composition so gross code like this on the right to call a service transom to say simple code that allows you to do multiple multiple service calls and chain the results the output of one just becomes the input to the next and finally gives you consistent programming model how do you write code on mobile is the same way you were cut code for the desktop which is the same rate way you write code for the server it's a very powerful system so yeah desktop mobile mobile and console all work exactly the same well that's my presentation I appreciate you all taking time to come out and listen to it for resources encourage you to check out check out gr PC IO which is the home of gr PC reactive X home of reactive programming it's of all different kinds particularly you can find links to our X Java and spray reactor from there this project is Salesforce reactive G RPC and you can also find all of the demo code you saw today as well as the main library itself if you'd love to help out I could I would love your help things I used need the most help with spring reactor has a context propagation API that I still have yet to wrap my head around I've tried a couple of times but there's some subtle reactor some reactor context propagation bugs I just haven't been able to fix so if you're an expert in Spring reactor context propagation I would absolutely love your help otherwise porting to other languages there's been asked for such c-sharp implementation obviously that's an enormous lift but it'd be really cool to have one and there's also rx Java three-race and they came out and may be worthwhile to write bindings for rx Java 3 any final questions I had a quick question yes so yeah so with the clients an example that you have with a chat for instance the so since those er PC endpoints there they were I guess their bidirectional streaming so in that case the client just has one it's just one I guess connection does it like is um is your PC with HTTP to like suitable for just like a long lasting spy directional stream for the whole session generally yes so er PC HTTP - so it is a bi-directional multiplexed streaming protocol it is suitable for long lived connections now you do have to take into account that long lived connections over the open Internet are naturally unreliable reactive geo PC does have some retry capabilities built into it to allow you to put a retry operator in place so that shouldn't this you know should the strain drop because the underlying connection was severed it will continue to basically tell gr PC reconnect and rikka reattempt the stream so it'll send the connection the request again and subscribe to the stream that doesn't always work on that that semantics doesn't always apply if you've got something complicated like I need to send you know a stream of requests and get a stream of responses so you may have to do some stream renegotiate connection renegotiation logic which is actually pretty common in most gr PC applications a deal with the long-lived streams but kind of thing that kind of code kind of lives in they use it in like user space because it's really hard to it's very application specific as to how you want to do your stream renegotiation sure thank you a question about our socket yes I am familiar with our socket it uh it is different than gr PC so I'm not here to make a stand as to which is better they both have their place I know about our socket and it is a very cool technology if anyone's interested in porting reactive G RPC to reactive well actually reactive our socket is because our socket is natively reactive so never mind but you know if you're interacting with something that's gr pc-based and you want to do reactive this is a technology that can help you hey I had a question that I think you got swamped before in the in the chat so can you elaborate on the use cases for reacted your PC in you use that self force and that's sure yeah I mean if it impacted you I mean it doesn't have to be necessarily positive because I've seen resistance to reactive programming as well well if you have a positive feedback and matrix you can share that that can be great I'd love to share that I am not aware of anyone at Salesforce who is actually adopted reactive gr PC as much as I'd love to it to be getting as you said getting reactive programming in into an organization can be very challenging I am aware of other other companies out there who are using a reactive gr PC I believe they're using it successfully because they're building some pretty power some big applications on it but yeah I can't really no one at Salesforce is using it that I'm aware of all right thanks yeah getting an organization to adopt reactive technology is a whole nother presentation yeah I know that I had another question actually um I was wondering if in terms of like performance if you saw any I guess like performance hit by relying on rx Java instead of just using the you know what GRP C Java comes out comes with with our company for instance we tried to do something similar with Farakka streams in Scala but we found that there was a performance when at least with our implementation with akka streams and so they're just wondering like in terms of your benchmarks that you saw any tax yeah we do have a benchmark project and I pull up the main repo I've been amazed we do actually have a somewhere in here the benchmarks not under Interop now where I forget where the benchmarks are but we do we did do some benchmarking I don't recall there being a dramatic difference between reactive gr PC and Raw native gr PC the majority of your latency is going to be in the network so if you're adding a couple of you know if you're adding a small amount of latency in process I don't recall there being any real major performance hits ah there they are benchmarks we do it will fall we do run the same set of benchmark tests that gr PC runs we saw our comparison it wasn't significantly different if I may I could add one or two things yeah so we when we have written our Xterra to and and reactor a few years ago they they came from a same project we we call the reactive streams come on we try to make sure that it was the least impacting on the performances when we always compared with normal sync sequential programming so we'll follow for instance compared to you a flat map and we try to avoid a maximum a lot of a location a lot of volatile touching volatiles and queues if we can we have some kind of internal optimization inside these reactive libraries to avoid creating queues when not necessary because as soon as you have an a synchronous boundary most of the time you need a a queue for message passing and we try to do all of this optimization it unfortunately made the code for our X and reactor pretty difficult to read if you want to dive into that and help you know with issues but the trade-off was to minimize the difference the gap with programming just the usual way without you know using any function all the types the other thing I would say is if you so the the overhead is pretty minimal but if you want to use the reactive stuff with something with latency like gr PC I think that's at this point very negligible like you never see any any gap because that's that's not the operation and the cost of this operation that will take any time that's that's the network latency or your Parisian latency and maybe I will add a third point which is it's not necessarily making things faster using a reactive library or reactive and to and it's mean first and foremost to make things scalable and more efficient that doesn't mean that you will do like a better request per second-- fruit but that means like something more like resource utilization if you are busy doing something you're not forcing your system to do nothing until you finish with this thing you're doing with the concurrency you gain by using the reactive libraries you can do you can utilize more few resources and at the end of the day that means you're saving maybe more instances or you run in your your system on less instances in your cloud and that you know that I quote equate to something at some pilots way I was I was pretty interested in if there was a use case for reactive jar PC at Salesforce because that's the kind of point of view from companies the usual the traditional reason for adopting reactive libraries to make system more efficient so they cost less to operate alright well if there's no more questions I will hand it back to Alexia alright guys thank you very much that was really a good talk and I think we have a lovely discussion in the slack so my question basically would be if folks are interested in more kind of open general discussion if you guys so Stefan basically led us into this if anybody wants to share kind of experiences modernizing your company with this basically it's all yours right so I just wanted to see one request I have if you want to speak please if you can turn on your video that will be you know easier thing on folks to see somebody making their points also it's easier to identify who it is speaking because zoom makes is hard to find out otherwise so the floor is yours I shared this signup sheet for the unmeet op nobody signed up sign up yet so this is all good we're kind of you know trying different ways what in other experience I heard that folks like to kind of do hallway conversations with each other slack can allow this right they can chat with each other one-on-one but unfortunately in this room we can kind of generally do most of the main talks so but if anybody wants to to share anything right now please say so as they say in the wedding or forever hold your peace let's see one question I have for everyone if you guys maybe raise your hand who thinks that 5 p.m. is a better starting time than 6 p.m. that would be really helpful if you guys can do that okay I see some hands okay and who thinks that 6:00 p.m. the old standard starting time is better who'd rather do 6:00 okay fewer hands I see and one more question I want to ask so since we're now a global meet up we have a lot of folks who want to join from Europe and in order to let them easily join we really have to start early so if we're in Pacific cost we can do a 10:00 a.m. or 11 a.m. so for those of you who are kind of doing enterprise zooms I'm not really sure what's happening in the world kind of work from home so if you think that you can do a 10:00 a.m. or 11 a.m. meet-up as an attendee if that actually works for you I mean we can do noon which becomes lunchtime in the US on the Pacific coast kind of three you know on this coast so I wonder if that works if you can raise your hand if you can do a morning meet up if you would be if it would be okay with you that way we can you know invite Europeans to present okay Ryan is for it anybody else raise your hand if you cannot do this if 10 a.m

we're 11 and absolutely doesn't work it's not a good idea for you you're all like in work stand-ups and zooms or whatever it's okay nobody says it's not possible all right cool okay one one okay so Larry says funds up I don't know if this is like you cannot do it or he can do it I'll ask you so all right later all right so I don't think we have any more immediate top proposals so what I encourage you guys please let me know we are really remembering this up I will be focusing a lot on the reactive technologies in conjunction of everything else so please let me know if you want to give talks about it in various spaces in various domains for instance telcos we heard before how it enables other things like machine learning streaming you know streaming data analysis everything goes our you'd see is perfect let me know thanks everybody again for joining I'm really excited about this and thanks again to Ryan for the great talk and a great presentation thank you guys if nothing else see you later