Is there a way to not expose relationship ids when stitching schemas?

[dclucas]

Both the basic and complex examples rely on exposing relationship ids in type definitions (see Chirp.authorId below), so they can later be used by the resolver to hydrate the full node.

    type Chirp {
      id: ID!
      text: String
      authorId: ID!
    }

That field becomes unnecessary after hydration and looks like an implementation leak (in a non-stitched API, only author.id would be visible externally).

I tried using an internal representation (which does not make it to the resolvers when mergeSchemas runs them, as well as using a package such as graphql-transform-schema to remove the field (it does not remove fields from the schema yet) and have not run out of ideas (besides ditching mergeSchemas altogether).

Is there a way to pull this off and, if there isn't, is that something you would eventually support?

[kbrandwijk]

What I have done is add a transformSchema step after the mergeSchemas, which removes those fields from the resulting schema. Strangely enough, the delegate keeps working when you do it in that order.

[dclucas]

Hm, perhaps I'm missing something, but my transformSchema made my delegates stop working (hydrated object does not show anymore). Besides, the relationship ids (authorId in the example) still show in the schema.

@kbrandwijk can you share some sample code?

[bialesdaniel]

I have this same question I get cant seem to const { tranformSchema}=require('graphql-tools') transformSchema says its undefined.

@kbrandwijk Did you have some example I can follow?

[yaacovCR]

You can use FilterObjectFields to accomplish this, but probably you would want to use type merging. Folded into v5 roadmap #1306, which merges improvements from graphql-tools-fork, including FilterObjectFields.