Support Object Extensions

[zvictor]

Object type extensions are used to represent a type which has been extended from some original type.

from http://spec.graphql.org/draft/#sec-Object-Extensions

It's easy to add additional fields to existing types using the extend keyword. Using extend is particularly useful in avoiding a large list of fields on root Queries and Mutations.

from https://www.apollographql.com/docs/graphql-tools/generate-schema/#extending-types

---

In our repo we could see it in action in the modularised example. The sayHello resolver is a UDF that belongs to the accounts folder, but we need to define it in the root type Query because right now we can't extend Query anywhere else:

https://github.com/zvictor/faugra/blob/6a6446bce541ae1c41e569984b9ff553bc0410c0/examples/modularized/Query.gql#L5

[lregnier]

Hi, @zvictor! If you were able to extend from the root types (Query and Mutation), that should be enough for covering this use case, right? In other words, you're not looking for extending for other user-defined types (e.g. User, etc), at least initially?

The former should be a much more straightforward change to implement within Fauna than the latter.

[zvictor]

In short: Yes, extending the root types is enough for now.
That could be processed inside fauna or even by @graphql-toolkit/schema-merging at push-schema.js

Either one converting the extend instruction into the extended object is fine for faugra.

---

Long answer: I am in favour of modularised development and I believe nested mutations would play a very important role in the faugra context.

If I have a type User in my accounts module and I want to define a changeName mutation for it, it doesn't make sense that I define changeName in a global scope. I would rather define changeName inside User:

type User {
  name
  age
  changeName(name: String!): String! @resolver(name: "changeAccountsUserName") 
}

That being said, nested mutations have known dangerous issues and the community has not come to an agreement on it yet:

• An example of the nested mutation MichalLytek/type-graphql#64 (comment)
• Proposal: Serial fields (nested mutations) graphql/graphql-spec#252

So, for now, "object extensions" of the root types would be our workaround for this issue. I don't yet see a strong use case for extending other types, such as user-defined types.

[zvictor]

with the migration from @graphql-toolkit to @graphql-tools implemented today, we can now use extend 🎉