Add gRPC endpoints for querying txs, TxsByEvents, tx/broadcast

[anilcse]

• Currently there are only legacy REST endpoints for querying TxsByEvents and for querying TxByHash. Having gRPC methods/endpoints would be handy for applications that uses gRPC alone.

cc @aaronc @amaurymartiny @alexanderbez

[aaronc]

It seems like clients could use tendermint JSON RPC directly without needing gRPC, and that gRPC would just be a very thin wrapper over tendermint. What benefits would this bring?

/cc @marbar3778

[alexanderbez]

The idea I think is that it's one less service to have to interface with if the client doesn't actually need Tendermint's JSON RPC.

[aaronc]

Yeah that's reasonable. We should also wrap broadcast (and maybe some other tendermint methods) if we do this.

[aaronc]

Yeah that's reasonable. We should also wrap broadcast (and maybe some other tendermint methods) if we do this.

[anilcse]

The idea I think is that it's one less service to have to interface with if the client doesn't actually need Tendermint's JSON RPC.

Correct @alexanderbez , and the less services to interface for clients, the better UX.

Yeah that's reasonable. We should also wrap broadcast (and maybe some other tendermint methods) if we do this.

+1

[sahith-narahari]

@anilcse @clevinson this should be addressed for 0.40 right, or is there a change of plan I missed

[amaury1093]

In reading Tendermint's v1.0 roadmap, I saw they were evaluating using gRPC instead of their own RPC layer. If that happens, I guess this issue is not relevant anymore?

The 2 gRPC servers will be on 2 different ports, if clients want everything on one single port, maybe there's a workaround to combine them under one port?

[anilcse]

We can address this after 0.40 as well, not a blocker. @amaurymartiny as this would be a small rework even after updating the TM side changes, I suggest to address this now. Wdyt?

[aaronc]

In reading Tendermint's v1.0 roadmap, I saw they were evaluating using gRPC instead of their own RPC layer. If that happens, I guess this issue is not relevant anymore?

Exactly.

But it's small enough (hopefully) that it's not a problem to add it in the meantime.

Not a blocker for 0.40.

[aaronc]

I suggest we backport at least tx by hash to Stargate. It shouldn't be that hard

[clevinson]

@amaurymartiny's PR currently only covers GetTxByHash, we should decide if the following other endpoints are priority for stargate:

• broadcast Tx REST endpoint (currently proto Tx's are only able to be received by tendermint RPC endpoints)
• TxByEvents REST endpoint

Thoughts @aaronc @anilcse ?

[aaronc]

TxByEvents is higher priority IMHO. Broadcast I'm not sure we should even offer that actually, it should take TxRaw if so.

[aaronc]

Maybe broadcast is useful to just use a single set of generated types...

[anilcse]

@amaurymartiny's PR currently only covers GetTxByHash, we should decide if the following other endpoints are priority for stargate:

• broadcast Tx REST endpoint (currently proto Tx's are only able to be received by tendermint RPC endpoints)
• TxByEvents REST endpoint

Thoughts @aaronc @anilcse ?

I suggest to include both if it's not too much involved for broadcast. TxByEvents is a priority anyway, better to address it in the same PR

[clevinson]

The only argument that I can see for broadcast, is for some users who still want to have a future supported REST endpoint for broadcasting transactions in Stargate. Unless tendermint RPC is basically REST over a specific port (sorry for not knowing this...)?

[aaronc]

Tendermint is not gRPC protocol (yet). Adding this stuff to gRPC allows clients to talk to a single endpoint (eventually).

[alexanderbez]

#7355 (comment)

Having the ability for clients to broadcast and query from a single gRPC/gateway endpoint would be ideal.