Building a high performance JSON parser

Re:Building a high performance JSON parser by jensneuse on Sunday November 05, 2023 @11:39AM (#38152704)

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

[ Parent | on HN ]

Re:Building a high performance JSON parser by markl42 on Sunday November 05, 2023 @11:49AM (#38152832)

How big of an issue is this for GQL servers where all queries are known ahead of time (allowlist) - i.e. you can cache/memorize the ast parsing and this is only a perf issue for a few minutes after the container starts up

Or does this bite us in other ways too?

[ Parent | on HN ]

Re:Building a high performance JSON parser by jensneuse on Sunday November 05, 2023 @11:56AM (#38152911)

I build GraphQL API gateways / Routers for 5+ years now. It would be nice if trusted Documents or persisted operations were the default, but the reality is that a lot of people want to open up their GraphQL to the public. For that reason we've build a fast parser, validator, normalizer and many other things to support these use cases.

[ Parent | on HN ]

Re:Building a high performance JSON parser by romshark on Monday November 06, 2023 @03:45AM (#38160137)

You might also want to check out this abomination of mine: https://github.com/graph-guard/gqlscan

I've held a talk about this, unfortunately wasn't recorded. I've tried to squeeze as much out of Go as I could and I've went crazy doing that :D

[ Parent | on HN ]

Re:Building a high performance JSON parser by jensneuse on Monday November 06, 2023 @04:04PM (#38168993)

It's a bit verbose.

[ Parent | on HN ]