[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: tendermint/tendermint#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 (#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: #7 (comment)

Drawbacks

• might introduce yet another dependency (always comes with hidden costs, e.g. see: Feature guard the networking stuff #289 and Problem: deprecated net2 crate crypto-com/thaler#1675 (comment))
• ecosystem is still moving fast (especially everything around runtimes / async/await etc)
• the rpc (encoding and lib) are under reconstruction in tendermint go (see: ADR-057: RPC tendermint/tendermint#4857)

related

• tendermint go rpc issue: RPC Design tendermint/tendermint#3367

• adr regarding rpc in tendermint go: ADR-057: RPC tendermint/tendermint#4857

• subscript / event listener issue: Event subscription ADR and refactor event_listener module #313

• async/await and rpc: De-asyncify RPC client & requester? #318

• light node: Light Client RPC Service #219

• crate dependency hell: Feature guard the networking stuff #289 and related: Cleaner directory structure #7; also over at crypto.com: at: Problem: deprecated net2 crate crypto-com/thaler#1675 (comment)

[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: #289 (comment) (@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