NethermindEth
Redesign first layer of JSON RPC
The calls should extract method name then resolve an RpcRequestHandler
RpcRequestHandler should be an abstract class from which a specific, e.g. EthBlockNumber should inherit. (we have done similar code for Catalyst and it avoid a lot of nonsense there)
Then we should invoke the method with parameters and with the response body stream passed directly.
Each handler should support 'smart' cached responses. For example on eth_getBlockByNumber or eth_blockNumber we can easily cache the most likely responses already serialized.
Currently each JSON RPC request is being processed by a series of classes - JsonRpcProcessor, JsonRpcService and then particular modules. The way the modules like EthModule : IEthModule are implemented in Nethermind has a few disadvantages. The code for the whole module is in a single class which may lead to quite big classes handling multiple different requests. The amount of dependencies a single module may require can grow excessively as each method may require some dependencies but not others.
I have worked on a slightly better, cleaner approach for Catalyst which can be found here. It assumes that each handler is an independent class with a single responsibility of handling a specific request.
I think we did quite a lot recently around jsonrpc deserialization and some nice improvement in gaslimit project also.
Can you guys check if anything more should be done here? cc @MarekM25 @LukaszRozmej @benaadams
This proposal is to split up modules to a single class per request. I find it kind of optional, would make some things better, but might make some worse in terms of code organisation.
Won't change actual functionality
