How to deal with @extends type and supergraph variants

Help
1

I am investigating a case where my deployed product might come in multiple configurations, lets say A + B + C and A + C. A, B and C each enrich each other entities.
In this case ABC deployment works, but AC deployment would fail with composition validation "no parent type was found for a type SomeBtype (key …).

Another approach to this, that doesnt make the schema complain is to use the sharable types, but it comes with a reverse issue, where tis sharable type has to be maintained in every subgraph.

I wanted to ask if there is a way to define a type as “will be resolved by another subgraph” or another, more graceful solution to have an “optional” federated service.

2

Hey @simas_j , I think you should take a look at Apollo Federation v2 which removes the need to have @extends on your entities. This enables a model where multiple subgraphs can have multiple entity representations.

We have some docs on how extends can be removed in Fed 2. I would be happy to talk about this more on a stream and I could use a tool to help design the schema with you. If that sounds helpful, you can join me in our Discord and ping me (@watson)!

3

That indeed sounds very helpful! I’ll reach out to you next week!

1 Like