Support for schema transformations

[ghostdogpr]

Something similar to this Apollo-server feature: https://www.apollographql.com/docs/apollo-server/features/schema-transforms/

The current problem is that Caliban currently stores runtime schema into this object:

case class Operation[-R](opType: __Type, plan: Step[R])

__Type matches the graphql type used by introspection, while Step is a description of a computation, that might require running some effects to get the underlying steps. If you want to remove or rename a field, it needs to be applied in both structures, which isn't really possible in the case of Step.

We need to think of a different way of encoding the resolver to support this feature. Maybe Step is generated too early and there should be something in between.

[ghostdogpr]

An alternative approach could be to introduce a sealed trait Transformation with a list of pre-identified cases (which is what is done in Apollo Server), and apply the changes ourselves case by case on both __Type (initially) and Step (during execution). Only ObjectStep might be affected because it's the only one that contains type names and a list of fields.

I'll sketch this with a simple transformation like renaming types.

[ghostdogpr]

Did a proof of concept that seems OK with the following API:

api
  .transform(Transformer.RenameType(t => if (t.contains("Queries")) Some("QueriesYOLO") else None))
  .transform(Transformer.FilterType(t => t != "character"))

[DGolubets]

Any progress on this?
Seems to be a handy feature when using federation.

[ghostdogpr]

Any progress on this? Seems to be a handy feature when using federation.

No one manifested interest so far so I didn't go further, but I could potentially resurrect my old prototype. I can't find the Apollo docs anymore but found this https://the-guild.dev/graphql/stitching/docs/transforms

[DGolubets]

Makes me wonder how many people actually use Apollo federation..

I just finished merging our APIs into a super-graph for use with Apollo Router. I was able to sort the conflicts by making some types sharable and wrapping queries\mutations so far. Nevertheless I got uneasy feeling that every time I modify a sub-graph service I might introduce a new conflict.

With your proposed feature I could just add a prefix to every type name.

[frekw]

@DGolubets we use Apollo federation. We run schema validation vs the supergraph in CI to avoid introducing conflicts / breaking changes (via the rover cli tool).

It's also very possible to share types between subgraphs, esp. so with federation v2.