What is the future of stitching in graphql-mesh?

[Davenporten]

This is mostly out of curiosity, but I use some stitching in my graphql-mesh instance and when I run it I get the message that stitching will be disabled by default in a future release. I guess my question is why was this decision made? Is the idea that we should/need to move away from stitching? Is it just an off by default sort of thing? This article is now a few months old, but stitching was the preferred method for the writer's team. Maybe I'm just not understanding what the message is about or the general projection of graphql, but any insight into would be appreciated.

[ardatan]

I think you're referring the old warning that says stitching resolvers will be disabled by default in the future which was actually misleading and confusing. Sorry for that. Mesh is superset of stitching. That message used to be printed by GraphQL Codegen and it refers to completely different stuff.

Just ignore that message in the console :) It should be gone now anyway,if not just ignore because stitching is what Mesh heavily relies on right now and it will be always like that in the future as well. So no worries about that situation.

You can keep using stitching as-is right now. Mesh tries to give you the best development experience with its declarative and programmatic API, and this will be like that in the future :)

Also stitching is now able to consume Relay, Federated and regular GraphQL services so it is a kind of generic gateway approach in GraphQL ecosystem right now.

https://the-guild.dev/blog/graphql-tools-v8