Support for multiple GraphQL Schemas in one server-instance

[andygrunwald]

This is more a feature request/request about how you foresee gqlgen.

Usecase

Having the possibility to have two GraphQL endpoints with different schemas.

• A frontend has different requirements than a backend API
• A backend API/GraphQL Schema might expose nearly all fields of a database (e.g., for simple CURD operations or using the backend also as a different use case (ERP-System))
• In a frontend GraphlQL API you might don't want to expose all fields like in a backend API

Examples

... of things that might not be exposed:

• Shop: Purchasing costs for the supplier
• Blog: Flag if an article is published or not
• Data (imported): The source from where it gets imported

Discussions

A related discussion can be read at Splitting a GraphQL API between public & private.

Additionally, I asked this on Gitter, but there was no answer (yet).

Potential implementations

Supporting this

Based on what I know, not that much would be adjusted:

Either the config will be adjusted to support multiple schemas.
Or the generate command accepts arguments to point to a specific config.
This would need two different configurations.
Not sure how this would work with the traditional ´go generate` command.

From the server implementation, it could be possible already to start two instances and map the handlers to two endpoints.
The playground would need support to add the endpoint. But this might be a problem already solved by the community.

Advising two services

An alternative solution could be to don't support this and advise you to create two independent services. This would make the source code of gqlgen lean and not more complex.
Those two services would both act with the data storage.

Client A (Mobile client) <-------->  Service A (Frontend) <--------> Database <-------->  Service B (Backend) <--------> Client B (Backend-UI)

Challenges:

• Keeping implementations in sync
• (Possible) sharing source code/models if the schema is partially the same

Thoughts?

What are your thoughts on this?
Would this be an interesting feature? Or is the vision more to keep it lean and recommending multiple independent services in this case?

[andygrunwald]

@hlubek put already some work into it and it seems that it is already possible to run two Graphs in one instance. See his prototype at https://github.com/hlubek/graphql-multischema-experiment

[ddevault]

I am interested in this as well, but somewhat differently: I want to have the same schema (this is important), but provide different entry points (i.e. different versions of type Query).

The use-case is (1) providing a normal gql API like you're used to, but also (2) allow the user to register webhooks with a GraphQL query representing the subset of the webhook payload they'd like to have sent back to them. The different entry point would, rather than having the global system as the "root", set the root to the particular webhook event which occured, and you could access data from the global system so long as you could trace a path from the webhook to it.

I have some ideas for hacking which might circumvent this limitation, but it would be nice if something like this were supported in a more first-class manner.

[jufemaiz]

Just hitting this point too! Good to see the conversation emerging!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

Nope

[xyu-io]

https://github.com/xyu-io/xyu-graphql

That is my own case, but I had instant record implementation steps to forget yesterday, when I try it again today after more complex cases, using gqlgen command produces the missing part of the important content in resolver.go, cause I can't complete implementation business interface, I hope you can help me find the answer and give me some effective Suggestions.

[aseidma]

@hlubek's solution works well in general, it would however be nice if there was a way to share resolvers among common schema objects.
E.g. when working with the following structure:

type Todo {
  title String!
  user User!
}

type User {
  id ID!
}

If I've implemented a separate resolver for the User type, gqlgen will create a resolver method called User on the todoResolver.
If I then use the Todo type in another schema, gqlgen will create a new todoResolver and with it a new User method. As far as I can see, there is currently no way to share the implementation of the todoResolver.

This means you have to keep the implementations in both schemas up-to-date, even though they are identical.