Hey guys, a quick question - is there any possibil...
# graphql-kotlin
Hey guys, a quick question - is there any possibility to host two different schema in the same graphql-kotlin service (specifically in springboot)? I.e, one schema would live on
endpoint and other schema would live on
endpoint. Is something like this possible? If yes, can you give me some pointers how to do this?
never tried it but don't see why not, you would need to • create two GraphQL schemas (if you partition by packages should be rather easy) • initialize engine per schema • invoke target engine per route
its doable but unsure how much value you would get out of it
one of the best things about GraphQL is the ability to expose single endpoint for all your client needs
I understand that. The whole point is to be able to host an older schema built previously on the same service together with incompatible schema (with conflicts in types as there are no namespaces in GraphQL).
But from what I'm gathering it should be technically possible. I guess I'm going to have more questions as I'm going to prototype this. Thanks for the help so far.
re: namespaces -> you certainly can prefix types with whatever you want
i personally wouldn't recommend the 2 schema approach as it implies client change to switch from one endpoint to another
I'd rather add new queries/mutations to existing schema
but I guess it all depends on the use cases
Well, this is where the problem is - the schemas have conflicts when it comes to actual types (same fields have different types). Think about this as an exercise of consolidating two graphql services into one without too many changes on the client.
(and because of the conflicts, federation is also out of question)
you could always create new types 🙂 yeah naming might be suboptimal but for clients it shouldnt matter
well, creating new types means updating clients, which we want to avoid as much as possible. The routing change can be done completely transparently for the clients (they still will talk to the old endpoint, but the traffic will go to the new service with
If clients are going to have to migrate anyway to a new endpoint, why not run the new schema on a new deployed service? This would better help the migration