4 ms·

> Comparing GraphQL to REST is apples to oranges Just because you say that, doesn't make it true. > most of those endpoints load more data than they need Gra

> Comparing GraphQL to REST is apples to oranges Just because you say that, doesn't make it true. > most of those endpoints load more data than they need GraphQL proponents seem to forget query parameters exist. It has never been the case that REST has to return more than you need. Never. Not now, not ten years ago. Why people keep repeating this obviously false claim is bizarre. The hoops you have to jump through to get GraphQL efficient as off-the-shelf REST are rather insane. Caching, both client and server side, have to be entirely reinvented. What Apollo does may be open source but it's also proprietary. And at this point, a single corporation controls the entire stack. Without Apollo, GraphQL is a terrible joke.

strken 7y ago
> GraphQL proponents seem to forget query parameters exist. It has never been the case that REST has to return more than you need. Never. Not now, not ten years ago. Why people keep repeating this obviously false claim is bizarre. You need to use something that does the same thing as GraphQL, e.g. allows you to define a graph of relationships and then query them, and can have many of the same tradeoffs, e.g. not being cacheable or not allowing you to stream the result. If you like the other thing better than GraphQL (I've used https://jsonapi.org/ https://jsonapi.org/ and https://loopback.io/ https://loopback.io/, among others), by all means use it. This is what I mean when I say comparing GraphQL to REST is apples to oranges. REST is general and broad and GraphQL is narrow and specific, so the comparison isn't meaningful unless we start talking about specific libraries, frameworks, specs, or patterns that use REST to do the same thing GraphQL does.
- digitaltrees 7y ago
  Check out Graphiti.dev it shows how a few common sense conventions in REST give most or all the power of GraphQL. I think the phrase “comparing apples to oranges” is a bit misleading in this context because it is normally used to imply that such comparison is impossible or not useful (i.e. a fruitless exercise, sorry, I couldn’t help it). But here there is a lot to compare. REST is built with the basic infrastructure of the web in mind so massive amounts of infrastructure like caching, error messaging do need to be rebuilt. GraphQL has some real benefits so a comprehensive comparison is worth it. Ultimately both are an api design to facilitate getting data. It’s sort of like comparing Postgres to MongoDB. Yes there are major differences but the expected use is to store data. Comparing is crucial. Either way. Have fun building cool stuff.

strken 7y ago

> GraphQL proponents seem to forget query parameters exist. It has never been the case that REST has to return more than you need. Never. Not now, not ten years ago. Why people keep repeating this obviously false claim is bizarre. You need to use something that does the same thing as GraphQL, e.g. allows you to define a graph of relationships and then query them, and can have many of the same tradeoffs, e.g. not being cacheable or not allowing you to stream the result. If you like the other thing better than GraphQL (I've used https://jsonapi.org/ https://jsonapi.org/ and https://loopback.io/ https://loopback.io/, among others), by all means use it. This is what I mean when I say comparing GraphQL to REST is apples to oranges. REST is general and broad and GraphQL is narrow and specific, so the comparison isn't meaningful unless we start talking about specific libraries, frameworks, specs, or patterns that use REST to do the same thing GraphQL does.

digitaltrees 7y ago
Check out Graphiti.dev it shows how a few common sense conventions in REST give most or all the power of GraphQL. I think the phrase “comparing apples to oranges” is a bit misleading in this context because it is normally used to imply that such comparison is impossible or not useful (i.e. a fruitless exercise, sorry, I couldn’t help it). But here there is a lot to compare. REST is built with the basic infrastructure of the web in mind so massive amounts of infrastructure like caching, error messaging do need to be rebuilt. GraphQL has some real benefits so a comprehensive comparison is worth it. Ultimately both are an api design to facilitate getting data. It’s sort of like comparing Postgres to MongoDB. Yes there are major differences but the expected use is to store data. Comparing is crucial. Either way. Have fun building cool stuff.