 is a developer advocate for the Google Cloud Platform. Ray is also a DevOps guru, has built a number of applications for a number of different companies, worked on a lot of open source projects, and likes photography and traveling. So, go ahead, Ray. All right, thank you very much. Thank you. I hope you are all applauding at the end of the talk as well, yeah, just saying. Cool, so this time it's going to be GRPC 101. Now, what I learned yesterday is that 101 is not a common concept in Europe, apparently. 101 just means that it's the first university session, an introductory course kind of thing. And my name is Ray. I'm a developer advocate for the Google Cloud Platform. And if you have any questions about today's talk, please, please contact me at Twitter, on Twitter, at Sidenizen. That is my Twitter handle. If you don't like to talk, please contact me on Google Plus, because I don't think you will be using it. It's kidding, no, I hope you do. No, I'm just kidding. If you have any good or bad, just let me know on Twitter. All right, aside from developing applications, I've been a developer for a long time, and did a few architecture related work. Project management and all that. But my other passion is definitely just traveling and photography. So if you want to see some of the faces I've been to, check out my Flickr, also under the nickname Southernism as well. Now, I have a lot to talk about today. So I'm going to breeze through some of the introduction stuff, and then jump into some of the code to show you exactly how this works. And the reason I wanted to do this talk as well, which I constructed, is because that there's a trend of microservices. I'm not going to go into any of the theories or whatever, like what you should be doing it, what you should be doing it. But if you do want to, say, create a microservices application, or if you do want to develop any source of distributed systems, one of the things that you're going to realize really, really quickly is that we're going to be breaking down like a single application, potentially, that we traditionally do, into multiple ones. And there are consequences for doing this. So you need to know why you need to be doing this in the first place. And also, the consequences are potentially you need more DevOps, you need more ways to manage and being able to deploy and monitor these different individual instances of your application or your services. You need to provision for them and such. But there are a lot of worries, but there's one thing that people often miss is, how do you communicate between the two services? How do you actually do that? And I think today, most of the times, we kind of fall back to, well, let's use REST. It's JSON over HTTP. It's well-known. And that's kind of the default choice today. But be careful, though, just remember 10 plus years ago where some other technology was the default choice. And you also have consequences for those as well. So I want to show you something new, hopefully something you'll like today as well. But then you may be saying, RPC, that sounds a little familiar, no? RPC is being around for a long time. I don't know anyone here used Corbott before, anyone? Yeah? You loved it, I think. So just for the research, for my talk, I mean, I done this a long time ago. But I found this great tutorial. I mean, it is a really good tutorial on how to use Corbott. Let me just make sure you can see this. I mean, first off, with most of the RPC frameworks, you're going to start off with the IDL, like Interface Definition Language. This is so that you have something intermediate that's language agnostic. But then you can use this Interface Definition Language to generate code for many other languages, right? So that's pretty straightforward. We have in this example, there's an app. You do addition for two integers, okay? Just two loans. Just keep down your mind, just two loans, okay? And then you generate the code. This is a tutorial for Corbott, right? You generate code, you have the stop, and then you implement the operation, right? That's pretty straightforward too. I mean, yeah, not bad, just one method. And then what got me is when you were to implement the server. And just to add two integers together, this is where you have to go through to start the server, which I just got completely lost. And then if you scroll down a little bit more, I mean, this is a great tutorial. If I ever need to do Corbott again, this is the tutorial I would look. And then this is what I need to do to generate the client or is to use the client. And again, there are a number of things here that I don't understand. For example, Nero anymore, and naming context, and all that stuff. So that was the state of art for RPC. No wonder, I guess, nobody really think about RPC anymore. And then there's CCOM, there's RMI, which is great for Java developers. But the problem is, well, first of all, you can create Java code, right? You can write interface, you can write implementations, you can expose them as a remote service, and then you can just invocate it. It's really nice, it's really easy to do. However, it is not so interoffable, right? Even though it's so easy to use, you can't really interoff between different platforms, different languages. And then somebody had an idea of, well, what a second, why don't we just use XML for the interchange, right? For the messaging format, it's machine readable, and it's human readable, kind of, as well. And then we have this thing called SOAP, which we can do both styles of remote codes, we can do document style codes, we can do RPC style codes as well. Regardless, well, we came a long way, right? Now today, the state of art is JSON over HTTP, or REST for services in most cases, but why would you even consider RPC after what I went through in the past couple of minutes? Well, think about this. First of all, RPC is hopefully, or definitely, gonna be a little bit more efficient than, say, JSON over HTTP. Why? Because in most cases, they are going to be binary, they're binary protocols, right? So I remember years ago, people are saying, well, SOAP is too slow, XML too slow, well, guess what? Anything with text is going to be too slow for you. So that's why RPC still has a place in the world, because they are mostly just gonna be binary messaging. They are strongly typed, because you define everything through the IDL, it's strongly typed across multiple languages, unless if you use something else, that's, you cannot do typing, I don't wanna mention which one. And then think about this, for the REST for services, most of the times you operate on a resource, and you are limited to kind of the semantics of the HTTP verbs, which are the guests that put the patch, right, the delete. They are mostly CRUD operations. Now, if you want to implement some more complicated business processes in a remote procedural call, for example, or via JSON over HTTP, right? How would you actually do it? Supposedly to transfer money between two accounts, right? What is the right verb to use for that? How do you actually implement a REST for service for that? In RPC, you can simply define an operation that says transfer, and then taking two parameters, and that will define the service. So RPC can, in my mind, can only be great. It was great, but it can be better and be great in being used today, only if it's simple to use and interoperable between different languages. And that is where GRPC comes from. Now, at Google, we actually use an internal framework called stubby. Stubby is our internal RPC framework. It's used for just about everything for remote procedural calls. And we handle about 10 to the 10 RPC calls per second with stubby. It was made to be very, very efficient. Now, just imagine if we need to make that 10 to the 10 number of calls with REST or anything else, it may not be as efficient, right? Not only that, if it just takes one byte bigger in the message size than it's necessary, we're looking at 10 to the 10 more bytes that we have to transfer across the wire, right across the data centers. And what happened is that Google wanted to open source stubby, and another company, Code Square, was trying to make the next generation of their RPC from work as well. So I think what happened is that, well, I heard what happened is when they joined forces and they said, well, why don't we just open source this stubby thing all together and call it GRPC? And that's where GRPC came from. It's actually coming from the best practices of both companies, in a way. Now, the GRPC is fully open source. The G in GRPC does not stand for any companies I know of. It is a recursive acronym. It's GRPC Remote Procedural Code Framework, okay? It is simple to use, which hopefully you'll agree. It generates idiomatic bindings for the languages. It is definitely performant and scalable, as we saw in the past slide, and it's interoperably extensible. The underlying technology that's being used are also open source, or they are standards. For example, for the IDL, it uses support about for three, which is another open source project from Google. And the payloads are all binary, and they are, of course, put about for three payloads as well, which is made into efficient binary payloads. The underlying transport between services is using HTTP2 rather than HTTP1. Now, why is that important? Well, HTTP2 is also a binary protocol. So, number one, what happens is then, you don't spend a lot of bytes on just describing the verbs, right? The guess, the pull, the patch, whatever. The headers are being compressed for you, okay? In HTTP2, header compression is there. So, rather than spending, again, a lot of bytes just to specify all of your headers, they're all gonna be compressed for you as well, via the algorithm called HPEC. The strings are multiplexed. So, in HTTP1, what happens when you need multiple connections or strings? Well, you open multiple connections, or you do pipelining and such. Well, in HTTP2, the multiplexing is default in the transport. So, you can multiplex multiple strings so you don't have to open up multiple connections. And I said the word streaming. Streaming is also default and native in HTTP2. So, rather than dealing with WebSockets, you can actually do client-to-server streaming and server-to-client streaming and bidirectional streaming as well. And that's all built in into HTTP2, okay? And just to show you what that feels like to be on a binary protocol, here is a demo page, okay? So, if I have internet here, so that's HTTP1, which is loading, what, 200 small images. And that's HTTP2, but here is, I guess, false names really fast here. Yeah, but yeah, there you go. So, on average, you can definitely see HTTP2 is going to be much faster. Now, another really, really neat thing is the server can actually push it out to the client before the client even asks for it. Now, that's really cool. Just imagine you're in a situation where well, the client requests like index HTML and you know for a fact that they need like a CSS and all these other things. Well, guess what? You can just push it to the client before they even ask for it, okay? Now, it is a binary protocol. So, of course, we expect it to be faster. So, this is a comparison that they have posted on a public blog actually, the throughput comparison. And with the same machines, you can see that, you know, obviously you can get more throughput. But what is more interesting to me though is the throughput per CPU, okay? And that's important because we're quickly moving to what people call a cloud native world. And that doesn't necessarily mean you run on the cloud, but what that means is you wanna be as efficient and nimble as possible for your services. And with GRPC, you can process more with less CPU. Now, what that also entails is that if you do run this on a mobile devices or smaller devices or IOT devices, well, it's going to be more efficient as well. Supposedly, hopefully also use less battery for the same amount of data that you're trying to transfer. Now, I want you to focus on the languages that the GRPC can support, a number of them. My favorite is Java here, but I wanna focus you on three, which is objects at C, C sharp and Java. That's because these three languages are being used in mobile devices as well. GRPC was made with mobile first in mind, right? So you can use GRPC on the client side from these mobile devices, whether it's an iPhone or iOS or a Windows phone or an Android phone, okay? So, let's see it. Let's see how much time I have. I got 30 minutes, well, great. Okay, so with GRPC, what I'm going to do, first of all, I'm gonna implement a very simple client server thing, so you just get a feel. And then next, I'm going to do bi-directional streaming with a real-time chat application with GRPC. And I'm going to hopefully, I'll do that within the next 20 or 30 minutes or so. All right, hopefully, I said. All right, so with GRPC, the first thing I need to do is to use the IDL to define your payload and your services. And these files are gonna be called the portal files because there are portal buffer three definitions. And to make sure we're using portal buffer three, we need to first say syntax is portal three, okay? Now, I see a lot of many hands who are Java developers. It's okay if you are not because hopefully the sample will make a lot of sense. But in this IDL, it's universal for all languages, right? And just like in Java or in many other languages, we have the concept of a package or a namespace. So what I can do is I can say, well, let me put it under this package, right? So all the payload, all the services is going to be generated under this type of package. This file is going to be processed by a generator, right? Basically, something that generates the actual source code that stops. And that generator can take different options. So for example, I can say something like option, Java multiple files is equal to true. What that means is, well, by default, it's going to generate all the classes into a single giant Java file, right? With everything inside. You can specify options for the generator and this specific one just says, well, for any of these payload and services, let's generate a different Java file for it, okay? So that's how you kind of set this up. Now, the next thing you do is to define the message. Okay? And the syntax is pretty straightforward. You just say message and I'm going to say hello request example. GRPC is just working based on the operation and the request and the response, okay? And in this request object or payload structure, whatever you want to call it, you can define multiple attributes. So for example, I can say string is equal to a name, a name field, and I can assign it a tag. Now, you can see here it's strongly typed. The name of the field is right here, but then you assign it an integer tag, right? That's because this tag is actually going to be the bytes that you send across the wire to identify this field uniquely within this message payload. So rather than sending the string, that's name, we're just sending the byte over, okay? Or however it takes to send the integer over, okay? So I can strongly type everything here. So I can say age is two, for example. I can even do enumerations or enums. So for example, I can say enum is a sentiment. That's how good we're feeling today. I'm feeling pretty okay, so I'm gonna say happy is equal to one. Let's see. It could be a little sleepy right now, which I hope not, but I saw somebody yelling, but so sleepy, I'm gonna say sleepy is equal to one. Happy is zero. And then by the end of this talk, it might be extremely angry at me, so I'm gonna say angry is equal to two, right? So once you have defined this enum, you can say sentiment is equal to three, right? Again, don't get messed up with the equal signs because you're saying the tag is equal to three, right? You can do, if you need a list of things, you can use the keyword repeat or repeated string. And I'm going to say hobbies is equal to four, something like that. And you can also do strongly typed maps or just hash tables or something like that. So I can say map, and I can strongly type the key and strongly type the value. And I'm gonna say bag of tricks goes to five, okay? Now life coding is definitely not my bag of tricks here. All right, so you can do a lot of those, right? Pretty straightforward. And I can do the same thing for the response. String and greeting is equal to one. Now the tags just need to be unique within the message payload itself. The next thing then I can do, once I have the request and the response, then I can define the services. So I can define a service called greeting service, for example. And here I can define the operations, the RPC calls itself. So here I'm going to say greeting and I'm going to taking a hello request and I'm going to returns, returns, hello, response, okay? And that's it. That's all I need to do to define this interface. Now, in GRPC, you can do streaming as well. You can do bi-directional streaming, client-side-to-server, server-to-client. And that's because we are using HTTP-to-behind-the-scenes. To make something streaming, all you have to do is to add the keyword stream and that's it. So in this case, if I add the keyword here, that means, oh, this is a client-side stream. So imagine if you have like devices that need to stream metrics to the server, well that's probably what you would do. You say client-side stream. If you want the server-side-to-stream responses back, like in a chat application, then you just put the stream in the response and that becomes a server-side-to-client-side stream, okay? All right. So now that's all good. Now, next thing I need to do is to generate the actual stops, okay? Now, the generation of these stops is a little bit different across different languages, but there are tooling for it. Now in Java, I like to use Maven, so you can use a plugin in Maven working. If you're using Gradle, you can use a plugin in Gradle as well. So what I can do is go to the gRPC page. So here is the gRPC source code, gRPCs.grpcjava, and they got different ones for different languages as well. Now if I scroll down, they got instruction here. So for example, I can add in the dependencies. I'm gonna do this fairly quickly, dependencies, okay? And then I'm gonna add in the build plugins here. Now that's Maven. Don't be scared. If you're in Guido, you can see it's slightly easier, right? All right, it's really up to you on what you wanna use. Okay, good. Now that's, oh, sorry. Let me just go ahead and do Maven clean. And let me do a Maven package. So what happened now is that the generator is tied in into the packaging phase or the compile phase, sorry, the compile phase of the cycle. Now what's interesting here though is that this plugin actually downloads the right binary for your architecture. So if you're on a Mac, it's going to download the Mac version. If you're on a Linux, it's going to download the Linux version of the compiler, the gRPC compiler or the generator. Okay, different platforms needs a different binary, but they really made it easy for Java developers to get started as well, okay? So that's good. So now if I see target, I should be able to see generated sources. And here I got Podobov and I got Java. And here you can probably see it. I have the request and the response generated. This is kind of expected, right? Then let's go ahead and implement some of these things. I'm going to write about 300 lines of code. I'm just kidding though. So first of all, I'm going to create an implementation class. So I'm going to say greeting service, input. No, please don't add it. And how do you zoom in here? There you go. Okay, so in this class, what I want to do is to extend, for example, the stops and probably going to be doing this for most of the languages as well. So I'm going to say extend the input base. And then I just have to override and implement the method itself, which was called greeting, right? And here I can see that I get a request and a response as a observer. Now this is interesting because in this stop, on the server side, this interface with this implementation or this metric signature looks like something that should be invoked asynchronously, right? So rather than having the response on the left-hand side as a return value, you give the response through the observer as a callback. So on the server side, everything is implemented with async in mind. Now the client gets to choose whether they want to invoke this synchronously or synchronously, but on the server side, to handle all of the cases, it's implemented as async by default. So here I can do something like I'm going to print out the request, for example. I can do that. I can create a response, hello response. Now in Java, in GRPC implementation, they love to use the builder pattern. So everything is done via a builder. So what that means is I can get a new builder. I can set the greeting field, for example. I'm gonna say hello plus request.getname, there we go. And I'm going to build this. And I'm going to assign this to a local variable called response. And then what I can do is to return this to the client, guess what, I use the observer. So this is called the response observer. And here we have three messages. We got unnext, completed, and unarrow. What that means is if you do catch an exception, you throw it back via unarrow, if you want it to be sent to the client. If you need to send data to the client, you call unnext. Now even though this is a unary call, meaning the client is only expecting one response, you can actually call unnext multiple times, which is not good, right? If you do it, it's going to give you a runtime exception, but that's the way that this interface works. Now are we done? So I say, hey, go and send this response to the client. Now here's the tricky part. You have to call uncompleted as well so you can close the stream. Otherwise the client will be hung and it will be waiting for the next thing forever, or until the connection times out, or until you call uncompleted for it to move on, okay? All right, so far so good? All right, so now let's go ahead and implement the server to start this, to start a server is extremely easy. They love the builder pattern, so there's a server builder, I'm going to zoom in a little bit here. I'm going to say server builder dot full port, I'm going to listen port 8080, and then I can go ahead and register this service that I just created. Basically you can just give it the new instance of that implementation and build, and assign this to a variable called server and you're done, okay? And once you have this reference, what you can do is to just go server dot start, and that's going to start the GRPC server in the background thread. And so before they, I don't want this main thread to exit, so I'm going to say await termination, okay? And that's it, that should be it for the server, I hope. How many people think this will work? Oh wow, wow, thank you, thank you, yeah. Just for the record, on the video, nobody raised their hand until I said thank you. All right, anyways, I don't want to say it. So sad, all right, let's try this. It's unbelievable that this will work, and I agree with you. So let's see, naturally it worked. So what happened is the server is in the background thread and I'm not printing anything, so this is it. So the server is running, I think. All right. So let's go ahead and... The server is on, that's a potential too. So the only way to try this out is to implement the client, all right? So, if it doesn't work, I gotta fix both things, right? Now for the client, I gotta establish a connection to the server. Now rather than dealing with the TCP connections yourself or even the HTTP2 connections yourself, they abstract everything away and they give you this thing called a channel. So what I can do is to create a new channel, and I do that through a pewter, of course. I can do, for the local host, Port88, okay? And I'm going to use plain text just because I'm in the dev environment, I'm not setting up any SSL. And let's go ahead and build it, okay? And I'm going to assign this to channel. Now this interesting part here is that, let's see here, I can do a name resolver, yeah? So this is, currently this is just point to point, right? The client to the server that's well known. If you do need to low balance across multiple services or multiple GRPC endpoints, well you have two facilities that can help you. One is called the name resolver, basically helping you to give a service name and identify and return a list of endpoints that the service is being served from. And on the client side, you can then set up a low balance factory to low balance across the list of endpoints. And you can provide your own low balancing strategy or you can use the default one, which is more like a wrong robin strategy, okay? So now once you have the channel, you can create a stop to send traffic over the channel. And to do that, I'm gonna say GRPC, sorry, greeting service info GRPC. I can say a new stop. Now here's the interesting part, right? At least in Java, when you do a new stop, you have three options. I mentioned before, the server is always implemented asynchronously, but it's up to the client to decide whether they want to block or not. So you can create a new blocking stop, which will block this call and get the return value in where you expect. You can also get a future stop, which will return you a Java feature, where you can use the asynchronous stop as well. So for this example, I'm gonna go ahead and just use the blocking stop. Okay, and I'm going to assign this to a variable stop. Okay, now we can actually make the call. So I can say stop.Greeting, okay? Hello request. I'm gonna use a new builder, okay? And in here, what I'm going to do, I'm going to set my name to Ray. Set age, O, 18, yeah? Yeah. Add hobby, so I can say coding, right? I can put back of tricks, coding, not live coding. Okay, something like that, right? So as you can see, it generates all the methods for you. It's all type safe. As soon as you stick with it, it's going to generate the right payload for you. And then I'm going to get the response back. Now, because this is a synchronous stop, I can just get the response back, oh, sorry, yeah, it's a blocking stop, so I can get the response back in the return value. And in the end, I'm going to go ahead and print it. Okay, I'm gonna try this again. How many people think this will work? Wow, the same number of hands, okay. I guess I have to work harder. Okay, so here, I'm going to do a package and do an exact. Let's see, let me just zoom in here. I'm gonna move the response out of the view so you can see it. I think it worked, I'm just kidding. All right, let's score it down. Hold on a second, I'm gonna score it down. There you go, right? So you can see that it actually connected. Wow, thank you. That's too easy, that's too easy. And on the surface side, you can see we also generate all the two strings for you. So you can, if you really want to, you can print this out. So you can see all of the things I entered, okay? So that's not so hard. That's pretty simple and straightforward for a simple service, I would say, right? So the next thing I need to do, I think I have until 11.20, right? 11.20, 15 minutes left, great. So in the next couple of minutes, what I'm going to do is I'm going to, you know, write some, a few more lines of code to basically create a real-time chat server in the chat client in Java with GRPC by using bidirectional streaming, okay? So I'm gonna close these out. If I go to chat server, most of the bootstrapping here is done because I went through the basics already. So the only thing I wanna show you is the photo file. Now in this photo file, like I mentioned, if you want a streaming service, you just put stream on the side that you want to stream. In this case, I want bidirectional streaming. So I got stream on the left and stream on the right, okay? And it's going to generate a stub that looks like this line to implement. So I'm gonna open up the service implementation here. Okay, now don't be scared. Again, every language is a little bit different. This is just how Java works. So it's a little bit more verbose here, but it's fine. It looks perfectly fine now. So a few things I wanna touch on here is that all the message passing is being done through a code back interface called the stream observer. Whatever the client sends the data to the server, guess what, the server will have a stream observer that listens to on next. When you want to send the data back to the client, we already saw you're going to get a stream observer reference and you're going to code on next and send it out to the client. So in this case, since this is bidirectional streaming, so what I'm going to do is I'm going to create basically return a new stream observer that will have this on next implementation that's going to be listening to the data from the client. And what I have done here is every time the client connects, I'm going to add it to a list of clients that's currently connected. And so what happens when I receive the message from the client is I need to broadcast it to all of the other clients that's currently connected as well. So for that I can do, I have a list of observers. I can use a stream and I can say for each of the stream O observer and I can do an O down on next, right? And here I can give it the chat message. Now what the chat message looks like? Well, I'm going to, I typed it specifically to call it chat message from the server so that there's no confusion. So I can do a new builder and build and I can assign this to the variable chat, for example. Now what goes in here is going to be the data payload I want to send to the client. So I'm going to say, oh, let me see here, new builder. Yeah, there we go. So I can say set message and I'm just going to take the message in that's on the client, okay? Now it should be it. So I'm iterating through all of the currently connected clients or observers and I'm going to send everyone the same thing, okay? Number one. Number two, if the client gives me an arrow as O Java developers do, we do nothing. I'm just kidding, here I should probably remove the observers from the stream. So I do a responsive server, right? And I'm going to do the same incomplete. That's it, that should be the server. Let me just make sure I got all the things closed. All right, that's not so hard, it's bi-directional streaming in a few lines of code. Mostly auto-generated for you by IntelliJ. All right, so let's see here. So I'm going to run this server. Hopefully this will work as well. Okay, very good, server is hung just like before. Yeah, okay, that's a good sign given the history. All right, so let's go ahead and implement the client, okay? So now I have a Java FX client. So just so I don't have to deal with other front ends, so what this client looks like is if I do Java FX run, okay? So basically you can, whoa, what just happened? All right, basically you can type in the name and you can say hello and hopefully when you click on that send button it's going to be sent to the server. And hopefully also you are going to see the message payload coming back, okay? So that's the thing we want to implement. So here I already have established the connection. I opened up the channel just like before. I created the stop. Now this stop is actually the async stop. So what that means is you actually get the stream of servers in both ways as well. So let's make a call. So let's see what that looks like. So chat service dot greeting dot chat, sorry. It's going to take in a stream of server and it's going to return you a stream of server as well. Okay, so chat message stream of server. Okay, so let me just make this a little bit more sense. I'm going to say chat messages to server, okay? So in this next, this next callback will be triggered every time the server sends a message to me, okay? So every time that the server sends a message to me, guess what, I need to add the messages, the message into the view. So what I can do is I just say add. And here I can say, well, what do I need to add? I'm going to add the content of the, whatever that's being sent to me. So I have the front field, okay? I'm going to plus. I'm going to add in the message field as well, the actual text. And that should be it. Now, because I'm running JavaFX, I should be running a platform run later. And what that means is because I need to execute this in the UI thread. So that's what I'm going to do. When I get the arrow from the server, you guessed it. Let's not do anything for now. When I'm complete, I'm not going to do anything either, okay? Now, when somebody press on that button to say, hey, I want to send a new chat message, what do I do? Well, let me make the call. So I'm going to say the send button, set on action, right? And it's going to give me an event. And what I can do is here, I can then make the call to send the data to the server. How do I do that? Through the observer. I'm next, right? And I can say chat message.newbuder.bude. And let's just make sure I got this all connected up. So I can say the message from, which is the name.gettext. So that's what people entering the name field. And then I can say the message and that's message.gettext, okay? Whew, life coding. All right. I think that's it. I really think this is it. I think. All right, I'm going to do another poll. How many people think this will work? Wow, still? Okay, okay, more hands. All right. All right, let's try this. Let's try this, because I have no idea. All right, so I'm going to do jump. Oh, wait, wait, wait. That's not going to work. I need to compile first. So I can do either way. Let me do package and, oh boy. All right, so just so you know, the source code, if I open it up, so I'm not cheating. All right, I'm now running this off of another server here. Localhost, it's going to localhost on point 9090, which is what I'm listening on. All right, so let's try this. Ray, hello, Boston. Oh, first thing, first thing. That's too easy though. That's only one client. I could easily have cheated. So what I'm going to do is I'm going to start another one, okay? And I'm going to zoom in a little bit. Do I see a familiar faces here? No, not yet. So what I'm going to do, I'm going to be my manager. I'm going to be a great, that's my manager. I'm going to say, good job, Ray. All right, actually it works. Okay, so that's how easy you can use GRPC. Hopefully you see some of the benefits. You know, again, it works with multiple, multiple different platforms. Now before I close up, let's see, I got three minutes. Do you want to say, there's a lot more than just simple requests and response and streaming. You know, streaming is simple now. You can also set deadlines. So if you're making multiple services calls, and just imagine you're doing a distributed call to multiple, multiple services and servers, and one of them is really slow, or some of them is really slow, but you gotta return stuff to the client. Well, what can you do is you can actually set the deadline for the top level service call, and it will be propagated to all the services that's been needed. So if the first call takes one second, and then the subsequent call takes two seconds, and your deadline is two seconds, currently you have a total of three, well guess what, that entire stack will be canceled. And the client, so the server side will receive a cancellation notification as well, so you can close up the transaction cleanly. You can also propagate metadata. So you can do this via the HTTP headers, and you can also propagate context. So you can pass the same variables across multiple services within the same boundary. If you need to go across boundary, across network boundary, then you need to propagate the data via metadata. And that is particularly great, because then you can do something, you can do interesting thing, like putting a security token on the top. You can do distributed tracing with interceptors. You can pass in the trace IDs across all of your services. There are actually really, really good ecosystems around JRPC at this moment. You can do low balancing and server search trees, and you can do some health tracking as well. You can find a lot of this information on the JRPC website. Just go to jrpc.io. We want to hear your feedback, and we want to get your contributions as well. It is fully open source. Come to the IRC, check out the Twitter, and join the forum groups. And a lot of these things are actually on my GitHub. So if you wanna find some of these code, just go to github.com slash satanism, and you're going to see some JRPC Java examples. So thank you very much for your time. Any questions? We've got time for questions. Wait, we have five minutes for questions. So, questions? Question number, sorry, I see the hands over there first. Yeah, definitely having a really hard time to hear. Sorry, I can't hear because of the auditorium. Could you be able to speak? You'll save later? Okay, I'm so sorry. Oh yeah, so go to the jrpc website, and oh, sorry, repeat the question. So how efficient is it, and how do you check, right? If you go to jrpc website, there's actually a link to the jrpc performance testing suite. So you can actually see the historical performances that they do on the jrpc releases. And that's all open, you can actually just check the link and see it. There were other questions here, yes? Thank you. Yeah. And I really can't understand why Google guys resist on shipping the native C binary to the operating systems, instead of just writing the native Java compiler for the problem. And they did the same, so I'll say with the black belt. I do not buy the fact that it's a deficiency of the name. I think you should really write your own native language compiler for the problem. Right, gotcha. So I think that there's a trade-off between something that's fully customized. You can even do more efficiency if you go over your own transport, for example, go straight to TCPIP. But I think there's a balance between the efficiencies that you get, the interoperability that you get based on some of the de facto standards out there. So yeah, I absolutely agree. I mean, you can always go more. I love to hear more of these feedback afterwards as well. Yeah. Yes, one more question here. Is it faster or more performance than divas? Well, I don't know if that's a good comparison, to be honest. So no comment on that. I don't think that's a good comparison, to be honest. Yeah. Last question over there. API versioning. Does your PC have some of the best practices for API versioning? So yes, actually, one thing I didn't mention is the message payloads, because it's based on pull the buffer. You can actually, it's backwards compatible in most part, unless you delete one of the fields. And if you do delete some fields in the same payload, in case you do want to do it, what you want to do is, for example, you don't want to reuse the tags. If you use a tag that was deleted in a new field, then the client or server is going to get really confused. What you can also do is reserve some of these tags so that they don't ever get ever used again in the future. Yeah. So I think that's all the time I have. You take one more question. One more? All right, I see over there. Yeah. So with microservices, you have to be loosely coupled and, no, not have dependencies between the services, right? So with GRPC, how do you address that fact? And your start of the talk, you also talk about not only between the client and the server, and also between multiple services that make use of this. So how do you create a loosely coupled with a strongly tight system? So how do you create a loosely coupled by strongly type system? Well, I would actually want to think of them as separate, right? I mean, you can be loosely coupled but still tight, right? Think about in the rest world where you are loosely coupled but not strongly tight. What happened is, potentially, you will send data or receive data that you never expected. And people are trying to kind of make that slightly different by having a really good definition language of swagger, yeah? So we expect certain things, where in two microservices being developed by two different systems, but still we ensure that these are not dependent on each other and fail because of each other's mistake. So what you want is to make sure that you define the service contracts in the payload cleanly in the puto file. And that would be the thing that defines the contracts. And that's the thing that you pass around to different services that needs to consume the service, right? I mean, think about this. It's not many. The IDL, you can think about it, is not much different from, say, a swagger doc that cleanly defines a rest service. Or I hate to say this, but it's like a whistel, but much, much more complex, right? OK. OK. We take one short question. Short question. Say short question. Does it support inheritance? I'm sorry. Does it support inheritance? Oh, let's see. It's mostly composition. Does it support inheritance? It's mostly composition, but in short, yes, in a way. But you've got to compose the objects together. You can also import. So one thing that I didn't get to show is that you can import types from another puto file as well. And you can reference to that type strongly typing as well. Yeah. Thank you. All right. Thank you.