David Pedersen

I wonder if the relay additions could be a separate library built on top of juniper and not necessarily something that is built in 🤔

I guess that means someone can build a library crate for relay support?

Thanks for the bug report! Sounds like this should have been caught in the query validation phase. Does running [this](https://github.com/MHRA/products/tree/4b8712cb9f7b1b15d3f120db8792d4033586343e/medicines/api) to reproduce the bug require anything besides Rust? It would...

If you're interested in the lookahead approach you could consider [juniper-eager-loading](https://crates.io/crates/juniper-eager-loading) which handles all the boilerplate. We're using it in production at @tonsser and its been working well so far....

@MikailBag I maintain a complete example app. You can find it here https://github.com/davidpdrsn/graphql-app-example. It does use Diesel directly however.

It seems other graphql communities have something called "validations" that allow you to validate a query before even running it. Such as https://github.com/graphql-dotnet/graphql-dotnet/issues/766. That should probably be able to handle...

[From #324](https://github.com/graphql-rust/juniper/pull/324#issuecomment-469833278) > Is it a view of the schema one would reasonably expect juniper to handle? Or is it a nice-to-have that isn't intrinsic to how juniper does things....

They aren’t meant to do the same. FieldError::from is provided by From from std. It only requires that your type and be converted into a string. There is no way...

I don’t exactly remember how the conversion works but do you have to explicitly call “.into_field_error()”? Doesn’t the macro insert that call for you? I might be mistaking and on...

@tomhoule Did look into this? I have the exact need you mentioned of building a CLI tool to validate queries against a schema. If you didn't spend time on it...