Thinking about #7 more, and my general unhappiness with the verbosity of the node.Client interface, it might make more sense to remove all the RPC-specific methods from that interface, and instead offer them as some sort of request builder and response parser pair.
Though not sure where said builders would live (e.g. what the actual name of pkg would be).
This pattern is used in a couple places to varying effectiveness, namely go-redis and the golang AWS SDK v2. Anyways, just a rough idea for now, but the main advantage is that it separates the definition of new RPCs from node.Client, which just needs to implement .Request and .Subscribe which makes implementing new virtual clients and or mocks much cleaner.
This would also make supporting batch requests doable, as the Client would just need to implement an additional .BatchRequest method, and the []jsonrpc.Request could be built using the builder.
Thinking about #7 more, and my general unhappiness with the verbosity of the
node.Client
interface, it might make more sense to remove all the RPC-specific methods from that interface, and instead offer them as some sort of request builder and response parser pair.So instead of:
One would instead use:
Though not sure where said builders would live (e.g. what the actual name of
pkg
would be).This pattern is used in a couple places to varying effectiveness, namely go-redis and the golang AWS SDK v2. Anyways, just a rough idea for now, but the main advantage is that it separates the definition of new RPCs from
node.Client
, which just needs to implement.Request
and.Subscribe
which makes implementing new virtual clients and or mocks much cleaner.