Skip to content
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

Integrate GRPC #2626

Open
zhongyang0316 opened this issue Nov 12, 2018 · 20 comments
Open

Integrate GRPC #2626

zhongyang0316 opened this issue Nov 12, 2018 · 20 comments
Assignees
Labels
status: waiting-for-triage The issue need to be evaluated and its future decided type: enhancement

Comments

@zhongyang0316
Copy link

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

@artembilan
Copy link
Member

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 artembilan added type: enhancement status: waiting-for-triage The issue need to be evaluated and its future decided labels Sep 20, 2019
@artembilan
Copy link
Member

@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

@artembilan artembilan reopened this Sep 20, 2019
@zhongyang0316
Copy link
Author

@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
Copy link
Member

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
Copy link

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
Copy link
Member

@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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link

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
Copy link
Member

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
Copy link

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?

@fengli79
Copy link

Glad to see that the Spring community is interested in getting gRPC support.
A few things we may need to consider:

  • gRPC use proto as idl, and it relies on codegen. I saw spring-boot explicitly rule out the codegen based solution, but I wonder it can be open to disucss/change.
  • The request/response needs protobuf, it would need codegen anyway. No matter how we may the gRPC service/method with spring.
  • gRPC java is majorly on Netty, but there are other network libraries it support, we need to handle the port sharing with other channel/protocols as well. For example, between http/rest and grpc.

@fengli79
Copy link

@tzolov I see you were assigned to this topic, is there any plan in your mind? I'm happy to help as well.

@artembilan
Copy link
Member

@fengli79 ,

Thank you for proposing the help!

As you see we already have a Protobuf support in Spring Integration: https://docs.spring.io/spring-integration/docs/current/reference/html/message-transformation.html#Protobuf-transformers.

For channel adapters (gateways) we can borrow some ideas from Spring Cloud Function project: https://github.com/spring-cloud/spring-cloud-function/tree/main/spring-cloud-function-adapters/spring-cloud-function-grpc

Feel free to contribute whatever you can: https://github.com/spring-projects/spring-integration/blob/main/CONTRIBUTING.adoc !

@fengli79
Copy link

Thanks @artembilan. I'm exploring some ideas and prototyping, will get back soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage The issue need to be evaluated and its future decided type: enhancement
Projects
None yet
Development

No branches or pull requests

7 participants