GRPC and inprocess channels

[ghost]

I think you were having issues with GRPC between golang and Dart and the fact that the Datr code demanded a http endpoint ? I might be wrong ... ?

I just tested this: https://github.com/fullstorydev/grpchan & https://github.com/jhump/goprotoc

Its a way to model using GRPC but run the two endpoints in process, and so no need a port based endpoint.

It might help you too. Let me know what you think :)

[empirefox]

Thanks @gedw99 Sorry I am late again. I am busy on a trip these days. And yes, any help is welcomed. It is a fake port to dial from dart to go. And i think grpchan may not compatible with grpc-dart. And it should works with goprotoc if goprotoc compatible with google official implements.

[empirefox]

The port can be designed replacing with a string id, but in the beginning i just wanted that it look likes system listening and dialing.

[ghost]

No need to apologise.

I agreed. It will not be compatible with grpc-dart.

My intention in suggesting it was a not properly explained by me.

Given the issues on mobile with interoperability between golang and dart using grpc, why not use gomobile embedded within flutter but have the connection between flutter and gomobile use a simple Jsonrpc call structure ?

But also on top of that change of thinking , also this would mean we can use stable grpc golang code between the server and the client. This allows pure grpc golang on both sides. It makes all the corner cases of dart and golang grpc disappear. I had many issues with dart and golang grpc interoperability in terms of maintaining a stable connection when using it in real world testing. There are lots of tricky corner cases.

Even the i18n and l10n logic can be in gomobile whilst still using the standard flutter API for flutter widgets.

Assuming my assertions above are decent this would make the whole system thoroughly more robust and easier to innovate with.

So why raise the use of grpc channels where no network port is used ? To allow the ability to take a group of grpc services that would normally be running on network ports on your servers and "reconfigure" then at Design / compile time to run inside gomobile on a mobile.

So by commiting to the gomobile layer only using grpc golang you gain all these other abilities.

Lastly, one thing we loose by not using grpc dart is the code generation and string typing of grpc. But I think we can use the protobuf at the gomobile layer to code generate the dart code to give the strong typing needed. For example flutter has streaming channel plugins now. We would scaffold all the code for that.

The down sides are:

• slower because your going through the java and swift layers on a mobile But where it's slower is not where the performance bottleneck is. So it's a worthy trade off.

• messier. Yes a bit in that it's not just dart to golang grpc. But I also think it's cleaner in the long run because you have a nice seperation of concerns. Flutter is only worry about GUI and no doing any networking. Golang is doing all the networking. They are both doing what they are good at.

Food for thought....

[empirefox]

Thank you for your analysis. I haven't thought deeply about it yet. My initial idea was to quickly integrate the existing server side code directly into the flutter, eg hybrid. And it is intended to work together with protoc-gen-dart-ext. But I really don't have time to make it more general.

[ghost]

No worries.

Can look into generalising later. Will be interesting to try out your code once it's usable. I stopped playing with it for now as too much is still changing.

If you get it stable please ping me. Have some other ideas