🔴 The Prisma Spectrum community is not officially managed by Prisma's support team any more. Please seek help on GitHub or on Slack instead. Learn more: https://spectrum.chat/prisma/general/where-and-how-to-best-seek-help-with-questions-problems~687a1b8f-8658-4df3-8849-ea5ab3503f28
Common issues with schema stitchingApril 17, 2019 at 12:38pm (Edited 5 months ago)
Schema stitching is an interesting concept but requires a lot of discipline from a team to implement it correctly and keeps room for shooting yourself in the foot. This post already does a great job of explaining the key shortcomings of a schema first approach. I just wanted to have a common place to list out most of the practical issues from the schema stitching ecosystem just to have a reference for evaluating schema stitching as a tool.
Stitching essentially adds more layers to your architecture and makes it difficult to pin point where something (error or some data transformation) happened in a layer unless you are very disciplined into tagging each layers response with some metadata. These layers and general architecture of schema stitching makes the following issues more pervasive:
Keeping schemas in sync across layers:
Alias furling/unfurling across layers
Note that some of the above issues are closed but not gracefully. Schema stitching still can be a good alternative to make a common layer of business splitting other GraphQL services like micro service but would require discipline like adding metadata for error propagation, avoiding name collisions by some sort of name spacing or conventions etc which makes it difficult to use that at scale.