Provide gRPC support [SPR-16358]

[spring-projects-issues]

Ashok opened SPR-16358 and commented

gRPC is becoming defacto standard for service to service communication, due to its ubiquitous nature & use of HTTP2

Currently we have grpc-java which generates its own version of classes that handle request in their own proprietary way when compared to Spring MVC & Spring WebFlux.

Plus, modern service mesh frameworks like https://envoyproxy.io works very nicely with gRPC.

Developers in spring world requires this high performance, type safe service-service integration (tho we have integration with hystrix, gRPC is much more performant & support wide variety of languages).

Here are some pain points in using grpc-java in spring world

1. Since gRPC makes no assumption about Spring web framework, its request handling has a completely different path outside of WebFlux/MVC
2. Integrating that code with spring ecosystem like Security will be completely adhoc & fragile

If spring can scaffold a WebFlux/MVC project from grpc service definition, it will improve the development experience & at the sametime developers like me can enjoy the benefits of gRPC

---

Issue Links:

• RSocket client and server support [SPR-16751] #21292 RSocket client and server support
• Support Protobuf serialization in WebFlux [SPR-15776] #20331 Support Protobuf serialization in WebFlux
• Add Thrift RPC support to WebFlux [SPR-16466] #21011 Add Thrift RPC support to WebFlux

7 votes, 18 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks for starting this discussion.

To me Spring MVC and WebFlux are web frameworks where the programming model is explicitly and intentionally based on HTTP. By contrast gRPC is a remote invocation, messaging framework where HTTP/2 is only a transport and does not impact the programming model. I see those as alternatives so I'm unsure what you're actually asking. For example if we scaffold a Spring MVC and WebFlux application, wouldn't that mean not using gRPC infrastructure at runtime (aside from @RequestBody and @ResponseBody based on protobuf data types)?

[spring-projects-issues]

Ashok commented

Thanks for your quick response.

To be honest, I have not done the complete deep dive into the spec & implementation details of gRPC.

My assumption was that it streams the requests & responses over HTTP2 within single connection, with both request & response body being encoded in protobuf, Which is what you explained :)

Since I am not that knowledgeable in the overall protocol, I looked up this document that details how they use frames within http to send & receive data over single connection.

https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md

Frankly I dint understand most of the document :)

Here is an interesting FAQ that found on their website

Why is gRPC better/worse than REST?
gRPC largely follows HTTP semantics over HTTP/2 but we explicitly allow for full-duplex streaming. We diverge from typical REST conventions as we use static paths for performance reasons during call dispatch as parsing call parameters from paths, query parameters and payload body adds latency and complexity. We have also formalized a set of errors that we believe are more directly applicable to API use cases than the HTTP status codes.

My assumption is that they are doing some preprocessing on the client/on the server (or) hardcoding urls within code generation itself for path parameters, not sure which

Since you might have better context on the internal implementation of Spring WebFlux, would appreciate if you can help us understand if

1. Integration is possible with code generation on Spring end to match the expectation of gRPC (or)
2. Integration is possible with adapters that convert between grpc & webflux (or)
3. Integration feasible with rest of Spring eco system (I've seen spring security integration with gRPC https://eng.revinate.com/2017/11/07/grpc-spring-security.html) but not with webflux (or)
4. Integration not possible due to limitations

Thanks again

[spring-projects-issues]

Brian Clozel commented

If you'd like to use gRPC, the Spring Boot community is already maintaining a dedicated gRPC Spring Boot starter for that.

[spring-projects-issues]

Ashok commented

@Brian

Thanks for point it out. I am already aware of the community maintained repo, but the repo is more of a work around.

The community maintained repo has all the problems I listed in the original problem statement.

For eg.,

1. Using Spring 5 webflux with GRPC uses 2 different ports - Using Spring 5 webflux with GRPC uses 2 different ports LogNet/grpc-spring-boot-starter#65
2. Support Spring Security @Secured annotation - Using Spring 5 webflux with GRPC uses 2 different ports LogNet/grpc-spring-boot-starter#65, which requires workarounds like this https://eng.revinate.com/2017/11/07/grpc-spring-security.html
3. Does not support complex validation of inputs such as using bean validation (may be gRPC itself does not have support for this natively)

These piecemeal solutions is what necessitated me opening this issue, so that we can start the discussion around identifying & probably finding a solution that's more well throughout

[spring-projects-issues]

Rossen Stoyanchev commented

The Salesforce reactive-grpc project provides reactive library adapters including one for Reactor so you can use Flux and Mono and underneath they're adapted to gRPC with flow control. For more on why this matters, see the rational from the proposal to support Reactive Streams in grpc-core/C++ but thanks to Reactor and reactive-grpc, those benefits are already available for Java applications, and the resulting programming model is well aligned with the WebFlux programming model.

About gRPC and WebFlux:

• gRPC-Java runs on Netty with HTTP/2, and it exposes an RPC/messaging API on top.
• WebFlux can run on Netty too via Reactor Netty, and it exposes an HTTP API.

So both run on the same server, but the have different runtime layers, and expose different programming models on top. We could change WebFlux to support the gRPC protocol, but that would replace the gRPC-Java runtime layer, and I suspect that's not what most gRPC users would expect or want.

A simpler goal is to bootstrap gRPC-Java and WebFlux on the same Netty server, and appears that's possible on separate ports but currently is not possible on the same port grpc-java#3458.

I think between gRPC-Java, the reactive-grpc adapters, and the grpc-spring-boot-starter, there are enough pieces out there at the moment. I don't think validation alone is enough to justify dedicated support, and for security I recommend creating a ticket under Spring Security. I'll leave this ticket open in the backlog but I don't see much to do at this time.

In the mean time note that we're also exploring support for RSocket with #21292.

 

[ST-DDT]

There might be a good starting point for a spring(-boot) grpc library: yidongnan/grpc-spring-boot-starter. There have been discussions to become a spring library already.

See also: spring-cloud/spring-cloud-sleuth#1139 (comment)

Disclosure: I'm one of the core maintainers of yidongnan/grpc-spring-boot-starter.

[trustin]

You can also use Armeria's Spring Boot integration: https://armeria.dev/docs/advanced-spring-webflux-integration The integration looks like this:

• Armeria runs a Netty-based HTTP/2 server
• gRPC services and clients runs on top of Armeria
• Thrift services and clients run on top of Armeria
• WebFlux (or Spring MVC) runs on top of Armeria
  • reactor-netty is replaced with Armeria

I'm one of the maintainers of Armeria project.

[mattdkerr]

There might be a good starting point for a spring(-boot) grpc library: yidongnan/grpc-spring-boot-starter. There have been discussions to become a spring library already.

See also: spring-cloud/spring-cloud-sleuth#1139 (comment)

Disclosure: I'm one of the core maintainers of yidongnan/grpc-spring-boot-starter.

I've been using this one for a project at EA and have had good success with it. It would be great to have more developers contributing, as I haven't had as much time as I would have liked to do so myself. (I've updated it to Gradle 6 line to support newer protobuf-gradle plugin so far.)

[bclozel]

As we can see in the comments above, there are numerous existing Spring integrations for gRPC. Such integrations don't need to live within the web framework layer, but rather connect at the level of the HTTP layer. If a more in-depth Spring integration is needed, with a messaging style RPC stack on top of HTTP/2 or other transports, I think RSocket is the de factor answer in Spring.

I'm declining this issue as a result.