Is there a way to turn the AST back into a graphql query string? about parser HOT 14 CLOSED

@listepo-alterpost I'm not a C++ developer and frankly I'm not sure I would want to support that myself. If you think you can get it working I would be interested in seeing it.

from parser.

I've tested a native adapter vs managed implementation in my fork (https://github.com/DSilence/parser).
Looks like managed implementation is significantly faster on .net core 2.1.

BenchmarkDotNet=v0.11.1, OS=Windows 10.0.17763
Intel Core i7-7700HQ CPU 2.80GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=2.1.302
  [Host]     : .NET Core 2.1.4 (CoreCLR 4.6.26814.03, CoreFX 4.6.26814.02), 64bit RyuJIT
  DefaultJob : .NET Core 2.1.4 (CoreCLR 4.6.26814.03, CoreFX 4.6.26814.02), 64bit RyuJIT

I've used windows port from this PR graphql/libgraphqlparser#67.
Keep in mind that I also don't construct a managed wrapper around the resulting AST (I only retrieve a ponter to it in the code). This will result in additional slowdowns.
I'm definitely not an expert of native code interop, so it might be that the interop code could be improved significantly.

from parser.

I've used https://github.com/lexxmark/winflexbison, as the PR author suggested. Hopefully I will have some time to try running the whole thing on linux, since windows is not officially supported by libgraphqlparser yet, which may very well be the cause of the slowdowns.
I also have some ideas for managed implementation improvements (using more structs instead of classes, span + slice instead of strings and substrings, not throwing parsing exceptions but storing and gathering them) which I think will be interesting to throw into that competition.

from parser.

There is an AstPrinter in the Core project, though there isn't one for this parser. For historical reasons, the AST in this project is slightly different than the Core project. The Core project currently does a conversion from this AST to the AST it understands.

from parser.

@joemcbride way not use original parser libgraphqlparser ?

from parser.

@joemcbride and @listepo-alterpost It would be nice to use that, so we can port or link that lib and let the C++ developers of graphQL build the parser while we only add the links with .NET

from parser.

Hi, might be a bit overdue, but recently I needed to turn GraphQL AST back to query as well so I implemented a printer class doing exactly that.

PR here: #20

@joemcbride Could you have a peek if there is something you'd like to add or remove for the sake of https://github.com/graphql-dotnet/graphql-dotnet?

from parser.

@joemcbride and @listepo-alterpost about https://github.com/graphql/libgraphqlparser

There are some issues I have found:

PROS:

• Faster, really much faster.
• Official Implementation

CONS:

• Can only compiled in Linux or MacOS
• Requirement to generate the library for diferent RID (linux-arm, linux-x64, win-x86, win-x64, etc...)

My personal opinion:
Seems like we have a working implementation that doesn't require anything native, meaning that we don't care about the arch.
In order to be as standard as posible, just make an exact port of https://github.com/graphql/graphql-js/tree/master/src/language but in .NET so we can be official as possible

Edit:
We can make an experiment about how much the performace win is when using the C library

from parser.

Keeping a port up to date is an ongoing maintenance burden, and can lead to the death of a project ("sorry we aren't on the latest version").

Could the js version be called from .NET using JINT or similar?

from parser.

OTOH if there is a working implementation from @mkmarek , then we should just run with it. Might be worth making it a pluggable type so that other implementations could be used.

from parser.

Using JINT will cause some performace penalizations.
My impression is that part of the library is pretty stable, so tracking changes should be easy. I would like to ask for better split of the flow types so its more easy to track changes

from parser.

your code seems good in interop terms.
Just to check.

ibgraphqlparser is built with CMake. If a sufficiently-recent version of Flex and Bison are installed on your system, it will use them; otherwise, it will rely on the checked-in parser.tab.{c,h}pp and lexer.{h,cpp}.

Do yo compile that with Flex and Bison? Can you run the same benchmark on any Linux? (Just to have more information)

from parser.

I rewrote the managed lexer/parser to utilize span API (at least partially). Below are the results of running the benchmark on Ubuntu 18.04 (I've used Azure VM). I have installed the latest versions of Flex and Bison before running it.

BenchmarkDotNet=v0.11.1, OS=ubuntu 18.04
Intel Xeon CPU E5-2673 v4 2.30GHz, 1 CPU, 2 logical cores and 1 physical core
.NET Core SDK=2.1.403
  [Host]     : .NET Core 2.1.5 (CoreCLR 4.6.26919.02, CoreFX 4.6.26919.02), 64bit RyuJIT
  DefaultJob : .NET Core 2.1.5 (CoreCLR 4.6.26919.02, CoreFX 4.6.26919.02), 64bit RyuJIT

from parser.

Will be published in v8.

from parser.