subsquid/squid-stitching

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