Support schema stitching #9
Assignees
Labels
enhancement
New feature or request
Comments
stuebingerb
added a commit
that referenced
this issue
Feb 3, 2025
This adds first support for schema stitching without aiming for full feature compatibility. And while I have a pretty extensive internal use case, schema stitching is still to be considered experimental and subject to change as needed. Schema stitching is a way to combine multiple GraphQL schemas under a single endpoint, so that clients can request data from different APIs in a single query. It also allows to add links between these schemas to e.g., automatically resolve references to actual types. This first implementation was made with the following goals/limitations in mind: - I tried to avoid interfering with existing code and to stick to existing architecture where possible - I tried to avoid introducing new dependencies for existing users of the library; in particular, kgraphql core should not get any ktor specific dependencies - I tried to have the stitching API as lean as possible - I focused on the non-experimental `ParallelRequestExecutor` first Over the course of implementing schema stitching, several bugs were resolved on the way but schema stitching is currently still impacted by some major issues like incomplete error handling (#114) that need to be addressed separately. Resolves #9
stuebingerb
added a commit
that referenced
this issue
Feb 7, 2025
This adds first support for schema stitching without aiming for full feature compatibility. And while I have a pretty extensive internal use case, schema stitching is still to be considered experimental and subject to change as needed. Schema stitching is a way to combine multiple GraphQL schemas under a single endpoint, so that clients can request data from different APIs in a single query. It also allows to add links between these schemas to e.g., automatically resolve references to actual types. This first implementation was made with the following goals/limitations in mind: - I tried to avoid interfering with existing code and to stick to existing architecture where possible - I tried to avoid introducing new dependencies for existing users of the library; in particular, kgraphql core should not get any ktor specific dependencies - I tried to have the stitching API as lean as possible - I focused on the non-experimental `ParallelRequestExecutor` first Over the course of implementing schema stitching, several bugs were resolved on the way but schema stitching is currently still impacted by some major issues like incomplete error handling (#114) that need to be addressed separately. Resolves #9
stuebingerb
added a commit
that referenced
this issue
Feb 7, 2025
This adds first support for schema stitching without aiming for full feature compatibility. And while I have a pretty extensive internal use case, schema stitching is still to be considered experimental and subject to change as needed. Schema stitching is a way to combine multiple GraphQL schemas under a single endpoint, so that clients can request data from different APIs in a single query. It also allows to add links between these schemas to e.g., automatically resolve references to actual types. This first implementation was made with the following goals/limitations in mind: - I tried to avoid interfering with existing code and to stick to existing architecture where possible - I tried to avoid introducing new dependencies for existing users of the library; in particular, kgraphql core should not get any ktor specific dependencies - I tried to have the stitching API as lean as possible - I focused on the non-experimental `ParallelRequestExecutor` first Over the course of implementing schema stitching, several bugs were resolved on the way but schema stitching is currently still impacted by some major issues like incomplete error handling (#114) that need to be addressed separately. Resolves #9
stuebingerb
added a commit
that referenced
this issue
Feb 7, 2025
This adds first support for schema stitching without aiming for full feature compatibility. And while I have a pretty extensive internal use case, schema stitching is still to be considered experimental and subject to change as needed. Schema stitching is a way to combine multiple GraphQL schemas under a single endpoint, so that clients can request data from different APIs in a single query. It also allows to add links between these schemas to e.g., automatically resolve references to actual types. This first implementation was made with the following goals/limitations in mind: - I tried to avoid interfering with existing code and to stick to existing architecture where possible - I tried to avoid introducing new dependencies for existing users of the library; in particular, kgraphql core should not get any ktor specific dependencies - I tried to have the stitching API as lean as possible - I focused on the non-experimental `ParallelRequestExecutor` first Over the course of implementing schema stitching, several bugs were resolved on the way but schema stitching is currently still impacted by some major issues like incomplete error handling (#114) that need to be addressed separately. Resolves #9
stuebingerb
added a commit
that referenced
this issue
Feb 7, 2025
This adds first support for schema stitching without aiming for full feature compatibility. And while I have a pretty extensive internal use case, schema stitching is still to be considered experimental and subject to change as needed. Schema stitching is a way to combine multiple GraphQL schemas under a single endpoint, so that clients can request data from different APIs in a single query. It also allows to add links between these schemas to e.g., automatically resolve references to actual types. This first implementation was made with the following goals/limitations in mind: - I tried to avoid interfering with existing code and to stick to existing architecture where possible - I tried to avoid introducing new dependencies for existing users of the library; in particular, kgraphql core should not get any ktor specific dependencies - I tried to have the stitching API as lean as possible - I focused on the non-experimental `ParallelRequestExecutor` first Over the course of implementing schema stitching, several bugs were resolved on the way but schema stitching is currently still impacted by some major issues like incomplete error handling (#114) that need to be addressed separately. Resolves #9
stuebingerb
added a commit
that referenced
this issue
Feb 7, 2025
This adds first support for schema stitching without aiming for full feature compatibility. And while I have a pretty extensive internal use case, schema stitching is still to be considered experimental and subject to change as needed. Schema stitching is a way to combine multiple GraphQL schemas under a single endpoint, so that clients can request data from different APIs in a single query. It also allows to add links between these schemas to e.g., automatically resolve references to actual types. This first implementation was made with the following goals/limitations in mind: - I tried to avoid interfering with existing code and to stick to existing architecture where possible - I tried to avoid introducing new dependencies for existing users of the library; in particular, kgraphql core should not get any ktor specific dependencies - I tried to have the stitching API as lean as possible - I focused on the non-experimental `ParallelRequestExecutor` first Over the course of implementing schema stitching, several bugs were resolved on the way but schema stitching is currently still impacted by some major issues like incomplete error handling (#114) that need to be addressed separately. Resolves #9
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Support schema stitching as an easy way to combine different sub schemas.
While federation seems to be the current hot thing, we currently have a use case for replacing atlassian/graphql-braid, which seems to have become completely unmaintained. Also, federation seems to require changes in the underlying model classes which may not be easily possible when those classes are auto-generated.
cf. https://www.apollographql.com/blog/graphql-schema-stitching
The text was updated successfully, but these errors were encountered: