schema-stitching-handbook VS graphql-go-tools

“Shifting this configuration out of the gateway makes subschemas autonomous, and allows them to push their own configuration up to the gateway—enabling more sophisticated schema releases.” — schema stitching handbook

Also see @graphql-tools/schema-stitching [0] and its handbook [1] with examples. Note the stitching gateway approach is slightly different than Apollo Federation. We are (lightly) using schema-stitching and happy with it so far – but haven't pushed it much yet.

[0] https://www.graphql-tools.com/docs/schema-stitching/stitch-c...

[1] https://github.com/gmac/schema-stitching-handbook

Federation Services - Stitching Handbook

Whether you’re planning a new API project, looking to migrate an existing one, or curious of alternatives for your current distributed GraphQL architecture, 2021 is the year to give Schema Stitching a fresh look. Read the new documentation, review the handbook, watch the video series, or join us for a conversation to learn about the exciting progress that was made last year.

If you're interested in the full implementation of the resolver, you can find it on GitHub.

https://github.com/wundergraph/graphql-go-tools/blob/dcd50bd...

Each iteration of this benchmark measures the aggregate performance of

- 1x ParseObject

- 3x AppendObject

- 3x MergeNodesWithPath

- 1x PrintNode

- 1x bytes.Equal comparison of two byte slices

The benchmark isn't actually benchmarking MergeNodesWithPath, it's benchmarking a much larger composite operation, which includes (multiple) calls to MergeNodesWithPath but also all of the above listed calls as well. If you want to measure MergeNodesWithPath, you would need to have each iteration of the loop do a single MergeNodesWithPath call, on the same JSON method receiver, and with the same input parameters.

You can check out the full code including tests and benchmarks on GitHub. It's part of graphql-go-tools, the GraphQL Router / API Gateway framework we've been working on for the last couple of years. It's the "Engine" that powers the Cosmo Router.

I've taken a very similar approach and built a GraphQL tokenizer and parser (amongst many other things) that's also zero memory allocations and quite fast. In case you'd like to check out the code: https://github.com/wundergraph/graphql-go-tools

The Cosmo Router is powered by graphql-go-tools, a highly mature and optimized GraphQL engine (MIT License) that is the fastest and most reliable implementation for Federation V1. The Cosmo Router builds on it with its own optimizations.

Cosmo Router is built on top of graphql-go-tools, a high performance GraphQL engine written in Go.

For more than five years, we've been involved in the GraphQL ecosystem, building tools and services around GraphQL, like [graphql-go-tools (https://github.com/wundergraph/graphql-go-tools), a library to build GraphQL Gateways in Go.

I've been working on this library for more than 5 years now and it has been a great success. Almost 3 years ago, I started adding support for Apollo Federation to graphql-go-tools. As excited as I was about the idea of Federation, the community was not ready for it yet. I've added support for Subscriptions years ago, but demand for it was very low, so my focus shifted to solving other problems.

Check us out: https://github.com/wundergraph/graphql-go-tools