deprecate grpc

[ebuchman]

Sorry fam, the pain is too great. I have yet to have a good experience with this tech, only pain.

We'll find some way to do #208

I'm also getting a bit worried about protobuf. What if a language doesn't have a protobuf implementation, or it does but it sucks?

Still planning to have grpc broadcast_Tx for 0.8, but support will probably be dropped for all grpc by 0.9.

Feel free to voice concern here.

[mdyring]

What are the pain points? Works well on C++ but I have not tested other languages.

Support seems very broad. From www.grpc.io: C++, Java, Go, Python, Ruby, C#, Node.js, Android Java, Objective-C and PHP.

Pros:

• You get all of the above languages for free, whereas a TMSP implemention needs to be build from scratch for all but the 3 first on the list - and maintained by 3rd parties in the future.
• Seems more extensible than a home-brewed socket protocol. Upgrade path built into protocol.
• Async RPC built-in. This is useful for BroadcastTx and will add some additional complexity if implemented in TMSP.

Cons:

• Possibly slower than TMSP protocol (but this depends on the implementation). This doesn't concern me that much, since a) I haven't seen any catastrophic performance figures yet and b) bottleneck will likely be elsewhere in stack.
• Adds dependency that must be pulled in, but this is not more troublesome than pulling in a TMSP lib.
• Need to maintain TMSP, HTTP and gRPC seems cumbersome.

IMO, protocols in order of importance: gRPC, TMSP and finally HTTP.. So I'd hate to lose gRPC.

[tomtruitt]

We are built for broadcastTX over grpc so it kinda pulls the ground out from under the work we've done (by we I mean not me)

[ebuchman]

Ok, thanks guys. I got a little emotional. I'll leave this open to gather more feedback and help track who is using it but will not move to drop support. Thanks.

[mdyring]

Group hug?

[ebuchman]

D'awww totally!

[mdyring]

[tomtruitt]

Yeah man we know it's been a pain in the ass and we really appreciate how much time and effort to poc has been saved on our end because of it. Maybe you could keep support until an answer to 208 is clear?

[tomtruitt]

😂😂😂

[silasdavis]

@ebuchman very interested in your specific issues with gRPC

[ebuchman]

copying my response from slack:

"yeh. i mean when i consider what its actually providing its kind of amazing that it just works. but its the little things I have to deal with that make it a pain - especially since right now its acting only to give app devs an easier time, not the real focus. so we offer it for tmsp, but it doesnt really make sense because tmsp is mostly async and grpc is sync, or else requires lots more work to shoehorn into its streaming model. we also have an rpc system thats been pretty good to us, and are only trying to offer broadcast_tx via grpc so the only network related lib an app dev needs is grpc, but for anything more sophisticated or higher performance, it would use the main tendermint rpcs and async tmsp anyways. so it just feels like disproportion amount of maintenance work for little gain- its always updating, breaking builds; it makes assumptions about the code that don't necessarily fit or that cause subtle issues; and it requires us to maintain redundant endpoints and tests. so its helpful to hear that people think its so valuable, since its kind of a pain to maintain"

[ebuchman]

one of the things that set me off yesterday was omitempty on json structs. In Go, omitempty can be a nuisance because it will omit zero values, so a struct full of default values will just look empty - ie. rather than receiving {"code": 0, "data": nil, "log": ""} for the tmsp result type, we get {}, which isn't nearly as nice. The omitempty is hardcoded into the grpc code for Go, so there's no way to change it without making a PR to them to have it optional, or adding extra maintenance work to strip it from the generated code after the fact. See grpc/grpc-go#481 . Apparently theres a specific-to-protobuf json encoder, but that doesn't help us since we have our own requirements (eg. we serialize byte arrays as hex rather than base64). Gah!

This came up here: https://github.com/tendermint/tendermint/blob/develop/test/app/grpc_client.go#L35

[ebuchman]

We're cool for now grpc