On GraphQL Schema Stitching & API Gatewa...

[magic lava]

(🍞crumb: found while researching namespacing state-of-the-art in GraphQL via https://github.com/graphql/graphql-spec/issues/163#issuecomment-440321567)

[tulip gale]

Yeah we looked quite a bit into various approaches (things like this, federation, etc.) back in the cloak days. From what I can tell from a very quick skim of the blog post, it's pretty much where we landed I think (?)

The part I screenshot seems to be pretty much what we do. And IIUC they are suggesting that conflict resolution be handled at the gateway, which is essentially our idea of automatically namespacing conflicting objects/fields by prefixing w/ Module name when needed.

[magic lava]

Yeah - my takeaway is that we're basically implementing "hard mode" haha, with the added sprinkle of caching query results (to the maximum extent possible) and running everything via containers + our somewhat ad-hoc calling convention instead of gRPC/REST/whatever

My rough plan for namespacing:

1. Prefix exposed types with ModuleName__, which has a lot of prior art in the linked GH issue, and is also really the only option we have anyway. It's a safe choice too since we normalize module names to exclude underscores.
2. Possibly allow the consumer side to set an alias name instead, which would rename both the Query entrypoint and the type prefixes.

The second one is unlikely to be important for resolving conflicts in practice; seems unlikely that anyone would directly depend on two modules with the same name. But it feels nice to have it as an escape hatch, and setting aliases might be a good idea too if it turns out that generally people write predictable APIs but you happen to want to switch between module implementations or something.

[tulip gale]

Yeah the main remaining question mark in my head has been whether we always do the prefixing or we only do it when we detect a conflict

Either works, it's a tradeoff of consistency vs. verbosity by default

I think

[magic lava]

Yeah - my preference is to just always do it, since I think you're not likely to actually see it all that often. They never show up in GraphQL queries themselves, at least. It'd show up in code if you pass a module-returned type to a function in Go, though.

I could be swayed either way, I'm also betting conflicts will be rare

So if they're actually rare it'd be nice to have it pretty-by-default

[tulip gale]

Oh sure, so I guess there's also a distinction to be made between the graphql schema and the codegen. I agree it probably makes sense to always do it for the raw graphql schema. The question remaining would be whether to try to make codegen methods/objects as succinct as possible by only including the namespace part when necessary for de-confliction