wildfly-proposals
wildfly-proposals copied to clipboard
wildfly
WFLY-13530 Expose JAX-RS Resources to gRPC clients
@ronsigal regarding discussions I don't know if maybe something on the wildfly-dev list would be a good starting point.
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.
Hey @darranl, I really appreciate the feedback.
-
I'll put together an email for the wildfly-dev list. If you don't mind, I'll include your most recent post, which lays out a number of issues.
-
If there is sufficient interest, then there's room for a lot of features. I've focused exclusively on JAX-RS because it's what I know best, but I would be happy to contribute to a group effort.
-
When you say gRPC sounds like a good fit with CDI, are you suggesting injecting gRPC clients in the same way MicroProfile REST Clients can be injected? That is different than what I've been thinking about, but it makes sense as part of a larger discussion.
-
Concerning the separate socket and a separate subsystem, again, I just proposed what I understand. One possibility is Undertow running on Netty, when that arrives.
-
As for protobuf and gRPC, there is some discussion on https://issues.redhat.com/browse/WFLY-13530. I think there could be two separate features: 1) protobuf as a transport layer, and 2) exposing JAX-RS resources to gRPC. Originally, I thought 2 would be awkward at best, and I focused on 1 at first. I ran some tests and was able to get as much as a 15% speedup with invocations running over the internet to a WildFly server on openshift. Then, after Bilge mentioned gRPC at the F2F, I started thinking about it again. At first I tried to find a hook inside of gRPC to capture requests, but I just couldn't find anything. That's when I thought of extending gRPC classes, which is what I've proposed in the feature request.