Use GraphQL Codegen to generate more accurate resolver types

[orta]

Alternative to #4786

This method tweaks GraphQL codegen to get accurate types, instead of bending the type system to fit (e.g. #4786), this work certainly makes me yearn for relay-compiler style generation of resolver types where it creates the exact types you need instead of a multi-thousand line file where we can pick useful bits out.

Anyway, this seems to work pretty well in strict and unstrict environments. It handles the date/string mismatch by making Prisma models be the default expectation of an resolver. This option has its downsides (I have a few resolvers which return dumb js objects in some places, but that's a rarity.)

Here's an example of a file using this setup:

import cuid from "cuid"
import { dnull } from "dnull"

import { db } from "src/lib/db"
import { MutationResolvers, QueryResolvers } from "types/graphql"

export const users = () => {
  return db.user.findMany()
}

export const user: QueryResolvers["user"] = ({ id }) => {
  return db.user.findUnique({
    where: { id },
  })
}

export const createUser: MutationResolvers["createUser"] = ({ input }) => {
  return db.user.create({
    data: dnull({
      id: cuid(),
      ...input
    }),
  })
}

export const updateUser: MutationResolvers["updateUser"] = ({ id, input }) => {
  return db.user.update({
    data: dnull(input),
    where: { id },
  })
}

export const deleteUser: MutationResolvers["updateUser"] = ({ id }) => {
  return db.user.delete({
    where: { id },
  })
}

export const createNewUserOnAccount: MutationResolvers["createNewUserOnAccount"] = async (args) => {
  if (!context.currentUser) return null

  const username = await canUseHandle(args.input.username)
  if (!username) {
    return null
  }

  return db.user.create({
    data: {
      id: cuid() + ":user",
      username,
      roles: context.currentUser.roles,
      account: {
        connect: context.currentUser.account,
      },
    },
  })
}

( dnull is essential to working with prisma/graphql to handle this issue and avoid data loss, it might be worth thinking about integrating it properly in some way )

[netlify]

✅ Deploy Preview for redwoodjs-docs canceled.

Name	Link
🔨 Latest commit	c36252e
🔍 Latest deploy log	https://app.netlify.com/sites/redwoodjs-docs/deploys/626a5546e714c200088d7eb3

[orta]

⚠️ making sure this is highlighted - there might be other alternative methods to grabbing the list of prisma models which doesn't involve require-ing from the user's node_modules.

[dac09]

Thanks for pointing this out - I get your reservation that it feels a little off, but I also think Prisma is designed to do this, with the generated types ending going into node_modules anyway!

[fenos]

This feels somewhat the right thing to do with the services definitions.
Is there an ETA on when this will be merged?

[jtoar]

Thanks for your patience @orta! And @fenos there's no timetable yet, but I'll bring it up at the meeting this week to see if we can prioritize it. In general we don't like to keep things waiting but we're still working though v1 backlog.

[Urigo]

@orta not really related to the changes here but what would you imagine for the Relay style resolver generator?
Do you mean writing the schema and resolvers next to each other?
We had some interesting experiments in the past that might be related?
dotansimha/graphql-code-generator#6379
Would love to hear your thoughts on that

[orta]

wow cool - dotansimha/graphql-code-generator#6379 its in the space for what I was thinking, yep - that's a clever TypeScript approach (using the string of the query to be a matcher against a central type mapping)

I think structurally I'd still end up with something a bit simpler. E.g. each set of resolvers in each SDL string would end up with a corresponding .d.ts which only has the types for that set (which would echo how relay handles that client-side)

It's a clever exploration as it looks like there are WIP builds, I will give it a run at some point (that shouldn't need to block this PR) - thanks

[dac09]

Nice one @orta - I do prefer this approach a lot more - as it keeps the type generation all in "one place". Let me try a few things out and I'll merge - looks like you've covered all the tests and stuff already! Thank you so much!

[dac09]

Needs one small change, fixing and will merge afterwards!

[dac09]

Added a few small fixes and tested with:

• rw g service --crud
• rw g sdl without relation
• rw g sdl with relation
• rw g scaffold

[orta]

Nice

[orta]

Forgot to note for folks how extend the GraphQL context - so here's a quick example from my codebase's api/src/functions/graphql.ts:

import { createGraphQLHandler } from "@redwoodjs/graphql-server"

import directives from "src/directives/**/*.{js,ts}"
import sdls from "src/graphql/**/*.sdl.{js,ts}"
import services from "src/services/**/*.{js,ts}"

import { getCurrentUser } from "src/lib/auth"

import { db } from "src/lib/db"
import { logger } from "src/lib/logger"
import { APIGatewayProxyEvent } from "aws-lambda"

// Extends the context API type with a new string
declare module "@redwoodjs/graphql-server/dist/functions/types" {
  interface RedwoodGraphQLContext {
    gamePlayUserID: string
  }
}

// Then this is how I add to the context via extraPlugins
export const handler = (event: APIGatewayProxyEvent, context: any) =>
  createGraphQLHandler({
    getCurrentUser,
    loggerConfig: { logger, options: {} },
    directives,
    sdls,
    services,
    extraPlugins: [
      {
        onExecute: async (e) => {
          e.extendContext({ gamePlayUserID: event.headers["thingy-gameplay-id"] })
        },
      },
    ],
    // ...
  })(event, context)

[dac09]

Thanks @orta - the other way you can do this is, which admittedly is undocumented (but in the types). I'll make sure I add it into the docs shortly

export const handler = (event: APIGatewayProxyEvent, context: GlobalContext) =>
  createGraphQLHandler({
    getCurrentUser,
    loggerConfig: { logger, options: {} },
    directives,
    sdls,
    services,
    context: () => {
      return {
        ...context,
          gamePlayUserID: event.headers["thingy-gameplay-id"] }
       }
    }
    // ...
  })(event, context)

I haven't tried it recently, but I think you can also avoid wrapping the function if you want, because the context already has the event as context.event