Christoph Herzog

@LegNeato I'm still rather negative on this due to the reasons stated above. We could put it into the book instead. Do you feel otherwise?

As mentioned by others, the possible approaches here are * datalaoder * using lookahead * uniper-eager-loading We should really add to the book, since it's a common stumbling block.

This is an example that works with the new object macro. THis should be added to the book and to the macro doc comment. ```rust pub struct DataStore; pub struct...

> which seems to be fine in my particular case Yeah it's fine in this case because the context is guaranteed to be alive for the duration of `execute`, but...

@tailhook I'll look over the code, but in principle, as long as the AST produced is decent and can easily be converted (without much cloning) I'd definitely be in favour....

@tailhook also, it's important to have great error reporting for parsing errors and to be able to map each ast node to the query location.

@tailhook all sounds great, I'll look over the code! Would you be interested in moving the parser into the `graphql-rust` organization? It would be cool to have all GraphQL related...

@Keats I haven't had time to look over the code. We will probably want to have a custom-tailored ast for Juniper. I'm perfectly fine with getting an AST from the...

IMO it's fine if we start from what's there and optimize later, especially if @tailhook is fine with moving the repo into the graphql-rust org. I also agree that the...

Some progress: https://github.com/graphql-rust/graphql-parser/pull/19