Would love to see a more robust server backend for this, but I am assuming it's still a long way off.
A standard is a very good start. I notice the license is BSD, but is this patent encumbered?
GraphQL Working Draft
11–20 of 71 posts
Re: GraphQL Working Draft
#12Would love to see a more robust server backend for this, but I am assuming it's still a long way off. A standard is a very good start. I notice the license is BSD, but is this patent encumbered?
There's a JS server provided: https://github.com/graphql/graphql-js.
Re: GraphQL Working Draft
#13Finally! It's exciting to see a serious challenger to the cult of REST.
Re: GraphQL Working Draft
#14Would love to see a more robust server backend for this, but I am assuming it's still a long way off. A standard is a very good start. I notice the license is BSD, but is this patent encumbered?
Unlike with RESTful APIs, a server basically only needs a single endpoint that parses and responds to GraphQL commands. This isn't as far off as you suppose to be the case.
Re: GraphQL Working Draft
#15Would love to see a more robust server backend for this, but I am assuming it's still a long way off. A standard is a very good start. I notice the license is BSD, but is this patent encumbered?
Unlike with RESTful APIs, a server basically only needs a single endpoint that parses and responds to GraphQL commands. This isn't as far off as you suppose to be the case.
The trickiness will come in handling authentication for all the nested resources (e.g., user X can only see public photos for user Y, and can't update them) and generating efficient queries to a relational datastore. Coming up with a clean architecture for that actually seems like a fun project!
Re: GraphQL Working Draft
#16Why not have the query in JSON? Now you need a new parser. EDIT: Thanks for all the replies, all of them very good points, and clearly show that JSON is not the most elegant option for a complex DSL.
Readability I guess. The new syntax looks pretty good to me. A little heavy on the (( and )) but very obvious as to what is being asked.
I wonder how important readability is in this case, though. How likely is it that this language will be written (or read) directly by people, rather than generated and consumed by programs? The potential bugs in generators and parsers (think SQL injection) seem like a real cost, which I would have thought would outweigh the benefit of improved readability.
Re: GraphQL Working Draft
#17Finally! It's exciting to see a serious challenger to the cult of REST.
> cult of REST
Is this a thing?
Re: GraphQL Working Draft
#18Earlier quoted context omitted.
Unlike with RESTful APIs, a server basically only needs a single endpoint that parses and responds to GraphQL commands. This isn't as far off as you suppose to be the case.
The trickiness will come in handling authentication for all the nested resources (e.g., user X can only see public photos for user Y, and can't update them) and generating efficient queries to a relational datastore. Coming up with a clean architecture for that actually seems like a fun project!
It's a good thing that relational databases solved the problem of generating efficient execution plans for ad-hoc queries about thirty years ago—with SQL.
Re: GraphQL Working Draft
#19So, I haven't had enough time to really dig into the spec but it doesn't seem like the language has any kind of insert or update type of feature. Perhaps I just missed it though.
But if it doesn't it seems like you would need a pretty large dataset to make this worth it, right? I mean for any kind of a change event you still need to support a standard REST API, as this really only replaces the GET operation. Am I missing something on it? I certainly not saying it's not a cool idea or base to build from, just want to make sure I'm not skipping over an important piece.
Re: GraphQL Working Draft
#20There was a comment on the original blog post that while they (Facebook) use GraphQL they still fall back to Flux for some of the data handling. Was this solved ? Did they manage to handle all the data needs of their apps with GraphQL or is it still limited to certain areas ?
They are orthogonal; graph ql is for fetching data and is supposed to be an alternative to writing a new backend endpoint for every ui-thing that needs some slice of data, flux is a pattern for organizing data flow in the UI.