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

61–70 of 84 posts

Re: GraphQL: A data query language

#61

Post by andy_ppp »

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…

GraphQL:

1) Give me data in the right shape for my problem please server.

2) Server responds with data in a shape that matches what it was asked for.

3) Update the store of your frontend and trigger any updates to UI (react does this automatically).

Save countless hours of writing fine grained rest APIs to support various different ways of requesting data or munging data into the right format on the client.

And by the way we've made it super easy to bundle requests together in a nice way saving trips to the server.

Re: GraphQL: A data query language

#62

Post by thomasahle »

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…

Perhaps you just analyze the queries and deny the ones that look too expensive?

Re: GraphQL: A data query language

#63

Post by nstart »

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…

It's the same here. Limit number of results to 10 by default (for example) and allow query to specify number if you need more. Then limit the number to a certain amount

Re: GraphQL: A data query language

#64

Post by adriancooney »

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.

Re: GraphQL: A data query language

#65

Post by eggie »

Amrinder12345 wrote: post #59
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…

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...

Re: GraphQL: A data query language

#66

Post by devit »

nstart wrote: post #63
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…

It's the same here. Limit number of results to 10 by default (for example) and allow query to specify number if you need more. Then limit the number to a certain amount

There are more ways in GraphQL to create huge result sets than that though.

For example, a query like "user {moviesWatchedByUser {usersWhoWatchedMovie {moviesWatchedByUser {usersWhoWatchedMovie ..." is allowed by GraphQL and will generate output with size exponential in the input size.

You can also do "{a1: expensiveOperation, a2: expensiveOperation, a3: expensiveOperation, ..." and trigger expensiveOperation an arbitrary number of times (for each item in the list you apply that to).

By using a sequence of fragments that include the next fragment more than once, it looks like you can trigger expensiveOperation an exponential number of times.

It's not clear if there is a way to prevent all this without severely impacting usabilty (by warping the schema design and adding GraphQL limits to handle this) or reliability (by enforcing hardcoded low resource usage limits).

Re: GraphQL: A data query language

#67

Post by jon-wood »

devit wrote: post #66
nstart wrote: post #63

Earlier quoted context omitted.

It's the same here. Limit number of results to 10 by default (for example) and allow query to specify number if you need more. Then limit the number to a certain amount

There are more ways in GraphQL to create huge result sets than that though. For example, a query like "user {moviesWatchedByUser {usersWhoWatchedMovie {moviesWatchedByUser {usersWhoWatchedMovie ..." is allowed by GraphQL and will generate output with size exponential in the input size. You can also do "{a1: expensiveOperation, a2: expensiveOperation, a3: expensiveOperation, ..." and trigger expensiveOperation an arbi…

Personally I'd probably enforce this at the level of whatever services the GraphQL layer is calling, assuming you're using it as an aggregation layer for lower level services within your organisation.

Otherwise, it should be possible to apply throttling to (for example) expensiveOperation in the same way that you would a RESTful API at the moment.

Re: GraphQL: A data query language

#68

Post by lhorie »

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…

The Youtube API has a concept of quotas, where requesting some types of information is more costly than others. I imagine you could implement a similar system that additively increases the cost of a query as it grows in complexity and fails if the quota is exceeded.

Re: GraphQL: A data query language

#69

Post by forgotAgain »

rattray wrote: post #10

I keep hearing people say things along the lines of, "Relay looks great, but I don't want to store my data in a graph". My impression is that GraphQL has nothing to do with graphs, really - it's a bit more like SchemaQL if anything. Could someone from the facebook team clarify about the name?

It seems that the graph part is referring to how the input is evaluated one node at a time and applied to the output. The sub objects (child nodes) of the input are evaluated and then applied to the output. It's a graph in the sense that it's a tree being evaluated and built. I would think it's pretty optimal if you're using nosql stores that are cached heavily with good locality of data and you can send the request to the right server based on the first node of the input.

Re: GraphQL: A data query language

#70

Post by TheMakeA »

dwenzek wrote: post #53
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…

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.
Post reply on HN