-
Notifications
You must be signed in to change notification settings - Fork 780
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(experimental): graphql: enable schema extending #2613
base: master
Are you sure you want to change the base?
refactor(experimental): graphql: enable schema extending #2613
Conversation
|
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @buffalojoec and the rest of your teammates on Graphite |
7e67c8d
to
b9bdb88
Compare
b9bdb88
to
1f83c37
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, here's what I think is much more likely to happen.
- Export the schema from
@solana/rpc-graphql
- Export the context creator,
createSolanaGraphQLContext()
- Let people stitch the schemas together themselves
See a tutorial on this and a running example.
Here's why:
- People's extensions might collide with our types.
@graphql-tools/stitch
lets you supply functions that decide how to resolve conflicts. - People's extensions might simply aim to add a field to an existing type (eg. imagine adding
nfts
toAccount
or whatever). Take a look at this example with two different schemas being merged into oneUser
type. - People's schema executors might be remote, and not at all written in JavaScript. The present PR doesn't offer a solution for delegating the whole entire subquery to (for instance) some URL.
@graphql-tools/stitch
does.
Problem
Many projects who wish to use the RPC-GraphQL resolver library may wish to
extend the default schema, which is designed around the
Solana JSON-RPC API. Currently, the library does
not allow for such customization.
There's currently no way for developers to add additional queries, types, and
resolvers to the GraphQL client, making extending this powerful library very
difficult.
Summary of Changes
Introduce three optional configurations for
createRpcGraphQL
.queryResolvers
: Custom root query resolvers.typeResolvers
: Custom type definition resolvers.typeDefs
: Custom GraphQL schema type definitions.I've also made the default type resolvers, which drive the batch loader,
availably publicly to downstream users (
resolveAccount
,resolveBlock
,resolveTransaction
).Lastly, I've added a test demonstrating how one might define custom types,
resolvers, and a custom query and provide those to the GraphQL RPC client.
Note: This should be the first in a series of changes to allow schema
extension. While the change proposed herein enables a wide range of possible
extended functionality, there are a few limitations. One such limitation is the
lack of ability to provide custom codec-based resolvers to convert
base58
orbase64
encoded accounts/instructions to custom decoded types.Ref: #2614