Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for GraphQL Schema Language #324

Closed
wants to merge 7 commits into from

Conversation

LegNeato
Copy link
Member

@LegNeato LegNeato commented Mar 2, 2019

No description provided.

@LegNeato
Copy link
Member Author

LegNeato commented Mar 2, 2019

A couple of notes:

  1. Naming is probably bad, please give suggestions if so.
  2. I didn't document the graphql-parser-integration feature. Not sure if we want that as public API, though I currently made it public in case other projects need to use it.
  3. I had a trait AsSchemaLanguage and implemented it for every MetaType. I didn't like how it made the code look with all the conditional compilation, so I centralized it into a SchemaTranslator instead.

@LegNeato LegNeato added the enhancement Improvement of existing features or bugfix label Mar 2, 2019
@LegNeato LegNeato requested a review from theduke March 2, 2019 07:40
@LegNeato LegNeato force-pushed the schema branch 2 times, most recently from 45b7ecb to 2bed836 Compare March 2, 2019 17:46
@theduke
Copy link
Member

theduke commented Mar 5, 2019

I'm not so sure what the use case for this is.

The schema language is usually used the other way around AFAIK, as in bootstrapping a server from a schema file and adding resolver methods.

Downstream tools use a introspection query to get the schema, since that way the information is already structured in a standardized way.

Where do you see this being useful? The only one I could think of is generating a easily readable specification of your schema for human consumption.

@LegNeato
Copy link
Member Author

LegNeato commented Mar 5, 2019

You need a schema file to use https://github.com/graphql-rust/graphql-client among other use cases such as external tools. Sure, you could run the introspection query and that's the next thing I am adding. If the schema is defined in Juniper/rust, it is essentially "locked up" until runtime currently.

@LegNeato
Copy link
Member Author

LegNeato commented Mar 5, 2019

But now that I think about it, perhaps it makes sense for this to be its own little crate/project, similar to https://github.com/davidpdrsn/juniper-from-schema? An argument can be made that it should be part of juniper as well as not. 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.

FWIW, Graphql.js has printSchema() built in, which does what this PR does (goes from internal language representation to IDL).

Then again, they also have a way to go from the IDL to the internal representation, which is what https://github.com/davidpdrsn/juniper-from-schema does in Rust land.

I guess the same arguments would apply to #307 as well? So you could argue that juniper should include both this PR and something like juniper-from-schema to match the capabilities of GraphQL.js, or you could argue that those can be handled by helper crates for people needing the functionality and juniper only focuses on the Rust definition and executing.

I'm going to open an issue.

@codecov-io
Copy link

codecov-io commented Mar 8, 2019

Codecov Report

Merging #324 into master will decrease coverage by 0.22%.
The diff coverage is 72.64%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #324      +/-   ##
==========================================
- Coverage   87.79%   87.57%   -0.23%     
==========================================
  Files         101      102       +1     
  Lines       14244    14457     +213     
==========================================
+ Hits        12506    12660     +154     
- Misses       1738     1797      +59
Impacted Files Coverage Δ
juniper/src/lib.rs 80.95% <ø> (ø) ⬆️
juniper/src/schema/model.rs 82.74% <58.53%> (-4.64%) ⬇️
juniper/src/schema/translate/graphql_parser.rs 74.68% <74.68%> (ø)
juniper/src/schema/meta.rs 88.7% <92.3%> (+0.13%) ⬆️
juniper/src/types/scalars.rs 87.42% <0%> (-0.56%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bd6f192...caa7008. Read the comment docs.

@theduke
Copy link
Member

theduke commented Mar 9, 2019

First glance looks good, I'll review thoroughly later today.

One question is how much work it would be to fully switch over to graphql-parser instead of bringing it in as a feature.

Also maybe there is a more elegant way to detect builting types than __ prefix checking.

@LegNeato
Copy link
Member Author

LegNeato commented Mar 9, 2019

@theduke For switching entirely over to graphql-parser's AST I think the concerns in #138 (comment) are still valid?

Also, it would probably be pretty trivial to change this to go direct to the string output without going through graphql-parser. Not sure if we want to go that route though...

@theduke
Copy link
Member

theduke commented Apr 9, 2019

@LegNeato as a first step I have opened a PR that allows a borrowed AST on the parser: graphql-rust/graphql-parser#19

I'll investigate wheter we'd really want to switch to that AST, and compare it with our own.
But, mapping the AST from the parser to ours would be a very lightweight operation that shouldn't make a difference performance wise.

@theduke
Copy link
Member

theduke commented May 15, 2019

@LegNeato I'm working on switching to graphql-parser.

We could wait with this until that happens, or move ahead now if you'd like to get it in sooner.

impl<'a, S> Field<'a, S> {
/// Returns true if the type is built-in to GraphQL.
pub fn is_builtin(&self) -> bool {
// "used exclusively by GraphQL’s introspection system"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a bit hacky, __ is not reserved so users could add their own objects/ fields/arguments/...

We could add a builtin: bool flag to the relevant schema types.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From https://github.com/graphql/graphql-spec/blob/master/spec/Section%203%20--%20Type%20System.md#schema:

"All types and directives defined within a schema must not have a name which begins with {"__"} (two underscores), as this is used exclusively by GraphQL's introspection system."

@theduke
Copy link
Member

theduke commented May 15, 2019

Mostly looks good.

Actually I'd be in favor of including it now, but without the feature, let's just build it in.

@LegNeato
Copy link
Member Author

Ok, I'll rip out the features, rebase, and switch to borrowing after your patch lands.

@arlyon
Copy link
Contributor

arlyon commented Jan 15, 2020

Juniper has changed quite a bit since August (especially with the recommendation to base new PRs on the async branch). That said, keen to test this PR out, I rebased this onto #493 and changed the graphql-parser dependency to depend on the master branch and (after sprinkling in some lifetimes) this works like a charm.

Seems like for this to be merged we are waiting on:

  • the async-await branch merge
  • a new version of graphql-parser

I can open a PR with my (minimal) changes, just know that I am still quite new to rust.

@LegNeato
Copy link
Member Author

I updated master to use the async-await branch.

@LegNeato
Copy link
Member Author

Would love a PR with the updated changes!

@LegNeato
Copy link
Member Author

@arlyon any chance you can put up the rebased changes?

@LegNeato
Copy link
Member Author

Friendly 👉@arlyon

@arlyon
Copy link
Contributor

arlyon commented Apr 15, 2020

Hey, missed these for some reason. I was going to open a PR, but I noticed a new version of graphql-parser is out and it seems silly not to update. Lifetimes are a bit annoying to iron out so it's taking a bit of time.

Edit: thought I was close to done, but can't get it right so I'm giving up. There's clearly some lifetime stuff I don't quite grasp. Sorry for blocking.

@LegNeato
Copy link
Member Author

@arlyon great, thank you! Yes, the new version should allow us to use &str instead of Strings and be a lot more memory efficient feel free to post WIPs if you get stuck!

@LegNeato
Copy link
Member Author

LegNeato commented Jun 6, 2020

This was landed as #676

@LegNeato LegNeato closed this Jun 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement of existing features or bugfix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants