Similarityoung opened a new issue, #821: URL: https://github.com/apache/dubbo-go-pixiu/issues/821
### ⚠️ Verification - [x] I have searched the [issues](https://github.com/apache/dubbo-go-pixiu/issues) of this repository and believe that this is not a duplicate. - [x] I have searched the [release notes](https://github.com/apache/dubbo-go-pixiu/releases) of this repository and believe that this is not a duplicate. ### 🎯 Solution Description Currently, the gRPC forwarding logic within the gateway relies on grpc.ForceCodec combined with a custom ptcodec (pass-through codec). This approach treats the request body as an opaque binary data stream and forwards it directly. The current core implementation looks like this: ``` clientStream, err := conn.NewStream(outCtx, &grpc.StreamDesc{ StreamName: ctx.MethodName, ServerStreams: true, ClientStreams: true, }, fullMethod, grpc.ForceCodec(ptcodec.Codec{})) ``` ### Current Problems While the pass-through mode offers high performance, it has several limitations: Limited Extensibility: The gateway cannot perceive or inspect the specific content of the payload. This makes it difficult to implement content-based routing, field filtering, or validation. Poor Observability: Specific business request fields cannot be parsed or logged at the gateway layer, making debugging and auditing difficult. Protocol Conversion Constraints: It is difficult to support heterogeneous protocol conversion (e.g., HTTP/JSON to gRPC) dynamically because the current implementation relies heavily on raw binary pass-through. ### Goals To achieve flexible Generic Invocation and improve the extensibility of the gateway, we plan to introduce gRPC Server Reflection. Specific goals include: Leverage gRPC Server Reflection to retrieve MethodDescriptor and MessageDescriptor from downstream services. Remove the hardcoded grpc.ForceCodec(ptcodec.Codec{}) implementation. Implement dynamic message construction and invocation based on reflection, granting the gateway the ability to parse and manipulate message bodies. Implementation Plan / Expected Changes Introduce a gRPC Reflection client (investigate jhump/protoreflect or the official gRPC reflection library or other). Dynamically resolve the input and output types corresponding to the fullMethod during the connection or request phase. Refactor the conn.NewStream logic to support dynamically generated StreamDesc or utilize generic invocation interfaces provided by the reflection library. ### 📋 Use Cases grpc to grpc ### ⚖️ Complexity & Risks _No response_ ### 🔗 External Dependencies _No response_ ### 📘 Additional Context _No response_ -- 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]
