Been playing around with GraphQL in the last day or so and just can't see any reason to use it over REST (or REST + an ORM). Am I missing something? Is it just so people don't have to learn SQL?
GraphQL is hierarchical. The queries look substantially like the output JSON. SPARQL (and SQL) require training. With a common tool like GraphiQL or Playground, queries are simple enough and abstracted enough (am I querying Redis, PostgreSQL, S3, or some combination?) that clients don't have to know much of anything except what data they want. That's huge.
It puts the onus on server developers to audit their data and security models, but they should be doing that anyway no matter what the stack looks like.
REST suffers from the N+1 problem and overfetching. Most ORMs do as well. "Oh! You want order info AND product reviews? (At least) 2 more REST calls for you. Oh! You don't need the person's shipping and billing addresses in this case? So sorry, take them anyway, otherwise we would have to make another REST endpoint just for you."
Also affects versioning. In REST you commonly see URLS like "/v1/foo/54321" because if you try to remove or rename ANY PART of the JSON payload coming back, you break a contract. With GraphQL, you make the new name available and mark the old name with a directive like @deprecated. Over time you watch the logs to see if any clients are still using the old name. If so, keep it around and write another blog post asking folks not to use it anymore. If not, just remove it. You're done. No broken contracts. No differently versioned URLs.
GraphQL handles N different clients with a single schema. Mobile app clients, desktop clients, B2B clients, et al get exactly the data they need—no more and no less. REST either shoehorns them all into one or two access models or explodes into an unmaintainable mess of hundreds or thousands of often redundant endpoints.
The biggest difference, the one that GraphQL was really originally built to solve at Facebook, was to allow the CLIENT to determine what data they needed at any given time rather than REST which may be driven by client requests but ultimately is what servers THINK clients will need, and is much harder to change as needs change (and they will change).
EDIT: It was awesome, and I kind of miss it, but it was too much to maintain within our constraints.