ruanwenjun commented on issue #417:
URL: 
https://github.com/apache/incubator-eventmesh/issues/417#issuecomment-954358967


   > 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.
   
   +1, using grpc can make the code clean. It's benefit to maintenance and easy 
to implement other language sdk.


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

Reply via email to