search

spring-projects / spring-framework

Spring Framework
https://spring.io/projects/spring-framework
Apache License 2.0
56.45k stars 38.08k forks source link

Provide gRPC support [SPR-16358] #20905

Closed spring-projects-issues closed 1 year ago

spring-projects-issues commented 6 years ago

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:

7 votes, 18 watchers

spring-projects-issues commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 - https://github.com/LogNet/grpc-spring-boot-starter/issues/65
  2. Support Spring Security @Secured annotation - https://github.com/LogNet/grpc-spring-boot-starter/issues/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 commented 6 years ago

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:

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 commented 5 years ago

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: https://github.com/spring-cloud/spring-cloud-sleuth/pull/1139#issuecomment-444302714

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

trustin commented 4 years ago

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

I'm one of the maintainers of Armeria project.

mattdkerr commented 4 years ago

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 commented 1 year ago

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.