feat: create @requires integration that functions like a normal resolver #3292

clayne11 · 2024-09-18T18:08:41Z

The explicit_requires flag currently generates the @requires resolver inside the execution context. It also doesn't use the normal resolver resolution process and adds a custom implementation that is always called, even if the field isn't requested.

The new computed_requires flag looks for @requires directives and mutates the schema to add dynamic field arguments and directives that are used internally by gqlgen.

These additional directives (@entityReference and @populateFromRepresentations) are runtime directives that "computed_requires" adds implementations for that enable us to fetch the correct data from the representations array and populated it into the dynamic argument for the @requires field.

The new implementation still isn't typesafe and generates the required fields into a map[string]any. This is the same as the existing explicit_requires implementation.

We will follow up with type safety in a future PR. To support type safety we need to generate types and marshaling logic for GraphQL operations (vs just schemas like we do today) which is a large lift.

I have:

Added tests covering the bug / feature (see testing)
Updated any relevant documentation (see docs)

@requires

The "explicit_requires" flag current generates the @requires resolver inside the execution context. It also doesn't use the normal resolver resolution process and adds a custom implementation that is always called, even if the field isn't requested. The new "computed_requires" flag looks for @requires directives and mutates the schema to add dynamic field arguments and directives that are used internally by gqlgen. These additional directives (@entityReference and @populateFromRepresentations) are runtime directives that "computed_requires" adds implementations for that enable us to fetch the correct data from the representations array and populated it into the dynamic argument for the @requires field.

…tions.

clayne11 · 2024-09-18T18:09:20Z

_examples/federation/products/gqlgen.yml

@@ -66,3 +67,5 @@ models:
      - github.com/99designs/gqlgen/graphql.Int
      - github.com/99designs/gqlgen/graphql.Int64
      - github.com/99designs/gqlgen/graphql.Int32
+
+omit_complexity: true


Simply reduces generated code for unused features. Not a material change.

clayne11 · 2024-09-18T18:17:08Z

_examples/federation/reviews/graph/schema.resolvers.go

@@ -11,23 +11,62 @@ import (
 	"github.com/99designs/gqlgen/_examples/federation/reviews/graph/model"
 )

+// ManufacturerID is the resolver for the manufacturerID field.
+func (r *productResolver) ManufacturerID(ctx context.Context, obj *model.Product, federationRequires map[string]interface{}) (*string, error) {


New resolver function automatically generated and includes the @requires fields in the federationRequires map.

clayne11 · 2024-09-18T18:18:51Z

codegen/data.go

@@ -97,7 +121,7 @@ func BuildData(cfg *config.Config, plugins ...any) (*Data, error) {

 	dataDirectives := make(map[string]*Directive)
 	for name, d := range b.Directives {
-		if !d.Builtin {
+		if !d.SkipRuntime {


Renamed this — BuiltIn didn't accurately describe the behavior.

clayne11 · 2024-09-18T18:19:30Z

codegen/data_test.go

+				Name: "excludeDirective",
+				Args: nil,
+				DirectiveConfig: config.DirectiveConfig{
+					SkipRuntime: false,


Used composition here in the underlying struct so I needed to update the instantiation.

clayne11 · 2024-09-18T18:20:01Z

codegen/directive.go

+	Name string
+	Args []*FieldArgument
+
+	config.DirectiveConfig


There can be multiple config properties, I thought it was easier to just pass this through. I can change this to individual parameters and map them onto the object if you'd prefer.

clayne11 · 2024-09-18T18:21:34Z

codegen/directive.go

+
+func (d *Directive) CallPath() string {
+	if d.IsBuiltIn() {
+		return "builtInDirective" + d.CallName()


We now have two types of directives: user provided and "built in" where the implementation is statically provided by the plug in.

For builtIn directives we call a static function vs an instance function.

StevenACoffman · 2024-09-18T20:07:36Z

plugin/resolvergen/testdata/filetemplate/out/schema.custom.go

+//  - When renaming or deleting a resolver the old code will be put in here. You can safely delete
+//    it when you're done.
+//  - You have helper methods in this file. Move them out to keep these resolver files clean.
+/*
+	func AUserHelperFunction() {
 	// AUserHelperFunction implementation
 }
+*/


This change is causing one test to fail

I reverted it but this change gets made automatically when I run go test ./.... I think we need to revert #3243.

Ah, crud. huh. Either that, or rethink how we do testing for that behavior.

Yeah potentially. Either way, I would revert for now, we can fix it later. I don't want master to be in a broken state. We should also update CI to ensure the git state isn't dirty after running the tests.

StevenACoffman · 2024-09-18T20:08:27Z

plugin/resolvergen/testdata/followschema/out/schema.resolvers.go

+//  - When renaming or deleting a resolver the old code will be put in here. You can safely delete
+//    it when you're done.
+//  - You have helper methods in this file. Move them out to keep these resolver files clean.
+/*
+	func AUserHelperFunction() {
 	// AUserHelperFunction implementation
 }
+*/


This change is causing one test to fail

coveralls · 2024-09-18T20:18:18Z

coverage: 58.813% (-0.7%) from 59.525%
when pulling 0508cef on uber:curtis.layne/requires-no-types
into e81a387 on 99designs:master.

clayne11 added 6 commits September 18, 2024 10:59

Add mechanism for supporting statically provided directive implementa…

3ba9fe3

…tions.

Get @populateFromRepresentations working

a2e1636

Add tests for computedrequires

06c7062

Update documentation

ae055c0

Ensure everyone that should be is using version 2

b41ae1a

clayne11 commented Sep 18, 2024

View reviewed changes

clayne11 force-pushed the curtis.layne/requires-no-types branch 2 times, most recently from a01332f to 2dcfdb3 Compare September 18, 2024 19:45

StevenACoffman reviewed Sep 18, 2024

View reviewed changes

Fix linter issues

0508cef

clayne11 force-pushed the curtis.layne/requires-no-types branch from 2dcfdb3 to 0508cef Compare September 18, 2024 20:15

StevenACoffman merged commit b020c09 into 99designs:master Sep 18, 2024
16 of 17 checks passed

StevenACoffman added the federation Related to Apollo federation label Sep 20, 2024

RyanMcCabe-catapult mentioned this pull request Oct 3, 2024

Using @entityResolver(multi: true) causes "directive entityResolver is not implemented" to be thrown when the entity is used in another Query #3160

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: create @requires integration that functions like a normal resolver #3292

feat: create @requires integration that functions like a normal resolver #3292

clayne11 commented Sep 18, 2024

clayne11 Sep 18, 2024

clayne11 Sep 18, 2024

clayne11 Sep 18, 2024

clayne11 Sep 18, 2024

clayne11 Sep 18, 2024 •

edited

Loading

clayne11 Sep 18, 2024

StevenACoffman Sep 18, 2024

clayne11 Sep 18, 2024

StevenACoffman Sep 18, 2024

clayne11 Sep 18, 2024

StevenACoffman Sep 18, 2024

coveralls commented Sep 18, 2024

feat: create @requires integration that functions like a normal resolver #3292

feat: create @requires integration that functions like a normal resolver #3292

Conversation

clayne11 commented Sep 18, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clayne11 Sep 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Sep 18, 2024

clayne11 Sep 18, 2024 •

edited

Loading