Adding a parser for Schema definition about graphql-js

[ecstasy2]

@leebyron One use case of a parser like that would be to validate the schema against orm orm external schema.

[leebyron]

We have a version of this internally that we decided to exclude from the spec for now as we work out the semantics. We didn't want to confuse people with that, as generating server code is the wrong solution for most and it's unclear when and if these can be included in a graphql document.

We have some cool client tools that leverage this sort of thing for code generation purposes, but we want to make sure we have that right before sharing more broadly

[madjam002]

Would it be possible to share what sort of tools you guys are working on internally? (e.g IDE autocomplete, static analysis etc). Sorry if this was mentioned in the stream, I was unable to watch all of your presentation due to buffering!

It would be useful to get a heads up though as then we can prevent someone else in the community developing tools which could be released in the future by you guys.

[leebyron]

We're working on a few IDE tools, but if anyone is interested I hope they tell us so at the very least we can provide guidance and resources.

We would love to share our tools, but most of them are tightly tied to Facebook's internal data sets and infrastructure and don't work outside of that environment. We're picking a few of the high value ones to generalize and share, but it will just take some time.

[ecstasy2]

My personal Interest with this parser is to make it part of a tool that
will provide two way sync of code and Schema.
I know that code generation might sound like a bad idea, but if you think
about it 99% of the js schema is just boilerplate code that would be more
easily written with the GraphQL syntax.

If there is any chance to get that code even if not as part of the repo
that would be nice.
On Jul 3, 2015 5:29 AM, "Lee Byron" [email protected] wrote:

We have a version of this internally that we decided to exclude from the
spec for now as we work out the semantics. We didn't want to confuse people
with that, as generating server code is the wrong solution for most and
it's unclear when and if these can be included in a graphql document.

We have some cool client tools that leverage this sort of thing for code
generation purposes, but we want to make sure we have that right before
sharing more broadly

—
Reply to this email directly or view it on GitHub
#16 (comment).

[madjam002]

@leebyron Alright thanks. Great presentation yesterday, hopefully I'll be able to watch the rest soon as it cut out half way through!

[leebyron]

Yeah, we're interested in spec'ing and building up the parser for this IDL for code-gen as well! So it's certainly on the list of things we want to do. Tracking this in #21