How to skip generation of entity resolvers for extended types

[MiguelCastillo]

What happened?

go run github.com/99designs/gqlgen
validation failed: packages.Load: /Users/miguel/khan/webapp/services/assignments/resolver.go:17:9: cannot use &(entityResolver literal) (value of type *entityResolver) as graphql.EntityResolver value in return statement: missing method FindFooByID

I'd need to add an entity resolver FindFooByID.

What did you expect?

No entity resolvers being needed for extended that only have external fields. Is this something we can optimize in gqlgen so that entity resolvers for extended type with only external fields arent needed? Or would that be some sort of violation of the spec?

Minimal graphql.schema and models to reproduce

type Foo @key(fields: "id") @extends {
    id: ID! @external
}

type Bar {
   foo: Foo
}

versions

• gqlgen version? 0.11
• go version? 1.13.8 darwin/amd64
• dep or go modules? modules

[csilvers]

Cc @marwan-at-work

[marwan-at-work]

My memory is a little rusty, but if there no extra fields why are you "extending" the type in the first place? :)

Maybe we can make the error messaging a little better by checking if all fields are external and erroring out if you have "@extends"

[csilvers]

The issue, as I understand it, is this: I am defining my own type that has a field of type Foo, which is defined somewhere else. Because Foo is defined somewhere else, my resolve_foo() only needs to return a "stub" Foo that defines the @key-fields for a Foo.

In the example for this issue, it would be something like

   func (Bar) resolveFoo {
       return Foo{ID: myId}
  }

But gqlgen obviously can't compile that code because it doesn't know about the Foo type. In this case, we are telling it about the Foo type by using the @extends syntax. That's the only way I know of, because we don't want to redefine Foo, and even if we could we don't necessarily know all the fields it has.

So the question is: what is the right way to do something like this, if not to do this "empty @extends"? There's probably a right way that we just don't know about.

[MiguelCastillo]

Hmmm yeah sorry I wasn't more specific here. As Craig said this is a type that is defined in a different service.

Service A

type Foo {
   id: ID!
   cerealType: string
   morningRoutine: string
}

Service B, which would like to be able to add Foo as part of its own type Bar

type Foo @key(fields: "id") @extend {
   id: ID! @external
}

type Bar {
   foo: Foo
}

In this sort of setup, Service B is currently required to provide an entity resolver for Foo.

In this contrived example, that's not a real big deal. But we have an interface with lots of implementing types so each one of those types currently needs an entity resolver.

Let me know if it would help to setup a sample repo.

[csilvers]

I think the right fix is that if a type is extended, and all the listed fields are @external, that we don't require a definition for the top-level lookup-by-id for that type (since the server will never ask us to resolve that type). Does that sound right to you @marwan-at-work ?

[benjaminjkraft]

Yeah, I think the spec is a bit unclear on this point. If I understand correctly, if a type has only @external fields, then the gateway should never ask us for it. We shouldn't even have to include it in the _Entity union. But the spec does say if it has an @key, it's gotta be in _Entity. I've asked them to clarify: https://github.com/apollographql/apollo-server/issues/3852.

[benjaminjkraft]

While writing about the spec issues, I realized it's possible we could fix this entirely in gqlgen. It would be a little ugly, but we'd just have to make the server not generate these methods, and instead if it gets a query for some type that doesn't have a method, it can just handle it some special way. (The only fields that could legitimately be requested are those passed, anyway.) But then again, it's not actually stated in the spec that we can never be asked for an @external field, even though I think that's the clear intent, so maybe we're back in the same place there.

[benjaminjkraft]

This led me to figure out what Apollo does in this situation. I've described it in the Apollo issue. It's basically what I proposed in the previous comment: the server just sort of does what it can since there's no application logic for this.