Integrate GRPC

[zhongyang0316]

trafficstars

GRPC is very popular now and many projects need to be integrated. Is there any intention to integrate GRPC?

[artembilan]

We don't have any objection to support this. Although having our low knowledge about this subject, we would like to ask about contribution: https://github.com/spring-projects/spring-integration/blob/master/CONTRIBUTING.adoc

Otherwise we will come back to this somewhere in the future.

Thank you for the report and understanding!

[artembilan]

@zhongyang0316 ,

What made you to close the issue? The fact that we don't do anything here doesn't mean that we are against such a feature.

So, I'll reopen it for the future consideration and you are free to elaborate more what is in your mind on the matter.

Thanks for understanding

[zhongyang0316]

@artembilan Because I see spring-integration-rsocket, rsocket and grpc are very similar, so I think it will not support grpc anymore.Maybe I misunderstood it,sorry. Thank you

[artembilan]

Well, have just bumped into this article from Twitter: https://medium.com/netifi/differences-between-grpc-and-rsocket-e736c954e60

So, quoting the first paragraph:

We get asked about this all the time. In general, gRPC and RSocket attempt to solve different problems. gRPC is an RPC framework using HTTP/2. RSocket is a message passing network layer that is lower level.

Therefore we can't just replace gRPC with RSocket, especially when another side is already on gRPC. Unless why day RSocket would provide a gRPC transport, but I doubt that since there is a special Protobuf model in between. Right now there are TCP and WebSocket transport supported in RSocket.

Any other thoughts?

[tsathishkumar]

There is already some work done here, to have a spring starter for grpc. https://github.com/LogNet/grpc-spring-boot-starter

Might be good to adopt it into spring project.

[artembilan]

@tsathishkumar ,

Thank you for sharing that with us. Only the point of this issue that we really talk about Channel Adapter implementations for Spring Integration: https://spring.io/projects/spring-integration

[meltsufin]

The LogNet gRPC starter doesn't seem to be actively developed anymore. The Yidongnan gRPC Spring Boot Starter seems like a more active project. However, neither has support for Spring Integration AFAIK.

Like others have said, gRPC is an RPC framework that works over HTTP/2 with Protocol Buffers as the data exchange format. So, I'm not sure what it would mean to integrate gRPC into Spring Integration.

However, what might make sense is the use of Protobufs as a message encoding format. Luckily, Spring already has a ProtobufHttpMessageConverter, which can be used with Spring Integration.

[artembilan]

Thanks, @meltsufin , for feedback!

Does it mean that there is just enough to use existing HttpRequestExecutingMessageHandler and HttpRequestHandlingMessagingGateway with the mentioned ProtobufHttpMessageConverter to communicated over gRPC protocol?

[meltsufin]

Well, no, I don't think you'd be communicating "over gRPC protocol". You'd just be encoding the messages the same as gRPC would. It's like when you encode messages as XML, you don't actually implement SOAP. Does it make sense?

[artembilan]

Thanks. That makes sense. So, we indeed need something what really connects and sends & receives Protobuf messages over gRPC. I need to dig more then how to build server and client with gRPC...

[meltsufin]

I'm not sure what kind of gRPC support in Spring Integration would be useful. gRPC heavily relies on code-generation and compile-time binding. It's possible to do runtime introspection of a gRPC service like gRPC CLI but that will have performance implications for production apps. So, I'm curious to hear ideas from people who are asking for this support.

[artembilan]

Yeah... OK. So, there is no a generic way to interact with gRPC with some message abstraction, like we do with WebServiceTemplate in Spring WS for SOAP?

What you say reminds me an Apache CXF project (https://cxf.apache.org/) when we generate model and services according provided WSDL.

This way we really are good to use a generated gRPC service though a @ServiceActivator on the client side and call a @MessagingGateway from an endpoind on the server side.

Correct me if I'm wrong.

Thanks

[meltsufin]

I'm hardly a gRPC expert. So take my opinion with a grain of salt. :)

I think you're correct in comparing it to CXF. The gRPC CLI proves that in principle you can have a generic "GrpcTemplate" or something like that. However, it will be less efficient and against the spirit of gRPC.

@saturnism WDYT?

[saturnism]

communicating w/ a gRPC service usually end up using a generated stub, so it ends up looking like any other Java API calls. It is possible to make a gRPC call w/o the stub, and use the underlying protocol to send the payload, using something like ClientCall. All the stubs basically generate the underlying ClientCall.

[artembilan]

OK. Great! So, technically we don't need to go a generic ClientCall "hardcore", since a regular stub generation would bring us the same behavior. It is really much better to agree a contract between services during design phase and get a statically generated strict types when we develop interaction. Then from the Spring Integration perspective a common @ServiceActivator would look the same as Channel Adapter implementation over ClientCall.

So, having such a feedback it sounds like Won't Fix from this project perspective and nothing more than some doc or blog post somewhere to demonstrate gRPC from Spring Integration.

[saturnism]

That's my thought. But I wonder if @zhongyang0316 has a different use case in mind. Does the regular gRPC stubs work for the use case?