You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apollo used to have a resolver called __resolveObject, which would resolve a type, rather than having to resolve every field it interacts with. This has since been replaced with __resolveReference.
The main advantage to this approach is that it allows you to get a "base" object, and then resolve individual fields as required.
Does gqlgen support a similar feature?
Because as it stands, it seems like I have to explicitly find every single instance where a type is referenced by another type, notate the field as resolvable, and then provide a boilerplate resolver for the field. Feels like a lot of boilerplate, when I am almost always able to resolve an entity by reference.
For example, if I know the ID of a User, I can easily resolve all User types by looking at the id field. If no ID is present, the resolver returns null. I don't need to state every field where a User shows up, and if the User is missing a field, I can implement field resolvers for those specific fields (if necessary), which are only attempted to be resolved if requested in the query.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Apollo used to have a resolver called __resolveObject, which would resolve a type, rather than having to resolve every field it interacts with. This has since been replaced with __resolveReference.
The main advantage to this approach is that it allows you to get a "base" object, and then resolve individual fields as required.
Does
gqlgen
support a similar feature?Because as it stands, it seems like I have to explicitly find every single instance where a type is referenced by another type, notate the field as resolvable, and then provide a boilerplate resolver for the field. Feels like a lot of boilerplate, when I am almost always able to resolve an entity by reference.
For example, if I know the ID of a User, I can easily resolve all
User
types by looking at theid
field. If no ID is present, the resolver returns null. I don't need to state every field where a User shows up, and if the User is missing a field, I can implement field resolvers for those specific fields (if necessary), which are only attempted to be resolved if requested in the query.Beta Was this translation helpful? Give feedback.
All reactions