refactor(experimental): graphql: revise accounts schema for data inputs

[buffalojoec]

This commit re-works the schema to deal with encoding and dataSlice directly
on the data field, rather than an account query at the top-level.

With this particular commit, the number of RPC calls to resolve a wide range of
queries is likely increased - such as multiple data fields on programAccounts.
However, the subsequent commits in this stack will seek to remedy this.

Specifically, the next commit introduces better account resolvers, which may
lessen the RPC calls for account queries by way of cache hits, but the commit
after that will introduce the revamped batch loader, which provides significant
optimizations to the number and timing of RPC calls.

Further up the stack are more changes to ensure the other queries, like
programAccounts, get to share in the benefits of similar optimizations.

Closes #1831

[buffalojoec]

Current dependencies on/for this PR:

• refactor(experimental): graphql: revise accounts schema for data inputs #2068 : 2 dependent PRs (#2069 , #2073 ) 👈
• refactor(experimental): graphql: add loadMany to loaders #2096
• refactor(experimental): graphql: add more type aliases #2095
• refactor(experimental): graphql: use runAllTimers in tests #2070
• master

This stack of pull requests is managed by Graphite.

[steveluscher]

I think this is the time to write visitors. It'll become much more tractable to handle all of the many many edge cases:

{
  coolAccount: account {
    data(encoding: BASE58)
    ... on TokenAccount {
      mint
    }
    owner {
      dataYouDoNotWantYourVisitorToProcessYet: data(encoding: BASE64)
    }
    ...SpecialAccountsFragment
    ...CompressedDataFragment
  }
}

fragment SpecialAccountsFragment on Account {
  ... on VoteAccount {
    authority
  }
}

fragment CompressedDataFragment on Account {
  compressedData: data(encoding: BASE64ZSTD) 
}

Oooh. I think I found that ‘merge the type info into the visitor’ thing I was looking for before.

https://github.com/DxCx/graphql-js/blob/async/src/language/visitor.js#L321-L351

[steveluscher]

K, I'm suspicious that there might be a bug here somewhere because I would not expect the test with no fragment specific fields to fetch with jsonParsed encoding. I think we need a few kinds of tests, multiplied by the three ways of making subselections (fields, inline fragments, and fragment spreads).

• Subselections that don't require a fetch at all (ie. just fetching address)
• Subselections that require jsonParsed (ie. literally requesting __typename, subtype-specific fields like MintAccount#mint)
• Subselections that require baseX data

…plus a combination of each.

[steveluscher]

Could always implement this with visit() rather than spelunking in value.kind. This probably applies anywhere you find yourself doing .kind.

Or not. This is fine too!

[steveluscher]

God I wish this thing let you write AST selectors. https://medium.com/dailyjs/eslint-selectors-just-got-super-powers-402ab942def5

Then you could do things like:

visit(node, {
    'FragmentSpread > Field': (node, key, parent, path, ancestors) => {
        // Only finds `Field` nodes who are the children of `FragmentSpread` nodes.
    },
});

If only there were like a TSQuery for GraphQL? https://medium.com/@phenomnominal/easier-typescript-tooling-with-tsquery-d74f04f2b29d

[buffalojoec]

@steveluscher It seems to me that the resolver is working correctly. I'm wondering if, in regards to your comments, you may have overlooked the .not here?

[steveluscher]

🪦 OMG I missed that. Nice work!

[buffalojoec]

Merge activity

• Feb 22, 3:57 PM EST: @buffalojoec started a stack merge that includes this pull request via Graphite.
• Feb 22, 4:01 PM EST: Graphite rebased this pull request as part of a merge.
• Feb 22, 4:02 PM EST: @buffalojoec merged this pull request with Graphite.

[github-actions]

🎉 This PR is included in version 1.90.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

Because there has been no activity on this PR for 14 days since it was merged, it has been automatically locked. Please open a new issue if it requires a follow up.