Hey guys, a quick question - is there any possibility to host two different schema in the same graph...

# graphql-kotlin

[Martin Brehovsky]

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 /graphql endpoint and other schema would live on /other_graphql endpoint. Is something like this possible? If yes, can you give me some pointers how to do this?

[Dariusz Kuc]

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

[Dariusz Kuc]

its doable but unsure how much value you would get out of it

[Dariusz Kuc]

one of the best things about GraphQL is the ability to expose single endpoint for all your client needs

[Martin Brehovsky]

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).

[Martin Brehovsky]

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.

[Dariusz Kuc]

re: namespaces -> you certainly can prefix types with whatever you want

[Dariusz Kuc]

i personally wouldn't recommend the 2 schema approach as it implies client change to switch from one endpoint to another

[Dariusz Kuc]

I'd rather add new queries/mutations to existing schema

[Dariusz Kuc]

but I guess it all depends on the use cases

[Martin Brehovsky]

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.

[Martin Brehovsky]

(and because of the conflicts, federation is also out of question)

[Dariusz Kuc]

you could always create new types 🙂 yeah naming might be suboptimal but for clients it shouldnt matter

[Martin Brehovsky]

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 /other_graphql endpoint)

[Shane Myrick]

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