How is gramps different from `graph-tools` schema stitching? about gramps--legacy HOT 5 CLOSED

I am of the persuasion that the primary goal of GrAMPS is to modularize your schema, allowing teams to work independently.

One byproduct of a more modular schema is the need to stitch between schemas. GrAMPS uses graphql-tools schema stitching to do so. The API to do so in GrAMPS is essentially identical to graphql-tools (because it is used under the hood)

If you already have two existing schemas and just need to stitch them, it would likely be simpler to just use graphql-tools directly. But if you're hoping to break a larger schema into smaller components, then GrAMPS is definitely worth taking a closer look at.

from gramps--legacy.

https://gramps.js.org/data-source/data-source-overview/

from gramps--legacy.

But all this can be done by simply schema stitching using graphql-tools can't it? Most of the listed benefits on that page are the same from https://www.apollographql.com/docs/graphql-tools/schema-stitching.html.

I think its worthy of clarification as an FAQ on the site.

I'm guessing that Gramps offers a more convenient API for merging or something like that.

The question I have is should I use Gramps or just use schema stitching with graphql-tools.

from gramps--legacy.

I think with GraphQL-tools you can only stitch schemas if they are exposed by GraphQL endpoints.

With GrAMPS you can stitch schemas from GrAMPS data sources without needing a GraphQL endpoint per source.

I could be wrong. Reading what @ecwyne had to say...

from gramps--legacy.

@ecwyne is right on the money here.

The goal of GrAMPS is to allow a large GraphQL codebase to be split into logical groupings. This is done so multiple teams can edit code that's exposed through a single endpoint without a complex review process or the risk of one team accidentally breaking another team's schema.

Modularity can work without schema stitching — the majority of IBM's GraphQL endpoints don't use stitching at all, but are all built as GrAMPS data sources.

The benefit of modularity is that the data sources can package their stitching logic together in the data source, which again helps keep things modular.

And as @idibidiart said, typically it's required to load a remote schema (though @kbrandwijk has done a lot of work to convert remote schemas to static ones at build time) for stitching, which adds overhead. Since GrAMPS data sources are installed as npm packages, there's no network overhead to assemble and stitch between them.

That being said, if you don't need modularity, then there's no difference between schema stitching in GrAMPS and schema stitching in graphql-tools; as @ecwyne said, GrAMPS is using graphql-tools under the hood to do it.

Hope that clears things up!

from gramps--legacy.