Make it easy to prevent merging of root query fields

[brunolemos]

When merging multiples apis (e.g. GitHub and Yelp), instead of generating this schema:

{
    getRepositoryById(id: String!),
    # ...otherGitHubQueries,
    searchPlaceByName(place: String!)
    # ...otherYelpQueries,
    myCustomQuery,
}

I'd prefer to be able to generate this:

{
    github: {
        getRepositoryById(id: String!),
        # ...otherGitHubQueries,
        myCustomGitHubQuery,
    yelp: {
        searchPlaceByName(place: String!),
        # ...otherYelpQueries,
        myCustomYelpQuery,
    },
    myProjectNameHere: {
        # ...myCustomQueries,
    }
}

Is that possible or planned?
Thank you.

• Related Stack Overflow question
• My current basic hack (Not using mergeSchemas, so doesn't handle conflicts etc)

[freiksenet]

We want to add namespacing utilities so that one can namespace stuff this way before merging. You can also filter the query after mergingSchemas, through eg https://github.com/graphcool/graphql-transform-schema.

[lifeiscontent]

@freiksenet any idea when this namespacing functionality will be finished? The project I'm working on really needs this kind of feature.

[flippidippi]

I think this is super important when using an in house schema and stitching to a schema that can change often, like GraphCMS. Instead of having to deal with multiple graphql endpoints or making sure the two schemas don't collide, we could easily do something like the following:

query {
  user {
    id
  }
  cms {
    pages {
      id
      title
    }
  }
}

where all of our often changing CMS schema is namespaced safely and won't interfere with our own schema.

[brunolemos]

I believe this is now possible with the new graphql-tools 3.0!
Does anyone have an example?

https://dev-blog.apollodata.com/the-next-generation-of-schema-stitching-2716b3b259c0

[terion-name]

Such a requested (and obvious) feature and no receipt yet ((

[stubailo]

This is a great idea! I think it's just a matter of implementing the right transform and making it easy to use/documented.

Anyone want to help with that?

[terion-name]

Currently I have an implementation that makes this by renaming types in remote schemas and constructing a new schema with service-specific fields, that have resolvers that delegate queries to corresponding remote schemas. I feel that my implementation is very rough and not very efficient, but the concept is something like this:

1. Collect remote executable schemas
2. Transform them be prefixing types (including root types) to prevent naming conflicts
3. Based on all their data construct a new schema with root fields and "service" fields in them, each of which has a resolver, that simply delegates queries to corresponding remote schemas

[Atomox]

I honestly feel that renaming types (as documented in 3.0) doesn't go far enough to resolve this issue for larger datasets.

If you are using GraphQL as a proxy to host many remote APIs under a single server, then merging upwards of a dozen or more remote schemas will get messy, particularly when there are multiple root-level nodes on each schema. Adding a root stub where a remote schema can be attached is much cleaner and more scalable than simply prefixing types with a schema-specific value.

Has anyone been able to do this successfully?

[yaacovCR]

WrapType transform can be used on the root type to namespace. Also see the Gatsby transforms that achieve this.
Folded into v5 roadmap #1306, which merges improvements from graphql-tools-fork, including WrapType.