Giant schema codegen when using Relay GraphQL Global Object Identification Specification (Node interface)

[jimisaacs]

Summary

Apologies if this was addressed somehow but I can't seem to find an issue. It was most likely something raised off GitHub, not something addressed that I can find.

The issue which continues to plague us is that our supergraph uses the Relay "GraphQL Global Object Identification Specification". Because of this, our schema generated code is becoming less and less manageable by the day. Every new type that adheres to the Node interface, which is basically every entity type in the federation spec, gets generated schema types in the client, regardless of whether they are actually used in an operation/fragment.

Version

1.0.7

Steps to reproduce the behavior

Make a query to a graph that utilizes the Relay GraphQL Global Object Identification Specification, i.e. GetSomeTypeThatImplementsNode.graphql:

query GetSomeTypeThatImplementsNode($id: ID!) {
	node(id: $id) {
		id
		... on SomeTypeThatImplementsNode {
			someField
		}
	}
}

The expectation is that only the types needed to fulfill this query, i.e. Query and SomeTypeThatImplementsNode, should be generated. Not every type in the graph that implements Node. To make this work you'll need a schema that looks something like this, schema.graphqls:

interface Node {
	id: ID!
}

type Foo implements Node {
	id: ID!
}

type Bar implements Node {
	id: ID!
}

type SomeTypeThatImplementsNode implements Node {
	id: ID!
	someField: String
}

type Query {
	node(id: ID!): Node
}

So as you can see, considering the above query, I would NOT expect there to be anything generated for Foo and Bar, but I would expect types to be generated for SomeTypeThatImplementsNode.

Logs

No response

Anything else?

See the files I've included in the attached ReducedCase.zip archive
ReducedCase.zip

[calvincestari]

I'm pretty sure had an issue for this but can't seem to find it yet, I'll keep digging. @AnthonyMDev - does this ring any bells?

[AnthonyMDev]

I don't see an issue for it either, but it is something we are aware of and want to fix. I know you and I have chatted about this specific issue in the past @jimisaacs. While we somehow didn't have a GitHub issue for this yet, it is the focus of this roadmap item.

Thanks for officially making an issue for this one @jimisaacs.

[jimisaacs]

Yeah, I do vaguely remember a discussion 🤔, but nice to see it officially on the milestone! Thank you!

[jimisaacs]

The reduced case zip I just added here also applies to this issue #2969 (comment)

[jimisaacs]

Would like to understand the new date for this, as the last time I communicated this to my team, it was July, 1.3.

[jimisaacs]

@AnthonyMDev @calvincestari @BobaFetters any word on this by chance? The more we expand, the more of an issue this is becoming.

[AnthonyMDev]

Yeah, I'm sorry this got pushed back so much. I'm actively working on getting support for disabling fragment field merging finished. I anticipate I'll finally have that done in November. With the holidays in December, my goal is to develop a solution for this issue in January.

[tmgsca]

Hi @AnthonyMDev, any news on this item? It's been a while since the last update. We have a huge schema and we need only a tiny fraction of it in our use case. We're getting hit with 1k+ files when performing codegen for just a few queries 😅

[AnthonyMDev]

Honestly not sure still. We've been working through our roadmap, and this is still on it, but a lot of features we've approached have been more complicated than anticipated. I will definitely update this issue as soon as we have anything to update you with.

But I totally understand your pain here. We want to improve on this. The current state of this is not what we want to be seeing.