[Discussion] An abstraction CKB client with a series of core RPC methods.

[yangby-cryptape]

Description

Now, when an app wants to connect an RPC endpoint, it has to know which kind of endpoint it connects to, a full node or a light client.

ckb-sdk-rust/src/rpc/ckb.rs

Line 22 in 3da7ffa

pub fn get_header(&self, hash: H256) -> Option<HeaderView>;

ckb-sdk-rust/src/rpc/ckb_light_client.rs

Line 103 in 3da7ffa

pub fn get_header(&self, block_hash: H256) -> Option<HeaderView>;

It makes things complicated.

An example:

enum RealClient {
    FullNode(CkbRpcClient),
    LightClient(LightClientRpcClient),
}

impl RealClient {
    fn new(url: Url, user_provided_full_node: bool) -> RealClient {
        if user_provided_full_node {
            RealClient::FullNode(CkbRpcClient::new(url))
        } else {
            RealClient::LightClient(LightClientRpcClient::new(url))
        }
    }
    /* Wrap similar RPC methods to unify into one, one by one. */
}

---

In fact, if we only use a sub-set of RPC methods, we don't have to know that such clearly.

We could split:

• CKB full node RPC methods into two parts:
  • Core CKB RPC methods
  • CKB full node only RPC methods
• CKB light client RPC methods into two parts:
  • Core CKB RPC methods
  • CKB light client only RPC methods

Then there appears an abstraction layer: a series of core CKB RPC methods.

When an app just uses these core CKB RPC methods, it could connect to either a full node or a light client, it doesn't have to know it clearly, but all of them works well.

Examples:

trait CkbCoreEndpoint {}
trait CkbFullNodeEndpoint {}
trait CkbLightClientEndpoint {}

impl CkbCoreEndpoint for CkbRpcClient {}
impl CkbFullNodeEndpoint for CkbRpcClient {}

impl CkbCoreEndpoint for LightClientRpcClient {}
impl CkbLightClientEndpoint for LightClientRpcClient {}

// Then, a core CKB client could be:
impl CkbCoreEndpoint for CkbCoreClient {}
// Or:
pub struct CkbCoreClient (Box<dyn CkbCoreEndpoint>);