gRPC in WildFly

Friday, 24 July 2020

Recently the RESTEasy group has been looking at protobuf and gRPC and 
discussing how they might fit into the JAX-RS world. We now have a 
feature request (https://github.com/wildfly/wildfly-proposals/pull/326) 
for exposing JAX-RS resources as gRPC servers 
(https://issues.redhat.com/browse/WFLY-13530). Briefly, it would work as 
follows. Compiling the proto file

service Greeter {
   rpc SayHello (HelloRequest) returns (HelloReply) {}
   ...
   }

will create a class GreeterGrpc, and a gRPC service can be created by 
subclassing an inner class. Rather than implementing a gRPC service, we 
propose passing the request to the appropriate JAX-RS resource, 
something like this:

class GreeterImpl extends GreeterGrpc.GreeterImplBase {

    @Override
    public void sayHello(HelloRequest req, StreamObserver<HelloReply 
responseObserver) {
       JAXRSForwarderBuilder builder = new JAXRSForwarderBuilder();
       builder.servlet("ResteasyServlet").pathTranslator((String s) -> 
("test/" + s)); // Configure the JAXRSForwarder
       JAXRSForwarder forwarder = builder.build();
       forwarder.forward(req, (StreamObserver) responseObserver);
    }
}

The gRPC infrasture would catch a request, dispatch it to GreeterImpl, 
and the JAXRSForwarder would

   1. create an HttpServletRequest and an HttpServletResponse
   2. find and invoke the appropriate RESTEasy servlet
   3. pass the result to the gRPC StreamObserver

The idea is to hide the complexity behind the JAXRSForwarder.

Now, this proposal is limited to extending RESTEasy. However, Darren 
Lofthouse has been reading it carefully and has suggested that it could 
be part of a larger discussion of how WildFly could incorporate gRPC. 
Some discussion points:

   1. Right now we're proposing to open a dedicated socket for the gRPC 
infrastructure, which runs on top of Netty. When Undertow incorporates 
Netty, maybe gRPC could share a socket with other subsystems.

   2. Maybe there should be a separate gRPC subsystem.

   3. Maybe we should go beyond servers and consider supporting gRPC 
clients. For example, maybe gRPC clients could be injected into JAX-RS 
resources the same as MicroProfile REST Clients.

   4. Darren has suggested that Elytron should be involved.

In fact, I'm going to quote one of Darren's recent remarks:

...
     Starting to research gRPC myself it feels like the kind of thing
     where the general support / strategy within the application server
     should be defined, the individual subsystems such as JAX-RS and
     EJB which want to expose their existing deployments would then
     dynamically make their resources available through this. For areas
     such as security this would be provided consistently within the
     general support.

     For gRPC initially if feels like it could have a good fit with
     CDI, I don't know how practical that would be and if it would
     cause a lot of considerations that may make it a better fit as a
     SmallRye project. On one side if that gets too complex it may be
     something that makes more sense as a SmallRye project to define
     how gRPC deployments are handled, on the other side unless the
     exposing of JAX-RS endpoints is 100% automated including the
     protobuf generation it sounds like a level of user deployment may
     be necessary anyway which may mean deployment handling is required.

     I think the exposed socket is possibly less of an issue compared
     to the general strategy. Maybe it will be necessary to expose a
     separate server socket for now, I would have thought something
     like this could justify it's own subsystem which would mean it can
     be defined in it's own Galleon layer but that would mean as a
     subsystem it could follow a similar path the Remoting subsystem
     took i.e. exposing a port and once possible adding support to
     delegate through Undertow.

     Regarding the other comments about how this could integrate with
     Undertow, the main motivation for gRPC seems to be the use of this
     binary protocol we probably should be cautious that we are not
     adding too many layers on our side that requests need to be
     translated thought otherwise we may be negating the benefits from
     the outset.

     Recently the tasks I have been working through have involved a lot
     of DeploymentUnitProcessor refactoring to restore better
     collaboration between subsystems regarding how they share security
     policy information, so far it has been slow going and considering
     backwards compatibility there is still quite a long way to go.
     This is the reason for something like this I am interested in the
     overall architecture first so we can hopefully avoid this kind of
     retrospective refactoring as we need to enhance it further. 

Any comments are welcome.

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013