graphql-go-tools VS JSMN

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

Like how https://github.com/zserge/jsmn works. I thought it would be neat to have such as parser for https://github.com/vshymanskyy/muon

One more JSON implementation using this approach is https://github.com/zserge/jsmn.

Yep! I'm using JSMN (https://github.com/zserge/jsmn), which is a streaming parser that visits each token sequentially, so there's only one copy of each JSON response in memory. I also avoid allocating new intermediate memory whenever possible; for example, to unescape backslashes in the JSON strings, I use a destructive loop that moves the non-backslash characters forward in memory, and truncates the string by moving the null terminator earlier in the string. Not something I'd imagine doing in most environments today, but as you said, it saves a bit of space at the expense of CPU time :)

  void DestructivelyUnescapeStr(LPSTR lpInput) {

After reviewing several options, I’ve settled on plain old JSON. For parsing, I use https://github.com/zserge/jsmn. For serialization I use https://github.com/rdpoor/jems (disclaimer: I wrote the latter, but others use it as well).

As mentioned here, it appears that tiny-json is a parser, not a serializer. If you're looking for parsers, I've been very happy with jsmn.

Very small, 4-5 fields but I'm still going to write in binary because I'm trying to reduce dependencies and https://github.com/zserge/jsmn looks like good fit but jsmn only does parsing which I need for parsing some Oauth json data and config.json file. I will be able to dump the state struct in a state.bin file and read it later for comparing it with system time. Not having to write in text fits well for this particular use case. Benefits: Reduced dependencies and almost cost less decoding of the state struct(which the user will never see).

This is my very straight-forward implementation that came to be from the lack of JSON encoding in jsmn: