Hi eyeryone. Thank you for your active discussion. The final way to achieve this is to expose JSON wrap services at the shenyu-client-grpc module,
dynamically generate the method descriptors on the shenyu-plugin-grpc side, and then invoke the grpc service. The final code has been merged. Here is PR(https://github.com/dromara/shenyu/pull/1556). At 2021-05-26 12:41:22, "midnight" <[email protected]> wrote: Okay, I will continue to try, please give me some more time. Thanks again for giving me this opportunity. 在 2021-05-26 10:28:45，"XiaoYu" <[email protected]> 写道： >Hi midnight > >I am very sorry, my previous reply was wrong, I meant to support 5 . > >Just do it .. go on. > >midnight <[email protected]> 于2021年5月25日周二 下午9:43写道： > >> 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. > >>
