A remote type cannot implement a non-remote interface

Issues GraphQL
1

Experience Report for Feature Request

What you wanted to do

Create a remote type that does not generate any DQL schema, mutations, or resolvers based upon a interface that does. This remote type would be used as the payload of a custom query adding in additional fields from the lambda function before returning the data.

What you actually did

Created a new type and redefined all of the fields I had already defined in my interface.

type Post {
  id: ID
  title: String
  # many more fields
}

type CustomPost @remote {
  id: ID
  title: String
  # many more fields copied from Post type
  extraField: string
}

Why that wasn’t great, with examples

interface Post {
  id: ID
  title: String
  # many more fields
}

type CustomPost implements Post @remote {
  extraField: string
}

If the schema has @remote on a type that implements an interface it will throw the error:

resolving updateGQLSchema failed because […]: Type […]; with @remote directive implements interface […]; which doesn’t have @remote directive.

Any external references to support your case

Nothing really other than a type implementing an interface usually does not throw an error if the interface has different directives. I would understand the point if a non-remote type was trying to implement a remote interface but the opposite I would think is capable of being supported without causing errors. But then again, if we were following exact schema specification, I would have to declare all of my fields in both every interface and implementing types causing this to be a mute point altogether.

3

I guess, the underlying reason for this decision was simplicity.

Keep remote and non-remote things separate altogether, don’t let them mix-up because we don’t know when that can be a problem.

If we were not to aim for simplicity, then one would be able to declare a schema like this as you suggested:

interface Post {
  id: ID
  title: String
  # many more fields
}

type CustomPost implements Post @remote {
  extraField: string
}

which doesn’t have any non-remote types implementing the Post interface. Which would result in queries being generated for that interface, but no way to add data for it through mutations. Which renders queries useless for that interface.
Apart from that, predicates will be allocated for it and the necessary indexes will be created for it. Which would again be useless.

Also ATM, the way auth queries are rewritten to DQL, they create DQL for every implementing type of interface. Then, supporting such schema would require us to put more checks everywhere in the code. So overall, not mixing up @remote with non-remote kept things simple for us.

If you want a remote type to implement an interface, declare a remote interface.

3 Likes
4

Not a blocker and there is a work around. Thanks for the update.