Jakarta EE Tech Talks, 9 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Jakarta Tech Talk | Jakarta RPC: JAX-RS for RPC Services | November 9, 2021

Description

Jakarta gRPC aims to do for Java gRPC services what JAX-RS did for REST: it makes them easier to implement, by allowing developers to annotate service classes and methods, and by generating client-side proxies automatically, based on the annotated Java interface. It also allows them to integrate and play nicely with other Jakarta specs, such as CDI and Config, which is something native, proto-based gRPC services do not do very well.

Another goal of Jakarta gRPC is to expand the ecosystem by making the services more marshaller-agnostic than they currently are. While the gRPC protocol itself, and its various implementations, including Java, are not tied to any particular serialization framework, the available tooling pretty much limits the choice to ProtoBuf, which is not always the best choice.

In this session we will cover how we plan to achieve all of the above via recently submitted Jakarta gRPC specification.

A

Hello, everyone and welcome to another jakarta tech talk joining us today. We have alex shovik to discuss jakarta. Arts pc alex, is an architect at oracle where he works on oracle coherence, a leading, in-memory data grid product.

A

If you have any questions for alex as we move through, today's presentation feel free to ask in the chat or using the tab at the bottom. So without any further delay alex over to you.

B

All right, thank you, kaylee all right, so it's really sad. uh I work with oracle architecting the coherence team and I'm here to talk about a new proposal for jakarta grpc and just to give you some background, a brief history. How we came to this point I mean back in 2011.

B

We were looking for a way to implement native clients across multiple platforms, for coherence and- and you know it's- you know we had our own technology that we wrote years ago, but you know in the meantime, a lot of things have happened, and so we started looking at what frameworks are out there to make remote calls from different platforms available uh and grpc obviously came to the forefront. So we started working on the implementation.

B

We did the initial implementation of our server uh and started working on some clients back in 2017, 2018 and in the process. We realized that what we've built actually is uh more than we need it's something that really makes more sense within the application framework within the java, ee spec, or something like that.

B

But at the time you know what we decided to do is to contribute to helium kelly then was recently released, and you know we talked to people on the teledom team and decided it made sense to move our implementation to helidom and we rewrote it pretty much completely in the process to make it look more like jackson, jax rs, which is what kelly the news is for web services for s services.

B

So we try to do something similar for grpc and then about a month ago. We actually said that you know even even helidom as it is, is not really a proper home for it. This thing is more general than that. We really should propose it as a spec, and you know whether we propose this microprofile spec.

B

It's valid on this microprofile implementation or proposed jakarta spec, and we actually decided to propose it with jakarta spec because, as I said, it's very similar in how it looks how it feels and and its purpose to jax rs uh when you you know, accept when you're writing grpc services instead of fresh services. So I have a link here to the proposal where you can find more information about what we are proposing, but I guess I'll I'll walk you through most of this stuff anyway.

B

So because the first first question: whenever I see a new proposal, I don't know why I mean what is it intended to solve and there are actually a number of goals we wanted to wanted to fulfill. So we wanted to make grpc services easier to implement.

B

We also wanted to make clients easier to implement, which we saw is that you know, as we were working with grpc, we realized it was a big pain point and there is a lot of boilerplate that you need to do in order to implement both services and clients, but mostly mostly clients.

B

uh We also show that you know there is the integration between grpc java implementation and things like jakarta, ee, specs and eclipse microprofile specs is not quite where we want it to be. We wanted to use things like cdi, et cetera and and kind of grpc java out of the box makes it a bit difficult which I'll get to in a minute.

B

uh We also wanted to have better support for modern java to be able to modularize applications, which is also a bit tricky and finally, from our perspective, because we we have our own serialization formats and you know, customers can choose their own civilization formats to use with coherence, etc. We wanted to make sure we support uh marshalling of payload in any in any format.

B

So you know, grpc as it is, is somewhat format agnostic, but but it's very much the tooling and documentation everything is geared towards protobuf and and we couldn't afford to use only prototype. I we are fine supporting protobuf, but we need to be able to support other formats as well.

B

So before I go any further, I mean this is not a knockoff on grpc java. Jrpc java is uh awesome. I mean we like it. We've been using it for the last four years since version one five, one six or something like that, and the goal of this pack is not to replace grpc java anyway. It really is to make its usage easier and to make it more seamless for the jakarta pe developer or eclipse microprofile developer, to write grpc services and clients.

B

So, let's go, and you know, let's go into it a bit different talk about how we propose to do this, so the first thing we wanted to do is to make services easier to implement. So so we can understand what the difference is. Let's look at. How do you how you implement grpc is the standard way if you're, just using plain grpc java. So the first thing you need to do you need to define your messages in a profile and it's fairly straightforward.

B

But you know it is a work that we don't think is always necessary. So you define messages that are going to be passed over the wire and then your pc java will generate classes for these messages you can use within your application.

B

Then you define a service interface, which looks something like this: to define a service, give it a name put it in a package, and then you define a number of rpc methods that are either unary, which means they take one one request and return one response or their server streaming, which means that they return a stream of responses.

B

They can also be client streaming, which means that they send multiple requests to the server and then expect one response back or they can be bi-directional, which means that they effectively have a pipe open between the client and the server, and both the server and client can send messages to one another at any point in time.

B

So once you once you do all that, you need to configure maven plugin to generate service stub, and then you need to implement the service and and the way you implement. The service is by extending uh a stub generated based on the profile you saw earlier by the maven plugin we just so configured, and then you override the methods, basically that the stuff that grpc generates uh only has methods that throw unimplemented operation exception right.

B

So you go ahead and you basically override every single method defined in that service interface, and you do your implementation and the way grpc methods are implemented. You basically have your parameter. There's always uh one argument that you get that you get as as as a argument as a method called argument, and uh you can send one or more responses back depending on whether, but whether the method is joinery, server, streaming or whatnot right. So even when you're sending single value back the way you send it, as is the case in this example.

B

The way you send it is by using stream observers. So grpc assumes that there could always be more values right. So it gives you this reactive api which they call stream observers. So you can send one or more objects, so you can call on next with with the with the payload on next.

B

You can call it multiple times and then once you're done, sending all the all the responses, then you can just follow on completed and mark request is completed and obviously, if, if there is an error, uh then you need to call observer on error to not play the client that an exception happen right. So that's effectively, I mean, as you can see, there is a lot of wallet like here right. There is one line which is task equals our api.

B

Our service create task with some description and then everything else is really grpc infrastructure, but try catch block, uh all the polls to observer, etc, etc. So how does that look like with jakarta jrpc? Well, you only have that one line right, so we have a set of annotations that tell us what the service is so because we don't have profile. In this case we have grpc annotation. That gives service a name which is fully qualified package and service name. uh We also in this case configure a marshaller.

B

We want to use json as a payload, and we configure this as cdib by doing applications called to the class level and then injecting our dependency inside of the service and then the method itself. Really I mean you will see a big difference here is that we don't take stream observer as an argument anymore. We could that that format is still supported, still supported, but we've simply marked methodism.

B

We returned the value that we want to return and then the framework under the hood does all the grpc specific stuff and and sends this task that we're returning back to uh back to the client it calls on complete or it gives the case. There is an exception when this method is executed. It calls on error and passes that exception back.

B

So obviously, this is not exactly the same as the service we just saw because the this one uses protobuf. So it uses task message, not task and we have to do some wrapping. So we get a task from our service implementation from our api and then we have to wrap it, convert it into a task message, which is a protobuf class, that the protocol generated class that we want to send back, because that's what api expects. So in this case, because we're using json, we don't have to do. We don't have messages.

B

We can just use our standard java folders as both or native java types like string. We don't. We don't take string value, which is a protobuf type as an argument we take string and we don't return task message, return tasks right, so it makes it when you're not working with photobuff.

B

It makes it much easier to implement services because you can just reuse classes that you already have, and you don't have to generate pretty much anything now. If you want to implement the same exact services you saw, then it's a little bit different like we don't. You know, we specify the the name that the grpc clients generated from that protobuf file will expect. So you know we put service in the appropriate package and give it give it the right name. uh We and then we mark we implement method exactly the same way, uh except now.

B

We use protobuf types as as arguments and the current values, and we still need to because our api internally, our implementation, uses our domain model. We need to convert our domain model into protocol message, but other than that the implementation is exactly exactly the same, and the only thing that changes really are these arguments and return values.

B

So that's that's pretty much it on the server uh and there is obviously I mean in this case. We are looking at binary method, but we support other method types, so you can also annotate your methods with uh server streaming. If you want to require multiple values- uh and we also have some return value optimizations for that. So if you return java, you till stream of values back and mark method, the server streaming then you'll effectively. You know just take that screen read values from it and stream them back.

B

One way, one by one and complete once the stream is exhausted.

B

So the next step is, you know: how do we make clients easier to implement then going back this? This seems a bit repetitive, so you know with your pc job when you're implementing clients, you still take that protobuf file, so you probably still have the files. You define your messages, you define your interface now.

B

The interface can be the same, but it doesn't have to be the same right. So you know it may be the same artifact that you already have from the server. It may be a subset of it right because you could have a service that is, for example, just read the only service and only cares about these formattings right. So there is no reason for you to take the full broadband file and tie yourself to the full api on the client.

B

uh Because, more you know the more things change in the server the more chances there are that you you're gonna be broken right. So you know something changes in incompatible ways, but so you could generate uh the client interface a client stops that only have methods that you care about. Then you probably should. But that means that you actually have to maintain multiple profiles for different things. You may need some messages on the server, but not from the client, etc, etc.

B

So you end up having multiple architects to manage, and then you again need to configure maven plugin, which is fairly straightforward, but just step, and then you need to initialize now now, when you're using this, the grpc will generate uh client stops for you, and there are actually three different client stops. There is blocking stuff, there is non-blocking stuff and there is future based stuff. The problem, though, is if you want to get access to the full grpc api of your service.

B

You actually have to use the the native grpc stuff that uses stream observer the non-blocking one, because both the future based up and the blocking stuff are actually very limited in the in the type of methods they support. I believe blocking only supports uh lunary methods and future may support server streaming, but I don't think it supports client streaming and in bi-directional.

B

So in the end you know, if you want to use full jrpc api, you have to use uh blocking. uh You have to use non-blocking stuff that uses stream observers and in order to do that, first, you need to create a channel right in order to create a stub. You need to configure a channel.

B

So in this example, I'm just going to create a very simple channel that connects to your pc server on localhost port 1408., and then the next step is to actually implement your client that wraps that wraps the stuff that you're using because stub is very much in defined in terms of proto-generated classes uh such as task message in this case and our application works with something. That's that's in our domain model. We need to conversion here and again, if, if we want to do a blocking blocking client apis, that is the case here.

B

uh We basically need to figure out the way to block right. So one way to do that is to create completely future, and then we call our method on the stub classic stream observer and that stream of zero effectively completes the future either successfully or exceptionally, uh depending on whether error happens or or not, and then in the end, we simply block waiting for the future to be completed one way or another right. So again, there is a lot of boilerplate here pretty much.

B

All of this is this for the plate right, because all we are doing is calling a method on the stuff that we know exists. That is, that has effectively the same signature as the method uh that we defined at the very top that you know we're calling this within and everything else is just grpc infrastructure code. So all of that can actually be simplified and that's kind of what we do. We took the same approach that the eclipse micro profile.

B

Rest client did so you effectively define an interface on the client and you define the methods on that interface and the arguments and the return values and all that stuff right, and this should match the server right, and you know the method names will be used for to match grpc method names. The service name from the grpc annotation will be used to find the service on the server.

B

Again, you have the ability to configure martial martial order to decide how the payload portrait return, type return, values and all the requests and responses are serialized, uh and that's that's pretty much it once you do that and again. If you want to define smaller interface, you just define a smaller interface just commit the methods you don't need, but there is no profile to deal with in this case. It's just java interface here and if we're looking, I mean.

B

Obviously this is this is json interface again and if you want to see the proper interface, it's exactly the same. In this case, we're just saying: grpc martial is protobuf and we're returning task message and taking string value and boolean value. Follow buff types as arguments instead of java native string, then our domain task task class.

B

So once once we do that, all we need to do is inject your pc proxy, where we want to use it. So in this case we have our application code of task manager and we simply inject your pc proxy uh with that with the interface we defined earlier right. So we have to do this. Prpc client interface, we inject proxy, for it, and- and we can call methods right so in this case we're using protobuf proxy. So we're going to get.

B

We're going to take string converted to string value and pass it to to the underlined service and in this case, we're using json proxy. So we just take string and plastic directly directly, as is.

B

So the next thing, as I said that we want to address, is better integration between grpc and jakarta and eclipse microprofile specs, and the first thing that we looked at was cdi support and on the surface it looks like it would be fairly simple. Grpc provides the base class. You do your implementation, that extends it, you mark it with application scope, you inject something into it and you just use it like any other cgi cdi being. Unfortunately, if you ever try to do that, you know that you will run into this.

B

The problem is that the the base class is generated by by protobuf compiler, based on the rpc service definition. Actually has this bind service method, which is final and cdi refuses to proxy.

B

So, unfortunately, I mean there are workarounds, and you know this is something that I've done, for example, so you can, you can create actually manage bean that yeah, I typically put it as an inner class within the within the service class itself, and just call it managed service which simply delegates buying service method. It doesn't make it final and wraps the service itself now notice that it doesn't need to delegate anything else right.

B

I mean we use constructor injection in this case, so we can construct the actual you know the actual protobot generated or well our implementation. That extends probably generated class. We can. uh We can fully configure it via constructor within this beans constructor, and then we don't really need to delegate any other methods because they they're never really called. I mean the way grpc works under the hood.

B

Every method is, it has its own definition, and it's really that matters definition that determines what the method is called on in this case, because the client service of the actual service implementation itself, the one that that is, that is, that is final in the generated class.

B

That's what actually determines what the method is going to be called on, so this is just a way for us to get dependency injection to work. It's just a workaround, but you know we don't like wordpress. We want to make it simple, so you know jakarta. Grpc, really cdi support is not only there from the beginning. It's kind of required, that's how we discover services and register them with a server etc. Right, so we'll look for any bean that has fgrpc annotation when you're starting up and we'll register it uh with a server.

B

So this is it really. I mean we saw the example earlier, it's it's it's there. It works out of the box. There is really nothing special that you need to do to make cdi work.

B

The second area we wanted to improve is configuration. So obviously an ngrpc java is powerful, but it's fairly low level. So you know you need to create channels, you need to define costs and ports. You need to configure tls et cetera uh programmatically, so we wanted to provide. You know. Skeleton is micro, profile framework. We wanted to make sure we want to use micro profile config to configure it to configure both the client and the server. So you can do something like this right.

B

You can define your grpc channel, define server host port, even tls information, we'll see an example later and then you can simply annotate your client with the channel or even better, I mean well, it depends. What's better, I mean it's, it's it gives you more flexibility, so if all you need is to connect to a single server, then annotating client interface with the jrpc channel is the way to go.

B

But if you want different injection points to connect to different servers using the same client interface, then you can actually annotate injection point the grpc channel it will determine which server to connect.

B

The next thing is better support for for modern java and what we primarily mean by this better support for java module system, and- and you know this is kind of a long-standing issue. I opened this issue back in. You can see it on the screen back in september of 2017 and unfortunately, this screenshot was taken a couple days ago when I was when I was working in this presentation.

B

So this this issue is still open and just had quite a bit of activity and comments on it and a lot of people asking for the grpc java team to fix it, and you can see things like this and things like this etc, etc. But, ultimately, it's a it's a hard issue for them to solve, because the issue is effectively a split package in some of the modules that they have, and you know there is no non-breaking way to fix that, and you know they still have to worry about.

B

Android usage and requirements for grpc java can be used on android devices and whatnot, so that kind of they have to support older versions of java as well- and you know it's been- it's been a difficult one to solve and that's why it's still open more than four years later now we did solve it in inheritance when we were working on this because skeleton at some point moved to java 11, plus only in version two all and we basically had to repackage grpc in a way that doesn't that eliminates the split package issue.

B

So our implementation. This is not necessarily part of the spec, even though spec should ensure that whatever implementation supports, it works properly in the java module system. So it works with java, 11, java, 17 and future versions of java. But you know it is a solvable issue. You know as long as you repackage vrpc java yourself. So that's basically what we did and it's been working fine for us since, since 2019.

B

And then, last but not least, as I said earlier, one thing that we wanted to make sure we can do is support payload marshalling using different formats right. So you know, protobuf is fine, but it does require it to kind of translate between protobite, because everything everything is generated from photobuff is final. You cannot add methods to it. You cannot really extend those classes. If you want to do anything, you really have to you know, I really can only treat those classes as messages.

B

Is that that's what they were designed to do so you know you have to take them on both ends on the wire and kind of underwrap them and convert them into something that your application can actually work with. So yeah and that's fine, but it's not always a deal and, as I said, we wanted to make sure that payloads can be supported with other formats like if you're working with with kafka you'll probably want to support avro. And you know, if you don't have to do conversion from one format to another.

B

You can optimize things to make them more efficient if you're, using coherence, you're, probably using puff if you're, using you're using json or visa- or you know same thing with oracle, json database and you're going to be. You know your application is going to be using a certain format, and you know if you, if you don't support it, formatting the wire between those services, then you have some additional work to do to unwrap those messages and convert them from one form to another.

B

So when we started looking into this initially, we realized that marshalling of any format in grpc is actually supported, maybe too well. Basically, every every method. Every grpc method that you define allows you to configure both the requests in a response marker. So you could technically have you know every method in a service use different marshaller for the incoming payload, for the request and for the for the outgoing payload for the response right.

B

So you know there is no reason you cannot have one method coming in the json format, return protobuf another one comes protoblock, you're, turning off, etc, etc. So you can really do whatever you want. The problem is practically. This is really not exposed because documentation on how to do. It is pretty much non-existent to me other than java dots and reading through source code and figuring out how to do it, and the tooling, as we saw earlier, pretty much depends on and only supports protobuf.

B

You can expect it to write those proto files with messages and and rpc service definitions, and you know generate code from them and push them start there right go from there. So we wanted. We wanted to make the underlying features that jrpc already has more more exposed. So what we came up with is basically allow you to have named marshallers and on any service uh you define which martial you want to use by default. We'll use protobuf because that's kind of historical default for grpc services.

B

So if you don't specify anything, we'll assume it's it's problem, we'll just go above marshaller, but you could override it. You could say that you want to use json for this service or you can use cloth or you can use you know even java civilization, although it kind of deprecated that because of security issues and whatnot, but you know whatever format you want, you can actually write martial or for it register it and use it.

B

So any martial are supported the same way. Protobuf is the default. So if you don't specify marshaller, you will try to use protobuf as a default. uh At the moment, as I said, you configure marshaller for the service. So it's not at the request response level. We could easily support method level overrides. So I don't think we do at the moment, but we easily could I'm just not sure how useful it is.

B

Typically, you have a formula that you want to use and use it use it throughout use it for all the all the methods and the service. But you know it's a it's. A feature we could easily easily have and implementing new marshallers is fairly fairly straightforward. So in this example, I'm configuring json marshaller. This is, for the most part, there's some bits that are missing here, but for the most part, this is the the implementation of the jason marshall, and there is really nothing to it. You need to be able to.

B

This is json b to serialize object to json returns, open stream. It returns input stream with the generated, json payload and then same thing the other way around when we get json payload, we parse json from that input stream into into a class of a given type. Now, because we need to know the type for some of these things. For you know. Fortunately, martial art is defined at the method level.

B

So, even when we use json, we can configure multiple json marshallers for different types right and in order to do that, we have what we call martial or supplier. So this is actually what's what allows us to create martial arts. So if you, if you say that your service should use json martial or we find a supplier- that's named json and we use it to get the new json marshaller for a given type. So that's really what what makes this whole thing work all right. So that kind of concludes the intro part.

B

So let's look at the demo here, so I have because again this all of this stuff already just you're, proposing it, as fact, but I'm using helidon implementation of what we're effectively proposing to demonstrate everything. So on the server I have four different uh service implementations. I have my role grpc java protobuf based implementation, so you can see that I extend generated class. I have my services proto file here, with both messages and service interface right, so extend generated class which can be found here.

B

And I over the method, so I have my constructor that injects my service api. I have my helper that converts tasks that my api returns or takes an argument into a task message, and then we have methods implemented right. So we have create tasks, which is the method we saw on the slide, and then we have get all tasks which again is very similar, so you may call our api. We call observer uncompleted here in this case, because we are actually streaming tasks back.

B

We call that both ask me. We map every task returned to the task message, and then we call observer on next and then, after we stream everything back to the client and then call and complete it right uh same thing with get tasks except it takes completion as an argument. Fine task delete task right, but, as you can see, it's very very, like every method is very similar. You have your try catch block your calling observer on next time, complete on error, etc. Right. So that's our uh plain grpc implementation at the bottom.

B

I have the workaround I mentioned earlier in order for our server to discover this service and register it. We have this uh cdi bean that allows us to inject api and repository implementations and then configures the actual service with it right.

B

So, if you look at it all together like if not counting workaround plus, we have about 220 lines of code, most of it boilerplate, we have the exact same service uh written using, jakarta, grpc, kelvin, jrpc and proposed proposed jakarta here in suspect. So we have we're putting it in a different namespace, because we're gonna run all of all four of these services on the on the same server. So we need to put them in a different name space.

B

uh We don't specify the marshaller so if we use proto by default, but in this case we don't need any workarounds right, we're also configuring interceptors that get into that a bit later. So we want to use logging interceptor to see when the requests actually, when the calls are actually made in this service on the server, uh and we still need to do the wrapping and unwrapping of the task. Conversion of the task message, but now our methods are much simpler right.

B

We simply have unary method and then we call api crea task and convert that to task message, get all tasks simply that so you know, the only thing that's left is the actual code that does any work, so we have server streaming streaming methods, etc, etc.

B

So, all together, this saves us about 100 lines of code or so so. This is really the whole implementation of the of our grpc service and these implementations are fully compatible. There is nothing different if I rename this service and basically run it to the same endpoint that the raw plane grpc java client expects it to behave exactly the same as the as the one that was created based on the generated class right and then we have the same implementation but using json.

B

In this case, you can see that we configure grpc marshaller json, uh we again inject our dependencies. We have the methods that look exactly the same now the difference here is now. We are just using our regular java beans. We don't have any generated message classes. We don't have anything. We're just using plain you look at if you look at that, it's just uh ignore the portable type, that's actually post support which I'm gonna get to in a minute. But this is basically just a regular java folder that we are using.

B

Right and then the first, the fourth service implementation and again this service is the same as the json lights and 100 lines of code. In this case, actually we do have. This is something to point out. uh We do have couple methods here that actually take message because again grpc right, I wouldn't call it limitation exactly it's just the way it works. You have single request coming in, so you cannot have multiple arguments in this case.

B

We need to pass the id of the test to update and the value to update within that task right, so we need to wrap them some way using this update description request, which is basically just id and description in this case. These messages are just regular java study classes with public properties, because eventually I mean what then really hoping this is. This is all using java 11 still, but this really should be java records if you're using java, 17 or higher.

B

So so that's the json implementation of the service, and then we have the same thing but uses coherence, portable object, format as a civilization, civilization format, which is again it's a it's. A binary format that we recommend clients use if they're using coherence. So if we get messages in performance, we can actually do things more optimally. If you're back in this coherence, you can just pass them through in any case, and that's actually, what coherence grpc service for the native clients does so it's very similar to json.

B

The only difference really is that marshaller is different. Everything else. Implementation wise is the same, and then the messages are slightly different because they have annotations. It will allow us to generate civilization code for puff from them. So that's that's it and then on the client. We actually have four different clients.

B

um We have the plain grpc proto client, which uses.

B

Which has a client that's a wrapper on generated stub, so you can see the code that I showed earlier on the slide here. We create a channel that connects to localhost 414.8, which is where I'm going to be running the service on your pc server on. uh We have a method now that does conversion the other way from task message to task, and then we have a bunch of rappers around the stuff that hold the stub and then complete the future with the result, and then we block on that future.

B

So pretty much every single method here is implemented implemented. That way, so you can see how this gets a bit cumbersome and we have almost 300 lines of code here and if you look at the same thing for our teledom product client. Let's look at that one, because that's exactly the same, all we have is this right. So in this case we explicitly configured the martial arts proto, which is something you can do, um configure the service to the photo service. We have on the back end and then we have methods that we wanna.

B

We wanna be able to call right. So that's, that's all there is to it and then within our task manager, we simply inject your pc products.

B

So without going, I mean the other two clients json client offline. They look effectively the same as this product line. I mean the only difference really is that they use they use task and string and boolean instead of task message and string value and boolean value full value from from protobuf right, so they just have different marshaller configured and obviously request messages that they need to send to the server.

B

So, let's see, if all of this works, let's start this server.

B

This is always so much slower when I'm presenting them and I'm not.

B

All right so there's something I'll show here, so you can see that yeah, we're printing, the logs that grpc server started and it registered a number of services. So we tell our examples product to the list with these methods. This is actually the native grpc java service. Then we have our off service, which is jakarta valid and grpc service.

B

We have json service and we, oh actually sorry. So this is probable service that uses jakarta grpc, and this is for the service that's generated from uh from the photograph file. Then we also have, because we run interference inside of this process as well.

B

We have appearance, name, cache service was discovered as well that we are not going to be you're not going to be using, so we're going to start uh first client, but let's start the value on color client, so the client is really I mean I showed you that the actual class that interacts with the with the grpc server, but the client is actually this javafx application that connects to this server and then it can create tasks, complete tasks.

B

Okay, so- and I want to show you- I want to show you here, because this is a proper, jakarta, grpc client. We should actually see that logging interceptor should print out calls, and you can see that it did right here. You can see that when this application started, it called it registered for events to receive from the server and it called get all tasks, and this was server steering, method and marshaller that we use this message- marshall, which is wrote above message marshall.

B

So we can create some tasks here.

B

Right we can complete tasks, we can clear completed et cetera and, as I'm doing that you can see the calls are being made to the examples proto to do this service right. So now I can also start the grpc prototype, which is going to be talking to a different grpc service, but in this case you'll notice that when I make the calls I mean everything should still be reflected, because now both clients are actually listening for events coming from from the server.

B

So you can see that this client already has the state and just to give you an idea, so I'm going to go into server and let's bring both clients on the screen.

B

So now I have kelly, don't find jakarta, grpc client on the left, hand, side and then grpc java client in the right hand side. So because this one is not a proper jakarta jrpc service, we don't have a way to configure interceptors the same way, so there's actually no interceptor here. So I can create tasks and you can see that task is created, but nothing is being printed out in the server because different service is being hit and we are not getting.

B

But if I use this one, then again you see that sync between both parts for perceiving events in this case this that code and obviously we can.

B

Start off client and we can start.

B

Json client, so now we have.

B

And you can see on the server that these points have been started. They already made the calls here.

B

Let's bring just these two in this case, so now we have the same clients that we saw earlier, but this this one is using json.

B

And this one is using off and again anything I do is reflected in any of them. I can bring the other two clients.

B

And you can see that they're, so they're, all they're, all talking to the same server they're all using same back-end data store but they're, actually using different payloads different service. End points, different service implementations on the back very similar service implementation, but actually different instances of service different instances of the methods with different marshallers.

B

So that's it for the demo. Let's go back to the slide and tower and we have a couple more minutes. So I want to talk about some some additional considerations because you saw like you know everything. I've shown so far uses blocking clients and servers. So everything is synchronous, but we, you know compared to your pc.

B

Absolutely I mean grpc itself under the hood, like server is always non-blocking and then clients can be either blocking or non-blocking but effectively, as I said earlier, that the only stop that allows you to access full power of your pc is the non-blocking one. So everything is non-blocking under the hood, so we wanted to expose expose that as well. So, in order to do that, what you need to do is really just change this, which is the example of our blocking client to this right.

B

So they're, really, if you look at it carefully, they're really only two changes here: the return, type changes from task, completion, stage, task or computable future task, and then the return value changes from future join to future itself. So in this case we're just going to create a future, submit the request and then return that feature and then eventually the future is going to get completed.

B

So this allows you to basically use a completable future api, so you can say in the caller of this method you can say when completed or handle or whatever, whatever you want to just use full power of the completed future, and you can do the same thing on the client right. So you can go from this to this right and you'll notice that it only changes for lunary methods, because the the methods that like get the whole task- I didn't actually cover this earlier, but I should have so.

B

This is the optimization that I I said we have right. So if you return stream of something from a server streaming method, then it will just send all those values back one by one and then complete when the stream is exhausted, uh so yeah those are already non-blocking right, I mean they'll just send stream values back, but the ordinary ones that used to be blocking are not non-blocking as well. So you're gonna call the method. You'll get your completion stage back and you can call right completely. You can join whatever you want to do.

B

And then on the server side same thing, so this is your blocking service, and this is your non-blocking service. Now, in order to implement non-blocking service, there is an assumption that you have some kind of non-blocking api that you use to typically access your data source, whether you use reactive database, api or you use something else to use, react to api or active async adherence api. Any of those things will allow you to to do this, but basically you need a back end that allows you to do things in a non-blocking way.

B

If you don't have that, then it becomes a little bit tricky and using just exposing. This is playing blocking services and letting us worry about unblocking when, when necessary, is probably the easiest way to go.

B

So another thing that I briefly touched on and we saw it kind of working on the in the server demo is interceptors right here. Pc allows you to define both server and client-side interceptors. It can modify the request, modify the response, add security, information to it, etc.

B

So, in order to to use those, uh you basically have couple ways you have: you can define interceptor bindings in this case we're saying: okay, this is log annotation and we're marking it with vrpc interceptor binding, and then we create our interceptor and we apply that binding to it right. So you say okay, so when, when anything is empty with log, then this is the interceptor. You should use right, and this is just again cdi beam, multi-grpc, interceptor and you're locked into super binding.

B

So the actual implementation is just this point: grpc io, jrpc server interceptor right, so it just prints out the call information and then.

B

When you define the application, you can simply annotate your service with log, or you can annotate individual methods with this annotation that the interceptor will be applied. If you annotate service, the interceptor will be applied to all the methods. If you annotate methods, the interceptor will be applied only to specific method.

B

uh You can also just you know. You can also not create interceptor bindings and just specify the interceptors explicitly. So if you have interceptor classes, they don't even have to be, I think, I'm not sure cdi beans. At this point I mean you just list them in a grpc interceptors list and they will be configured for the methods on the service and the same thing with clients. Right, I mean exact same same thing except you're. Interested for implementation in this case implements client interceptor, which is slightly different interface from the service interceptor.

B

And finally, last but not least, I guess security. So, as I said earlier, we do have support for configuration that extends not only to what the host import is, but also to tls configurations. You can specify whether pls is enabled what is disciplinary certificates and key default paths uh in a kubernetes deployment. For example, this can be read from from kubernetes secrets and and the server can be configured that way uh and then we also plan to support. This is not supported at the moment, but by the time final spec is out.

B

We plan to support jsr with 50 security annotations, just like most frameworks doing in in jax rs, so you can define who has access to what end point, the specifying roles allow permit all denial etc. So that I believe, concludes everything I have. uh You can get a source for the demo. I just showed from this link, so all the all the clients and the server implementation.

B

Are there there's one client missing here, so I guess I took this screenshot earlier. There is helidone grpc client, take care of kelly on product client missing, but all four clients and the server are there. You can run the example yourself. You can review the code. If you have any questions you can reach out to me on twitter on slack, I'm not sure, I'm not sure, what's the best way to reach out, but yeah twitter's, probably good, uh and with that I will open it to any questions. Thank you.

A

Thank you alex for that presentation. uh I'll just remind everyone in the audience. If you do have any questions, you can throw them in the ask a questions tab at the bottom or the chat and, in the meantime, I'll just go through a few things here. So we are looking to book more jakarta tech talks into 2022, so if you're interested in presenting you can feel free to fill out the form which I will link in the chat as well. If you haven't already done so, we encourage you to register for the jakarta.

A

One live stream december, 7th it's our largest jakarta event of the year and you won't want to miss it. So you can also register for that with the link I am putting in the chat now, so you should have both of those. um Let me just go back here. I don't see any questions, so, if that's it then I'd just like to thank you again alex for the presentation today. I hope everyone has a wonderful afternoon.

B

A

Thank you, bye.