refactor(experimental): revise accounts schema

[buffalojoec]

This PR introduces a revised version of the account schema for jsonParsed
account data.

Typically we see JSON-parsed account data like this:

{
  data: {
    parsed: {
      info: {
        /* data */
      },
      type: 'mint',
    },
    program: 'Tokenkegxxxxxxxx',
    space: 82n,
  },
}

However, when it comes to GraphQL, I've made an opinionated decision to move
away from the JSON-parsed format returned by the RPC, and instead opt for this
"optimized" format:

{
  data: {
    /* data */
  },
  meta: {
    program: 'Tokenkegxxxxxxxx',
    space: 82n,
    type: 'mint',
  },
}

Since we know we'll always get program, space, and type, we can extract
those to be "parsed metadata" about an account and introduce the meta field.

[buffalojoec]

Current dependencies on/for this PR:

• master
  • PR refactor(experimental): revise accounts schema #1817 👈
    • PR refactor(experimental): revise transactions schema (Part 1) #1818
      • PR refactor(experimental): use GraphQL lang for schema #1819
        • PR refactor(experimental): set up GraphQL transaction tests #1823
          • PR refactor(experimental): set up GraphQL block tests #1829
            • PR refactor(experimental): normalize GraphQL loader args and cache keys #1830

This stack of pull requests is managed by Graphite.

[steveluscher]

Let's go further! Free yourself completely from the JSON-RPC responses, and imagine building a UI that displays a mint account. For sure you would want this:

query {
  account(address: "abc") {
    # Stuff that every account has...
    address
    owner
    space
    ... on MintAccount {
      decimals
      isInitialized
      mintAuthority
      supply
    }
  }
}

No need for data, meta, or type fields.

Then in JS:

const account = ...; // Fetch the account
if (account.__type === 'MintAccount') {
  // TypeScript has now refined `account` to have the `MintAccount` fields
  console.table({
    decimals: account.decimals,
    supply: account.supply,
  });
}

The only thing that has to happen to make this work is that the fields have to be unique among all the types. You can't have a MintAccount that returns a supply that's an integer and a FooAccount that returns supply that's an object. In practice I haven't found this to be very difficult to avoid.

tl;dr collapse the account schema as flat as is practical and see what we end up with.

[steveluscher]

Isn't this always of the MintAccount type? Shouldn't be any need to type the subselection.

[buffalojoec]

Yes it's always a mint account, and I could stick the MintAccount type in there (which would be pretty cool), but that eliminates the potential for someone to get the mint account as base58, etc. It would always be the parsed MintAccount.

I'm leaning towards it though, because having to specify the spread here stinks.

[steveluscher]

One way we can do that is to let fields take arguments:

source {
  mint(encoding: BASE_64) {
    data # Base64String
  }
}

[steveluscher]

My idea here is better.

[steveluscher]

What should we call this for real in this greenfield schema?

• Assigned Program id
• Owner
• Owning program

https://docs.solana.com/developing/programming-model/accounts#ownership-and-assignment-to-programs

[buffalojoec]

ownerProgram I think.

[steveluscher]

We need to talk about whether to make things like this plural fields or connections to prepare for a future where it's possible to paginate through them.

https://relay.dev/graphql/connections.htm

[buffalojoec]

Pagination has been discussed for RPC v2, yeah? Probably good to do.

[buffalojoec]

Let's go further! Free yourself completely from the JSON-RPC responses, and imagine building a UI that displays a mint account.

Yeah, I like this. The primary reason I went with data and meta was to isolate the field names, so any parsed accounts could be named whatever, without worry of collision.

The only thing that has to happen to make this work is that the fields have to be unique among all the types. You can't have a MintAccount that returns a supply that's an integer and a FooAccount that returns supply that's an object. In practice I haven't found this to be very difficult to avoid.

Right, so we could do this with the JSON-parsed data no problem. It's all known parsed structures and we can rename certain fields however we want to make this work. However, I'm thinking about a future where I can plug my IDL or Kinobi AST into this API and get parsing of my program's stuff!

This might complicate that.

[buffalojoec]

Merging this stack for now so we can get the new schema layout in #1819, which will allow us to much more easily discuss changes! I also won't have to make the changes twice.

Created #1831 for tracking, for now.

[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.