Schema

[schloerke]

Great package! Allows me to parse queries very quickly and easily!

Will schema parsing be added to this repo (written in c or cpp)? I can see graphql.js has a schema parser here: http://graphql.org/docs/api-reference-schema-language/

My motivation is to do something similar to https://github.com/matthewmueller/graph.ql but with another language.

Thank you,
Barret

[aarvay]

Defining and parsing schema is an implementation's job as each implementation will have its own better way of doing it, mostly based on what the language the implementation is written in, offers.

However, there're actually quite a lot of the language spec that needs to be implemented here.
For a start, this test needs to get passed.

[schloerke]

Fair.

You're correct. It doesn't like the kitchen sink. :-(
So what you're saying is that I should look elsewhere for an query parser, as this one is not complete? I really enjoy the json output that you provide.

[swolchok]

It doesn't like the kitchen sink. :-(

Hmm, that's strange. I missed this bug report because this issue is marked as being about schema parsing and I was busy with end-of-year stuff. I'll look into why the kitchen sink test is failing.

[swolchok]

Found the problem: graphql/graphql-js@3f1f9f5 broke us. Working on a fix.

[swolchok]

8feed9c fixes parsing of kitchen-sink.graphql.

As to the original question about adding schema parsing to this project, I would take a patch that added schema parsing so long as it could be disabled at build time (and, probably, was disabled by default), but I probably won't add it myself.

Here's my underlying philosophy on why it should be optional: The main reason to do a C++ implementation of anything, in my opinion, is performance, and the main environment where I expect high-performance GraphQL parsing to matter is server-side. Servers probably don't need to parse the schema language, at least not after startup, and they very probably should not accept schema definitions as part of incoming queries.

[swolchok]

By the way, if you find more spec-compliance bugs in libgraphqlparser, please report them and I will fix them quickly! I consider them to be very serious; this one just slipped through the cracks. :(

[schloerke]

Thank you for the fix!

(small) Rebuttal for the schema... It is fairly easy for me to call C++ that returns JSON and parse the JSON output. It is MUCH more difficult to create / maintain a text parser to parse the schema in a language that hates strings. Yes, parsing the schema's would only be done once, but it'd be done with the same mechanism (or something similar) as the queries.

Unfortunately, my C++ skills are not up to this level... so we'll leave it as it. ;-)

[swolchok]

Hmm, that is a good point. I will have to think more about implementing schema parsing; reopening to track.

[aarvay]

Thanks for the fix. And I concur with @swolchok, regarding supporting schema parsing. Schema definitions can take its own form. It needn't be "strings"! :)

[rivanov2]

@swolchok Hi,

First of all, thank you for making this fantastic library.

I'm currently in a position that necessitates me to write a schema parser, or a whole ODB wrapper.
My intention was to use ODB -> postgraphql -> schema parser (custom) -> libgraphql -> restbed to implement a graphql-server.

Any ideas whether or not you'll be implementing a schema-parser? I'd love to contribute my implementation to this project when it's complete.

Cheers!

[swolchok]

#45 seems to be working, but I'm waiting for the holiday season to end before merging it.