jinrongluo commented on issue #417: URL: https://github.com/apache/incubator-eventmesh/issues/417#issuecomment-954082688
I am very interested in this topic about Integrating grpc/reactive-grpc as transport framework in EventMesh Runtime. I would like to contribute as well. I am studying the following materials - grpc https://grpc.io/docs/languages/java/quickstart/ https://github.com/grpc/grpc-java - reactive-grpc https://github.com/salesforce/reactive-grpc One thing I would like to bring up when doing this integration: EventMesh runtime is already having two kinds of transport framework: HTTP and TCP. They are both implemented using Java Netty. gRPC is NOT compatible with Java Netty. This means the following design choices needs to consider: Option 1. Introduce gRPC as a third transport framework. Keep existing HTTP and TCP Netty code in Runtime side and SDK side Option 2. Replace exiting TCP with gRPC. This means a MAJOR code refactor in Runtime and SDK modules. Existing Netty Server and client code will be removed and replaced with gRPC related codes. Option 3. Replace BOTH existing HTTP and TCP Netty framework with gRPC. This means a MAJOR code refactor in Runtime and SDK modules. Existing Netty Server and client code will be removed and replaced with gRPC related codes. In my opinion, Option 3 provide more benefits over Option 1: - gRPC offers streaming and async APIs which can effectively satisfies the needs of existing Eventmesh TCP and HTTP Pub/Sub APIs. This claim needs to be verified by Prototyping and Proof Of Concept - gRPC offers multiple languages SDK generator, which can benefit Eventmesh community for having multi-language SDKs - Having single gRPC transport has much less code maintenance overhead in the long run. Option 1 and Option 2 still maintenance multiple transport codes, and It can be confusing to end user for not knowing which to choose, HTTP or TCP or gRPC? To end user, as long as they can perform Pub/Sub, the transport protocol does not matter. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
