4 ms·

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

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?

Fellshard 7y ago
Client-side shaping of queried data without directly writing SQL against a back-end database, and without having to pre-arrange queried data structure with the back-end.
- zozbot234 7y ago
  Wouldn't SPARQL be a better choice for this? It's an actual Web standard, unlike GraphQL so a better fit to general-purpose clients with no "pre-arranged queried structure".
  - miles-po 7y ago
    SPARQL is a flat result set, just like SQL. Also so much like SQL, it's not actually an advantage over SQL, just removed from a relational database. 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.
MikeAmelung 7y ago
I used it once upon a time to essentially allow joins across 3 separate databases that had all been developed/grown independently. Once you have certain kinds of resolvers between types, all sorts of neat stuff is possible. Ultimately, once we had time to update the applications, we merged the databases and dropped the GraphQL app entirely. EDIT: It was awesome, and I kind of miss it, but it was too much to maintain within our constraints.
adamredwoods 7y ago
I've been using it lately, too, and think of it as a database to connect databases and return json. Yet another layer in the ever-growing stack.
miles-po 7y ago
I love SQL. I'll write CTEs and window functions until the cows come home with a smile on my face. But not everyone needs to know SQL. There are many other worthy pursuits. 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).

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?

Fellshard 7y ago

Client-side shaping of queried data without directly writing SQL against a back-end database, and without having to pre-arrange queried data structure with the back-end.

zozbot234 7y ago
Wouldn't SPARQL be a better choice for this? It's an actual Web standard, unlike GraphQL so a better fit to general-purpose clients with no "pre-arranged queried structure".
- miles-po 7y ago
  SPARQL is a flat result set, just like SQL. Also so much like SQL, it's not actually an advantage over SQL, just removed from a relational database. 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.

MikeAmelung 7y ago

I used it once upon a time to essentially allow joins across 3 separate databases that had all been developed/grown independently. Once you have certain kinds of resolvers between types, all sorts of neat stuff is possible. Ultimately, once we had time to update the applications, we merged the databases and dropped the GraphQL app entirely. EDIT: It was awesome, and I kind of miss it, but it was too much to maintain within our constraints.

adamredwoods 7y ago

I've been using it lately, too, and think of it as a database to connect databases and return json. Yet another layer in the ever-growing stack.

miles-po 7y ago

I love SQL. I'll write CTEs and window functions until the cows come home with a smile on my face. But not everyone needs to know SQL. There are many other worthy pursuits. 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).