New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide gRPC support [SPR-16358] #20905

Open
spring-issuemaster opened this Issue Jan 8, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Jan 8, 2018

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:

  • #21292 RSocket client and server support
  • #20331 Support Protobuf serialization in WebFlux
  • #21011 Add Thrift RPC support to WebFlux

7 votes, 18 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 8, 2018

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 8, 2018

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 9, 2018

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 9, 2018

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 - LogNet/grpc-spring-boot-starter#65
  2. Support Spring Security @Secured annotation - 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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Apr 20, 2018

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

This comment has been minimized.

Copy link

ST-DDT commented Feb 16, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment