RFC: Enhancing gql.tada with Server-side GraphQL Type Retrieval

[pevisscher]

This RFC proposes leveraging GraphQL's introspection capabilities in gql.tada to automate type definition for server-side resolvers, eliminating the need for manually writing queries for type extraction.

Proposal

This RFC proposes leveraging GraphQL's introspection capabilities in gql.tada to automate type definition for server-side resolvers, eliminating the need for manually writing queries for type extraction.

Proposed Solution

Introduce a new API e.g. graphql.field<T, F>(), where T is the type (e.g., Query or Mutation) and F is the field name (e.g., addPost). This function utilizes the already stored introspection data, and further utilizes the args and type declaration of fields.

type Query {
    getPost(id: ID): Post
}

type Mutation {
    addPost(id: ID!, author: String!, title: String!, content: String!, url: String!): Post!
}

type Post {
    id: ID!
    author: String
    title: String
    content: String
    url: String
    ups: Int!
    downs: Int!
    version: Int!
}

Using the example schema, the API simplifies type generation:

type AddPostVariables =  VariablesOf<typeof graphql.field<"Mutation", "addPost">>
type AddPostResult =  ReturnType<typeof graphql.field<"Mutation", "addPost">>

// Use in server-side resolver
const addPostResolver = async (args: AddPostVariables): Promise<AddPostResult> => {
    // Implementation...
};

Summary

This enhancement streamlines the development process, ensuring type safety and reducing boilerplate by automatically deriving types from the GraphQL schema.

The proposed introspection-based solution offers an alternate approach to the issue described in gql.tada GitHub issue #10, addressing the need for simplified type generation. By automatically deriving types directly from the GraphQL schema using introspection, it circumvents the manual effort and complexity currently discussed in the issue, providing a streamlined and type-safe method for handling GraphQL operations on the server side.

[kitten]

Preliminary thought here that this is out-of-scope of gql.tada. Sorry! ❤️
The general idea of what we're currently experimenting with is captured here: #10

The context here is that I don't think SDL-first schema builders (aka “schema-first”) are a particularly good experience, and generally regarded as outdated by many members of the server-side GraphQL community.

Even if we wanted to support it, the spirit of gql.tada would dictate that we should instead parse SDL, and not provide loose types that you can annotate (which is more along the lines of what GraphQL Code Generator can do for you already)
In other words, there's, in my opinion, no improvement to be had from the experience here compared to GraphQL Code Generator, and the goal of having a beginner friendly approach (#10) isn't compatible with SDL-resolver-type annotations.

A project that is already doing this afaik though is Elysia

However, our focus is more on integrating code-first schema builders at a type level with gql.tada.

Hope that makes sense 🙌

[pevisscher]

I applaud you for explicitly outscoping this from the project! ❤️