If the main metric for success for an API is payload size, then the implementations of GraphQL are tough to beat. Though there is nothing stopping you from doing the same thing with REST (what some call sparse field sets), GraphQL already has a solid implementation of reducing those responses. And it has great tooling. That doesn't exist for most web APIs.
GraphQL also has its own complexities. It's caching story is not great. Pagination is not as nice as adding next and prev links in an API like GitHub used. Errors are lacking compared to what HTTP allows.
I suppose my long-winded point here in the context of the post is that while those are great technologies, I'm still unconvinced people are going out to search for solutions for overfetching or underfetching. And I'm not sure these technologies make it conceptually a better choice than REST. REST has a lot of ideas outlined in the original spec that most people don't use. That makes it harder to compare for me.
But if you're building a JavaScript frontend or mobile app, wow, it's hard to compete with GraphQL.
I think you're confusing GraphQL with a certain implementation of it. It's as flexible as you build it to be. There's a convention relay uses for pagination, but that's completely optional. If you want to add next and prev and page number, go for it. Same goes with caching. You may be using an instance that doesn't handle caching the way you want, but caching has nothing to do with GraphQL itself or any errors other than syntax. It's up to the one managing the API service to handle these things, as they define how GraphQL can interface with their systems. GraphQL isn't a javascript or php module, it's just a more abstract language specification
I’m speaking more about the entire GraphQL ecosystem in my comment. The stories around what I mentioned are fuzzy and developing over time. You are right, the implementation is up to the providers and the issues are not addressed in the spec.
The HTTP ecosystem on the other hand has several widespread specs and implementations for these things.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Won't it still be technically superior because of roundtrip/overfetching/underdelivering reasons?
If the main metric for success for an API is payload size, then the implementations of GraphQL are tough to beat. Though there is nothing stopping you from doing the same thing with REST (what some call sparse field sets), GraphQL already has a solid implementation of reducing those responses. And it has great tooling. That doesn't exist for most web APIs.
GraphQL also has its own complexities. It's caching story is not great. Pagination is not as nice as adding
nextandprevlinks in an API like GitHub used. Errors are lacking compared to what HTTP allows.I suppose my long-winded point here in the context of the post is that while those are great technologies, I'm still unconvinced people are going out to search for solutions for overfetching or underfetching. And I'm not sure these technologies make it conceptually a better choice than REST. REST has a lot of ideas outlined in the original spec that most people don't use. That makes it harder to compare for me.
But if you're building a JavaScript frontend or mobile app, wow, it's hard to compete with GraphQL.
I think you're confusing GraphQL with a certain implementation of it. It's as flexible as you build it to be. There's a convention relay uses for pagination, but that's completely optional. If you want to add next and prev and page number, go for it. Same goes with caching. You may be using an instance that doesn't handle caching the way you want, but caching has nothing to do with GraphQL itself or any errors other than syntax. It's up to the one managing the API service to handle these things, as they define how GraphQL can interface with their systems. GraphQL isn't a javascript or php module, it's just a more abstract language specification
I’m speaking more about the entire GraphQL ecosystem in my comment. The stories around what I mentioned are fuzzy and developing over time. You are right, the implementation is up to the providers and the issues are not addressed in the spec.
The HTTP ecosystem on the other hand has several widespread specs and implementations for these things.