<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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
      (<a class="moz-txt-link-freetext" href="https://github.com/wildfly/wildfly-proposals/pull/326">https://github.com/wildfly/wildfly-proposals/pull/326</a>) for
      exposing JAX-RS resources as gRPC servers
      (<a class="moz-txt-link-freetext" href="https://issues.redhat.com/browse/WFLY-13530">https://issues.redhat.com/browse/WFLY-13530</a>). Briefly, it would
      work as follows. Compiling the proto file<br>
      <br>
      service Greeter {<br>
        rpc SayHello (HelloRequest) returns (HelloReply) {}<br>
        ...<br>
        }<br>
        <br>
      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:<br>
      <br>
      class GreeterImpl extends GreeterGrpc.GreeterImplBase {<br>
      <br>
         @Override<br>
         public void sayHello(HelloRequest req,
      StreamObserver&lt;HelloReply responseObserver) {<br>
            JAXRSForwarderBuilder builder = new JAXRSForwarderBuilder();<br>
            builder.servlet("ResteasyServlet").pathTranslator((String s)
      -&gt; ("test/" + s)); // Configure the JAXRSForwarder<br>
            JAXRSForwarder forwarder = builder.build();<br>
            forwarder.forward(req, (StreamObserver) responseObserver);<br>
         }<br>
      }<br>
      <br>
      The gRPC infrasture would catch a request, dispatch it to
      GreeterImpl, and the JAXRSForwarder would <br>
      <br>
        1. create an HttpServletRequest and an HttpServletResponse<br>
        2. find and invoke the appropriate RESTEasy servlet<br>
        3. pass the result to the gRPC StreamObserver<br>
        <br>
      The idea is to hide the complexity behind the JAXRSForwarder.<br>
      <br>
      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:<br>
      <br>
        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.<br>
        <br>
        2. Maybe there should be a separate gRPC subsystem.<br>
        <br>
        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.<br>
        <br>
        4. Darren has suggested that Elytron should be involved.<br>
        <br>
      In fact, I'm going to quote one of Darren's recent remarks:<br>
      <br>
    </p>
    <blockquote>
      <blockquote type="cite">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.<br>
        <br>
        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.<br>
        <br>
        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.<br>
        <br>
        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.<br>
        <br>
        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.</blockquote>
    </blockquote>
    <p><br>
      Any comments are welcome.<br>
    </p>
  </body>
</html>