Are you still maintaining this project? about graphql-parser-php

[andheiberg]

I'm not aware if @dosten is still maintaining this.

I would be interested in discussing your project if you're willing. I work with a team that have invested considerable effort into GraphQL in PHP and would always love to share experience.

On a side note I did start playing with my own PHP extension https://github.com/andheiberg/graphql-parser-php-extension I believe I left in a semi finished state with some edge case errors. I haven't had an incentive to pick it up again though. You should consider that in practical usage caching the results of query parsing means that the efficiency of the query parsing is fairly unimportant. We've yet to open source our works for caching, but could be persuaded to do so if there was an interest for it.

[crisu83]

@andheiberg we actually decided to write the parser ourselves to ease the adaption of our library. I would definitely be interested in discussing this further with you.

[fubhy]

You should consider that in practical usage caching the results of query parsing means that the efficiency of the query parsing is fairly unimportant. We've yet to open source our works for caching, but could be persuaded to do so if there was an interest for it.

I disagree. Yes, there are quite a few scenarios in which query parsing performance becomes less relevant. Most importantly when using persisted queries in which case you definitely want to cache the pre-parse AND pre-validated query ASTs of the persisted queries. Unless however you actually are able to use persisted queries (which is not possible if you have a completely open API for instance), you need to parse all incoming queries. You can cache the results based on a hash of the query string, sure, but a single whitespace difference would cause a cache miss. Hence, at least for one of my use-cases, query string parsing is actually a considerable part of query execution (roughly 10%).

[andheiberg]

You can cache the results based on a hash of the query string, sure, but a single whitespace difference would cause a cache miss.

It's very possible to normalise queries to prevent this. Again we have an internal tool for this. If people are super interested we could look into open sourcing it.

[fubhy]

I am super interested. :)

[vladar]

Hence, at least for one of my use-cases, query string parsing is actually a considerable part of query execution (roughly 10%).

Have you tried using this C-based parser with webonyx's AST::fromArray. It has some overhead on top of a plain associative array, but it should perform much better than existing PHP-based parser anyway.