[rpc] module concerns

[liamsi]

Motivation

As we are introducing an rpc service (aka light-node #219), now is a good time to look at different options regarding the rpc client (and soon server) lib.

The current approach seems to be to write all types and logic from scratch.

This has the major benefit that we don't introduce any dependencies, and, that we can manually guarantee compatibility with the go implementation (which might not always adhere to standards, e.g. see: https://github.com/tendermint/tendermint/issues/2949).

The major drawback here is that we need to implement details that are not directly tied to tendermint core types or business logic. e.g., we need to make the jsonrpc wrapper type is properly tested (#298), or that we care about control messages in the web-socket implementation (https://github.com/informalsystems/tendermint-rs/issues/311).

Actionable Items

Reconsider using a library for most of the rpc server (and partly client) logic.

For that a brief writeup (adr) on pros and cons on libraries leaving a documentation trace why a particular choice was made would be ideal.

Currently paritiy's crates look most promising here:

• https://github.com/paritytech/jsonrpc/tree/master/core
• https://github.com/paritytech/jsonrpc/tree/master/core-client
• more: https://github.com/paritytech/jsonrpc#sub-projects

But they might soon be replaced by an asny/awaitified variant: https://github.com/paritytech/jsonrpsee

Also, consider making the rpc module a separate crate, see: https://github.com/informalsystems/tendermint-rs/issues/7#issuecomment-645487039

Drawbacks

• might introduce yet another dependency (always comes with hidden costs, e.g. see: https://github.com/informalsystems/tendermint-rs/issues/289 and https://github.com/crypto-com/chain/issues/1675#issuecomment-636871417)
• ecosystem is still moving fast (especially everything around runtimes / async/await etc)
• the rpc (encoding and lib) are under reconstruction in tendermint go (see: https://github.com/tendermint/tendermint/pull/4857)

related

• tendermint go rpc issue: https://github.com/tendermint/tendermint/issues/3367

• adr regarding rpc in tendermint go: https://github.com/tendermint/tendermint/pull/4857

• subscript / event listener issue: https://github.com/informalsystems/tendermint-rs/issues/313

• async/await and rpc: https://github.com/informalsystems/tendermint-rs/issues/318

• light node: #219

• crate dependency hell: https://github.com/informalsystems/tendermint-rs/issues/289 and related: https://github.com/informalsystems/tendermint-rs/issues/7; also over at crypto.com: at: https://github.com/crypto-com/chain/issues/1675#issuecomment-636871417

[brapse]

Just to relay the conclusion from out of band conversations, I think this makes sense. Going with jsonrpc to provide consistent documentation is a win. Let's continue to be mindful of dependencies and the complexities that come with them. 🙏

[liamsi]

referencing this: https://github.com/informalsystems/tendermint-rs/issues/289#issuecomment-645867633 (@xla)

[...] introduce fine-grained feature flags in the rpc crate which on-demand enable the client, event_listener and such.

Makes most sense to me.

[ebuchman]

Given all the recent work with the rpc crate, is this issue still relevant? cc @thanethomson