participle VS graphql-go-tools

I know of tools like Kaitai that do essentially what I want, just curious about my options. I guess something like https://github.com/alecthomas/participle could work to parse the format, then I'd have to generate code based on the parsed data or something

This one was recommended in an older thread and looks like it's still actively developed: https://github.com/alecthomas/participle

I like participle: https://github.com/alecthomas/participle. It's pretty easy to get something working if it fits your use case.

Like the other commenters said, it's probably best to just split the string and go through it manually. If you need a real parser, check out: https://github.com/alecthomas/participle

I used https://github.com/alecthomas/participle to implement a custom DSL for some projects. I think there's also an SQL example in the repository. After the parsing is solved it's 'only' about doing something useful with the query but at least you've full control of all aspects, which features you'd like to support and so on.

I made a domain specific language using https://github.com/alecthomas/participle what I found interesting is the grammar defined in structure annotations. After the parser runs, you get a fully instantiated structure based upon the input. I then invoke structure methods to do the work described in the DSL.

Maybe instead of regex you could look into other options.

Shameless plug, but have you compared your Rust parser to https://github.com/alecthomas/participle?

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