Skip to content
This repository has been archived by the owner on May 23, 2024. It is now read-only.

subsquid/squid-stitching

Repository files navigation

Schema and pattern selection:

Proxy pattern (now)

All instances of the same type just has prefixes or namespaces

Pro: The easiest way

Con: All union logic should be implemented by partners (now)

Join pattern:

We have a instance from canonical source and this instances from other source with additional fields (id should be the same)

Possible schemas:

account {
    substateId
    kusamaTransfers {...}
    polkadotTransfer {...}
    kusamaStaking {...}
    polkadotStaking {...}
}

account {
    substrateId
    transfers {
        kusamaTransfers {...}
        polkadotTransfer {...}
        ...
    }
    staking {
        ...
    }

}

Pro: the supposed way to join by all tools (can be implemented in semi-auto way)

Con: we should have a canonical source type, in order parachain data can merge into it (should contain all the substrate ids of all the chains)

Union pattern:

We unite all arrays of entities of the same type

account {
    substateId
    transfers [
        {
            chain
            data
        }
    ]
}

Con: Almost manual implementation

Service selection:

Hasura:

Pros:

  • Very easy to implement
  • Hot adding and removing new schemas

Cons:

  • Only Join and Proxy patterns
  • Not very customizable

Graphql-tools:

Pros:

  • All patterns
  • Pretty customizable

Cons:

  • Need more time to implement
  • No hot reload (?)

Deploy selection:

Should we unite all services under one compose file or not

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published