Connector inheritance

[outSH]

@petermetz
We were thinking about adding another ethereum-based ledger connector, but we don't want to copy-paste or rewrite logic that remains the same between two ledgers (like deployContract, transact, etc..). This causes obvious maintenance issues with duplicated code.
Ideally, I'd like the new connector to inherit from the old one (which should work with only small adjustments), but there is possible problem with API paths. Derived connector will use both /api/v1/plugins/@hyperledger/cactus-plugin-ledger-connector-ethereum/* and /api/v1/plugins/@hyperledger/cactus-plugin-ledger-connector-ethereum-derived/* endpoints, so Derived connector will occupy two connector spaces. In other words, there can't be DerivedConnector alongside ethereum connector on a single apiServer instance. The same applies to any duplicated connector (i.e. AFAIK you can't have two fabric-connectors even if they connect to different ledgers), so I think this could be OK under condition that it would be clearly documented in Derived connector readme, but please share your opinion on this. Overwriting of endpoint paths would be more complex but possible I think.

[petermetz]

@outSH Thank you for bringing this up and sorry for the very slow response!

My simplistic view to offer to kick us off on that topic is that we can move re-usable functions to the cactus-core package and the connectors can increase their code-reuse by importing those functions instead of copy-pasting everything. I've made some progress on reducing boilerplate in REST endpoint code as well (the error handling is now mostly generic with the 4xx vs 5xx error codes working as they should).

To put this into an example for connector method implementations: We would (in the beginning at least) shy away from using the actual class inheritance features of the language and instead focus on composable code snippets in the form of standalone, pure-ish (as pure as possible) functions.

core package: src/main/typescript/evm/deploy-evm-contract.ts

export interface IDeployEvmContractContext<T> {
  readonly req: T;
  readonly log: ILogger;
  // plus any other parameters that we need like
  // web3 connection object that's ready to go
}

// encapsulates the response from the contract deployment
// and allows to have additional parameters 
export interface IDeployEvmContractResponse<T> {
  readonly res: T;
  readonly someOtherReturnInformationThatImSureWeWillNeed: string;
}

export async function deployEvmContract(ctx: IDeployEvmContractContext<T> ): Promise<IDeployEvmContractResponse<T>> {
  const { log, req } = ctx;
  log.debug("Deploying EVM contract to ...");
  // rest of the implementation 
}

PluginLedgerConnectorX/Y/Z

import { deployEvmContract } from "...";

class PluginLedgerConnectorX/Y/Z {

 public async deployContractJsonObject(
    req: DeployContractV1Request,
  ): Promise<DeployContractV1Response> {
     const ctx: IDeployEvmContractContext<SomeResponseTypeToBeDefined> = { req, log: this.log };
     const out = await deployEvmContract(ctx);
     return out;
  }
}

I'm not a 100% confident in the exact details regarding the generic types yet, but this is the general direction I'd want to go instead of actual inheritance like this below:

class PluginLedgerConnectorGenericEvm {
   public async deployEvmContract();
}

class PluginLedgerConnectorX/Y/Z extends PluginLedgerConnectorGenericEvm {
}