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