graphql-wg VS graphql-go-tools

I'm using the Example from the DeferStream RFC

The client-side tree as proposed by other posters is what I would do in GraphQL currently; but I did want to mention the Struct RFC which may or may not address this problem depending on if your department/etc link to other GraphQL types you might want to query that should not be represented as structs.

Every aspect of languages and specifications are created with context of an end user human. The specification is a project by the Joint Development Foundation, with a current Working Group charter that includes the IP policy governing all working group deliverables (i.e. new features, changes of spec, source code, and datasets, etc). To join the Working Group there are details for membership and details in the agreement for joining the efforts of the group.

GraphQL Foundation maintains specification http://spec.graphql.org/, documentation, tools and vendor-neutral events. GraphQL Working Group (WG) manage & - maintain specification. https://github.com/graphql/graphql-wg

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