You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The docs say Schema Stitching is deprecated in favor of Apollo Federation.
Of course, Federation can replace Schema Stitching in general.
However, there are some cases only Schema Stitching makes sense.
For example, sometimes we can't directly develop and change our microservices' GraphQL schema even if we want to use them with Apollo Federation. Some code-first frameworks like nexus or type-graphql do not support GraphQL directive. Some GraphQL engines like Hasura or Postgraphile are same as well. In other cases, we might want to incorporate 3rd party services'(e.g Stripe) GraphQL, which is of course not federation-spec-compliant. In these cases, one of the good solutions is using Schema Stitching and Schema Transform. There's even a package named graphql-transform-federation for this purpose.
What's more, even when only a monolithic service is enough, Schema Stitching can be used to override some queries, mutations or subscriptions of existing monolithic service, if we can't directly fix the service schema (e.g. code-first frameworks or engines like Hasura).
Sometimes, even clients want to transform schema provided by a server. Client developers might want to do this for their convenience. In this case as well, Schema Stitching is useful.
In conclusion, Apollo Federation does not cover every use case of Schema Stitching. Thus, as they are different, I think Schema Stitching should not be deprecated.
The text was updated successfully, but these errors were encountered:
Type merging from remote schemas is now supported. In combination with transformations that allow you to rename and restructure remote types and fields even for graphs not under your control, schema stitching is alive and well, just not under Apollo auspices. Probably the best thing for the community would be for them to let control of this repository head out to the community so that schema stitching and Federation can really each have a shot at addressing community needs.
Why just not taking over graphql-tools-fork fixes to graphql-tools? Really hard for me to understand, just to say its deprecated. Seems to me, like a sad story.
The docs say Schema Stitching is deprecated in favor of Apollo Federation.
Of course, Federation can replace Schema Stitching in general.
However, there are some cases only Schema Stitching makes sense.
For example, sometimes we can't directly develop and change our microservices' GraphQL schema even if we want to use them with Apollo Federation. Some code-first frameworks like nexus or type-graphql do not support GraphQL directive. Some GraphQL engines like Hasura or Postgraphile are same as well. In other cases, we might want to incorporate 3rd party services'(e.g Stripe) GraphQL, which is of course not federation-spec-compliant. In these cases, one of the good solutions is using Schema Stitching and Schema Transform. There's even a package named graphql-transform-federation for this purpose.
What's more, even when only a monolithic service is enough, Schema Stitching can be used to override some queries, mutations or subscriptions of existing monolithic service, if we can't directly fix the service schema (e.g. code-first frameworks or engines like Hasura).
Sometimes, even clients want to transform schema provided by a server. Client developers might want to do this for their convenience. In this case as well, Schema Stitching is useful.
In conclusion, Apollo Federation does not cover every use case of Schema Stitching. Thus, as they are different, I think Schema Stitching should not be deprecated.
The text was updated successfully, but these errors were encountered: