Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraphQL: A data query language

code.facebook.com

Post reply on HN
Print view View original

71–80 of 84 posts

Re: GraphQL: A data query language

#71

Post by TheMakeA »

adriancooney wrote: post #64
TheMakeA wrote: post #30

Every time there's a new post about GraphQL, I become even more concerned that "GraphQL" was the wrong name to use publicly. It seems like most people assume it's just another combination of two buzzwords, Graph and QL, and incorrectly pattern match it. In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead. It's not a storage layer. It's not really a query languag…

I'd have to disagree in that it's not a query language, there is definitely ability to query different parts of the data. I'm just unsure where the Graph part of the name came from. I was under the impression it was some play on the words sounding like "graphical" since the appearance of the query language in code is a very close depiction of the actual data returned.

> I'd have to disagree in that it's not a query language, there is definitely ability to query different parts of the data

For sure. If I could still edit the post, I would probably change it to be something closer to "it's not really a general purpose query language like the name might imply"

It's definitely a query language, but folks start looking for the sorting/filtering/etc and get confused.

Re: GraphQL: A data query language

#72

Post by dwenzek »

TheMakeA wrote: post #70
dwenzek wrote: post #53

Earlier quoted context omitted.

No, I disagree. GraphQL is definitely a query language, since it allows to specify pieces of data to be extracted from a whole data set. Compared to SQL, this is done using an unusual manner, giving a shape of the data we want around some seed, but the approach is both expressive and efficient. In light of this query principle, it is perhaps unfortunate that GraphQL use a different syntax for the query and the respon…

Let me clarify a little: I think the name GraphQL for sure makes sense from a technical point of view. But from a marketing point of view, it has been a nightmare and makes it _unusually_ difficult for others to initially grasp.

So what you mean is that name of GraphQL minimizes one of its important aspect: the ability to query a service/product/app whatever are the actual persistence mechanisms and even so if part of the response is computed on the fly.

Now, I better understand, why you would prefer a name like ProductQL or even ProductAPI in order to emphasise the will for this tool to be the single point of interaction from the outside with a product.

Re: GraphQL: A data query language

#73

Post by orclev »

This works fine for read only (I.E. query interface), but what about for non-idempotent endpoints? It seems like you'd need to provide BOTH a REST API and a GraphQL API, GraphQL for doing queries, and REST for everything else. Admittedly the query endpoints tend to be the ugliest ones in a REST API, but I'm not sure that ugliness justifies the extra complexity and overhead adopting something like GraphQL would entail (not to mention potential performance and DoS issues others have brought up).

Re: GraphQL: A data query language

#74

Post by dschafer »

devit wrote: post #57

How do GraphQL implementations avoid denial of service? In other words, what stops anyone from easily disabling a website by making a few parallel extremely complex GraphQL requests that consume all CPU and I/O, and perhaps result in holding some locks for a very long time? In normal APIs you can make sure most endpoints are cheap to run, and throttle, secure or otherwise control the ones that must be expensive, but…

FB's GraphQL APIs are only used by our first-party applications; for third-party APIs (where you don't control the callers), it definitely gets trickier for the reasons you note. One option would be to do some analysis of the query in advance (effectively, assign each field a "cost"), and reject queries that have too high of a cost. The "cost" metric could basically be "around how many objects will this return", so in the

  user {friends {friends {friends {friends{id}} } } }
case (which is the canonical example in FB's schema of a crazy query), we would note that there's a 5000 friend limit, and so that query would potentially query 5000^4 = 6.25e14 nodes, and based on that we would (hopefully) reject it.

Re: GraphQL: A data query language

#76

Post by dschafer »

Novex wrote: post #44

Version Free sounds amazing - I can see the pros of being able to add/deprecate fields at the same API endpoint, but I find most of the reason we version our API is for field type changes as the data schema naturally evolves. We need to keep track of finer grained data in existing fields that wasn't originally thought of. To take the Star Wars example at https://github.com/facebook/graphql and build on it. Let's say…

Yeah, introducing a new field and deprecating the old one seems like the best option here. The nice thing is that while this introduces new functionality, there's still only one version of the server; if you query for `homePlanet`, you always get the name, if you query for `homePlanetDetails`, you always get the planet object. This is particularly useful for tooling, since the API response is a function only of the access token and the query.

Re: GraphQL: A data query language

#77

Post by aikah »

eggie wrote: post #65
Amrinder12345 wrote: post #59

Earlier quoted context omitted.

Every time there's a new post about GraphQL

And with good reason. I work on graph data structures and have had four people suggest I check out "GraphQL" for my work. Alas it has almost nothing to do with graphs. Every time I read about it I feel that Facebook tech has jumped the shark. I'll go back to my terascale rank/select dictionaries now...

> Every time I read about it I feel that Facebook tech has jumped the shark

No, Facebook does it on purpose, just like React has nothing to do with functional reactive programming. They are talented , not idiots , they know that a catchy name is useful to promote their tech even if it is misleading.

Re: GraphQL: A data query language

#78

Post by yzh »

mrinterweb wrote: post #52
yzh wrote: post #50

Shameless self-promotion: Gunrock, a high-performance GPU graph processing library: http://gunrock.github.io/gunrock/

I'm confused. What does your library have to do with GraphQL?

We are trying to enable graph query into our library too. Currently working on subgraph matching, but might expand to more general graph query. I think in general, graph with rich attribute is quite difficult to deal with on the GPU. Thanks for your interest.

Re: GraphQL: A data query language

#79

Post by mandeepj »

devit wrote: post #57

How do GraphQL implementations avoid denial of service? In other words, what stops anyone from easily disabling a website by making a few parallel extremely complex GraphQL requests that consume all CPU and I/O, and perhaps result in holding some locks for a very long time? In normal APIs you can make sure most endpoints are cheap to run, and throttle, secure or otherwise control the ones that must be expensive, but…

You have to write a functionality for this scenario. Similarly You can also ask how Sql server is going to avoid DOS attacks?

Re: GraphQL: A data query language

#80

Post by leebyron »

bobbylox wrote: post #32

Why invent syntax when you can specify the queries in JSON, too? MQL did it, and it was amazing: http://wiki.freebase.com/images/e/e0/MQLcheatsheet-081208.pd...

The GraphQL language syntax is useful because it naturally expresses more patterns than JSON can. However GraphQL is eventually parsed into an AST which is represented as JSON, it's always possible to write that JSON directly.

Ultimately syntax is useful to express domain-specific concepts in a terse way.

Post reply on HN