Using parachain SDKs

[tad3j]

I've been evaluating this SDK (as a replacement of Polkadot SDK) to use on Apillon project and I like the benefits this SDK brings but I've noticed that it isn't compatible with most of the parachain SDKs, mostly due to the fact that all SDKs rely on Polkadot SDK (either they use it under the hood or require ApiPromise to be injected).

Here is an example of using Phala SDK and concrete issue where variable api has invalid type (DedotClient) passed to Phalas OnChainRegistry:

import { DedotClient, LegacyClient, WsProvider } from 'dedot';
import {  OnChainRegistry} from '@phala/sdk';

const api = await DedotClient.new(new WsProvider(this.rpcEndpoint));

const registry = await OnChainRegistry.create(api, {
        strategy: periodicityChecker(),
      });

Most if not all SDKs all suffer from tight Polkadot SDK coupling with them that's why I wanted to open an issue to see what are other people thoughts on this issue. I know solution is not trivial since each of SDKs would have to support this SDK or at least use compatible interface. I'm afraid this issue will prevent adoption of this SDK since it's only compatible with generic substrate side but not with specialized parachain side.

Is it reasonable to expect that parachains will ever be compatible with different API clients?

[sinzii]

Hey @tad3j, thank you for opening this issue and putting your thoughts here.

I’ve been thinking about this more and more recently, while we definitely can have some kind of adapter to make Dedot to be compatible with ApiPromise, e.g:

const client = await DedotClient.new(new WsProvider(this.rpcEndpoint));
const api = new ApiPromiseAdapter(client);

const registry = await OnChainRegistry.create(api, { ... });

This is definitely doable, but it might take a while to implement it correctly. On the other hand, I see a few things that might hinder us to bringing a better DX to the ecosystem:

1. Parachain teams would less likely to have any reason to move their sdk to other clients that have better support for Types & APIs for individual/specific chains, since they can still using the compat adapter. This creates a high barrier for new devs to on-board to the ecosystem.
2. Dedot is built with optimization for smaller bundle size and less memory consumption compared to @polkadot/api, if we were to have this adapter, this would probably defeat this optimization and might resulting in a higher bundle size for dapps overall if they're using this adapter.

Instead, I think teams should consider gradually migrating to new libraries like Dedot to harness & fully benefit from the advantages and features that the new tools bringing to the table. One of the concious decisions that we made for Dedot is for it to have a similar API-styling with @polkadot/api, so teams can have an easier time getting started with Dedot and migrating to it easier and faster. To demonstrate this, I was trying to quickly migrate the OnChainRegistry of @phala/sdk from @polkadot/api to dedot, as you can see from the commit, most of what we did was to delete the code to fix the type system issue since dedot is using native Typescript type-system.

For team like Apillon, where you guys are using sdks from other parachain teams. I think, a reasonable approach now might be to migrate part of your code base from @polkadot/api to dedot to analyze & verify the impact first and then gradually migrate other parts that using sdks from other teams later when they're catching up with new tools.

I really appreciate it that you bring this up for discussion, let me know if you have any other thoughts.