Type-safe GraphQL resolvers with garph

Write resolvers without the codegen and debugging. Infer types with code-first GraphQL schemas.
Learn more about GraphQL: graphql.wtf
#graphql #webdev

[@wezter96]

I am looking into if there is something in the GraphQL landscape that offers a similar DX and velocity as building an API with tRPC. Do you know any specific tools you think can achieve that or do you think that for smaller scale projects tRPC is probably the better option? I have briefly been looking into Garph with GQty + Yoga and also currently looking at your video about pothos. What would be your recommendation?

[@dimitro.cardellini]

The problems with typing resolvers is that the type can have their own resolvers those are not considered on the GQL Schema level what ever you use. As instance let's look on on the Cart type. Let's guess that Query.cart resolver returns cart without "subTotal" field, and then Cart.subTotal resolver calculates the subTotal using the parent.items array. Or, similar example Money type has a resolver for formatted field, to allow format money on the type level and don't move responsibility on that to the more important business entities. At the end to correctly type resolvers we need to combine Schema and Resolvers themselves -- so, garpgh doesn't help with that. Unfortunately

[@notrab]

I’d use the database as the source unless you hook into the execution phase and project a further selection set for fields you want to calculate on. This video is a quick example. You should use the actual db contents instead of root/parent

[@dimitro.cardellini]

@@notrab > You should use actual DB contents instead of root/parent It sounds ... strange. If all projects in all cases operate only with a single DB, then GraphQL doesn't have parent field in its resolvers. Let's look on the real case: There is a subscription integrator that allows to manage licenses on a lot of different software products. Licenses for each specific product are managed by the dedicated server that exposes its own API, has its own DB and uses its own m2m-authorization. So, the queries like: query ($subscriptionId: ID!){ subscription(id: $subscriptionId) { productCode paymentMethod { ... } license { ... } } Couldn't be processed with a single DB request. The second point that the GraphQL is just an intetface, application can expose other interfaces as well, so the business logic must not depend on the interface specific details otherwise we get two applicstions inside of one and it becomes hell to support. So, the problem with type-safe resolvers is still actual

[@stepci]

Garph maintainer here. We have heard from the community about the issue and have since added .omitResolver modifier you can add to the field so you can skip returning the value and resolve it elsewhere using a separate resolver

[@dimitro.cardellini]

@@stepci actually the problem of correct resolvers typing is a problem of the type generstor rather then of GraphQL. It is better to have schema free from resolution logic -- actually it is a contract, but not its implementation We have a file field-resolvers.ts where for each GraphQL-type we define the union that is a list of fields that have resolvers. Now we define types for resolvers manually, so we still have an issue that our return values could miss the Schema, but at least we don't mark fields as optional, as many teams do.

[@arsalanshaikh3763]

It is like pothos code first graphql