[wildfly-dev] gRPC in WildFly

[Scott Marlow]

On 7/24/20 1:55 PM, Ron Sigal wrote:
> 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.

+1 for ensuring that gRPC support doesn't create any security holes, 
good to hear that Darren is helping!  :-)

> 
> 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.
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>