Hi, everyone. thanks for your discuss. I want to talk the 5 point.
The shenyu-client-grpc module has already provided the json grpc service that wrap the origin grpc service. If the request message and response message of the json service can be dynamically constructed in the shenyu-plugin-grpc module, we may be able to call the server. Currently, I haven't implemented this method yet, I don't know if it is feasible.What about other people's views? 在 2021-05-25 16:19:59，"XiaoYu" <[email protected]> 写道： >Hi > >Ok , I probably understand what you mean, so I agree with 4, what about >other people's opinions? > >zhangleispring <[email protected]> 于2021年5月25日周二 下午4:04写道： > >> Because of the message in the protocol buffer is a series of key-value >> pairs. >> The binary version of message just uses the field number (field's number >> and wire_type) as the key. >> The name and declaration type of each field can only be determined by >> referencing the definition of the message type (proto file) on the decoding >> side >> So it is very difficult to deserialize and deserialize based on metadata >> >> >> >> >> 在 2021年5月25日 15:20，XiaoYu<[email protected]> 写道： >> >> >> Hi , zhangleispring & wei liu 4. The client side reports the grpc service >> metadata to the registry center. Is this solution not feasible and what is >> the difficulty of it? thanks, wei liu <[email protected]> >> 于2021年5月25日周二 下午2:49写道： > 3. Upload the proto file in the background or >> store it in the form of > metadata, and parse the proto generation method >> descriptor. > > > - > > It seems like a good idea > > > zhangleispring < >> [email protected]> 于2021年5月25日周二 下午2:28写道： > > > I've researched >> apisix and enovy,They all upload proto files in the > > gateway or generate >> them through scripts. > > I think this is a feasible way > > > > > > > > > >> > > > > > 在 2021年5月25日 12:57，midnight<[email protected]> 写道： > > > > > > >> Hello everyone. There are still some problems with the way the > > >> shneyu-gateway connects to grpc. The shneyu-plugin-grpc and > > >> shneyu-client-grpc modules need to dependency on the shneyu-common > >> module. > > Is there any better way to implement grpc service access? The >> methods > > collected are: 1. Obtain the descriptor by reflect, and then >> call the > > service, but there is one more rpc call. 2. Simulate the grpc >> protocol, > but > > it is more difficult, and the generated class is too >> complicated. 3. > Upload > > the proto file in the background or store it >> in the form of metadata, and > > parse the proto generation method >> descriptor. 4. The client side reports > > the grpc service metadata to the >> registry center. 5. Define the same > proto > > file on the plugin and the >> client side, and the client side exposes the > > service by the proto file. >> Welcome everyone to discuss the above methods, > > or express your point, >> in a better way to access gprc service in the > > gateway. >
