Documentation on how to use `LookAhead*` features.

[jearbear]

I saw that support for look ahead functionality was added in #136, but I'm a bit confused as to how to use it since it's not at all documented. I see they are exported here, but attempting to use them throws a compiler error:

error[E0432]: unresolved import `juniper::LookAheadArgument`
 --> src/schema.rs:4:5
  |
4 | use juniper::LookAheadArgument;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `LookAheadArgument` in the root
warning: unused import: `juniper::LookAheadArgument`
 --> src/schema.rs:4:5
  |
4 | use juniper::LookAheadArgument;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(unused_imports)] on by default

Any help here would be greatly appreciated, thanks!

[LegNeato]

/cc @weiznich

[weiznich]

I think the released version on crates.io does not contain that feature yet. So to make this work you need to dependent directly on the git version.

[LegNeato]

Oh, yes, sorry...I should have read closer. You need to use master/git until a new release (#210). Sadly I can't do a release because I don't have permissions and @theduke and @mhallin haven't been around lately.

It would still be good to get some docs on how to actually use it in the book so keeping this open.

[jearbear]

Ah I see, I suspected as much, thanks!

Out of curiosity are these the main way people are recommended to tackle the N+1 query problem? I find that even in the most simple case it gets pretty chatty and haven't been able to find much guidance on that in particular. (Well other than using dataloader-rs, which I believe requires async support to work?)

[weiznich]

There are basically 2 ways to solve the N+1 query problem:

• Using something like dataloader
• Using a lookahead mechanism to inspect the whole query

The first solution won't work with juniper as implemented currently, because it needs async support, so this leaves currently only the lookahead solution.

(Btw: If you are trying to integrate juniper with a relational database checkout wundergraph)

[LegNeato]

This discussion may also be of use:

#124

[jearbear]

Yup that's what alerted me to wundergraph's existence 😄. During my first pass through I found it a bit hard to grok, but I haven't set some time aside to really dig into it so I'll do that and report back.

[weiznich]

I guess if we define these types in juniper consumers of the lib aren't forced to use them. They could just use the default Int and Float types and it would be as if they were never added.

Writing documentation is a big point of what's left before wundergraph will be released officially. For now the two examples are the only documentation that exists beside the code.

[kestred]

@weiznich: While it isn't as complete as facebook's GraphQL dataloader, at work we've got a pretty decent to solution to handle batching of nested objects.

---

Our solution to handle nested objects is to wrap our RealObject in a new struct:

struct BatchedObject { id: Id, batch: Rc<MultipleObjectDataWithLazyRefCells> }

and then load the data out of the Rc in the field blah() -> { self.batch.get_blah(&self.id) }.

Here is a gist with part of the bits you might use https://gist.github.com/kestred/6cac1149b072228bd398e2c60e3c7871.

The gist example is fairly unusual, because all of our typical batching has been replaced a graphql_batch! macro which hides most of the noise.

[Darkeye9]

Would anyone, please, mind to show a basic example of how this works? I am not a Rust begginer, but neither a pro... And I could not get any cue from the wundergraph project :(

[weiznich]

The basic idea is quite simple:
You call Executor::look_ahead() to get a LookAheadSelection. That's basically just a structure that represents the whole request. After that you can use the methods provided by LookAheadMethods to traverse the request tree. How you do that and what you do with the result depends quite a lot on your exact use case. For wundergraph this is used to construct sql queries.

@LegNeato I think this could be closed because the documentation was released.