REST vs. GraphQL – A search for evidence on which is better
1–10 of 243 posts
Re: REST vs. GraphQL – A search for evidence on which is better
#2Yes, had this discussion on here before. While in REST you can more or less optimize a service to be performant at what it does, the moment there is another service that you need to fetch some additional data, the browser would be required to orchestrate that, which means you're also waiting for the return trip on the first call before you can even get the secondary data. This alone makes REST far less favorable in my opinion.
The secondary is that operations are standardized in GQL. Whereas in REST I can pass data in through:
Query params
Body
Headers
Path variables
Each team will do this differently. In graphQL these inputs are pretty much standardized and you have the option to implement security through headers. This makes GQL decoupl-able from HTTP (at some point). That's a great incentive too by itself since at some point the web may just be media distributions + services. Where media distributions is just HTML/CSS/JS/etc... There's new reasons as time moves forward media distributions needs to take place over HTTP.
The top response to this is caching - in other words every device on the planet knows HTTP so caching in GQL becomes a secondary thought. So yeah there's that. GQL has some variously applied caching semantics - so YMMV but personally I still feel like the gains from the first point are so dramatic that most people won't really care about this.
Re: REST vs. GraphQL – A search for evidence on which is better
#3original link https://arxiv.org/abs/2003.04761
Re: REST vs. GraphQL – A search for evidence on which is better
#4Yes, had this discussion on here before. While in REST you can more or less optimize a service to be performant at what it does, the moment there is another service that you need to fetch some additional data, the browser would be required to orchestrate that, which means you're also waiting for the return trip on the first call before you can even get the secondary data. This alone makes REST far less favorable in m…
You do realize there's no reason a rest endpoint can't support doing this.
My endpoints take a 'fields' parameter... and those fields can themselves be serialized objects.
Re: REST vs. GraphQL – A search for evidence on which is better
#5you must construct additional ~pylons~ abstraction layers
Re: REST vs. GraphQL – A search for evidence on which is better
#6Are there any performance benchmarks comparing REST and GraphQL?
Re: REST vs. GraphQL – A search for evidence on which is better
#7Admittedly I skimmed -- observed that the paper dove really deep into time to perform queries and implement desired behavior, but didn't spend much time on implementation of GraphQL vs a REST API.
One statement made that stood out to me:
> it is clear that the availability of a type system—expressed as a schema— is one of the key benefits provided by GraphQL
So I wonder what the results would look like if you had an OAS spec file for the API you were hitting (with autocomplete in VSCode), seems to me that's the best of both worlds: ease of implementation on the server side, ease of use on the client side.
This to me feels like an argument of better tooling and (self) documentation rather than one technique over another.
Re: REST vs. GraphQL – A search for evidence on which is better
#8Yes, had this discussion on here before. While in REST you can more or less optimize a service to be performant at what it does, the moment there is another service that you need to fetch some additional data, the browser would be required to orchestrate that, which means you're also waiting for the return trip on the first call before you can even get the secondary data. This alone makes REST far less favorable in m…
You do realize there's no reason a rest endpoint can't support doing this. My endpoints take a 'fields' parameter... and those fields can themselves be serialized objects.
Very lazy thinking. It doesn’t have types, do introspection, batching, granular caching, access control... I suggest reading the GraphQL introduction post for a start: https://engineering.fb.com/2015/09/14/core-data/graphql-a-da...
Re: REST vs. GraphQL – A search for evidence on which is better
#9Are there any performance benchmarks comparing REST and GraphQL?
They'll both be as fast as your implementation; but GraphQL will most likely have some additional overhead, likely offset with caching.
GraphQL isn't a magic bullet; you still need to implement/define how the data is returned.
Re: REST vs. GraphQL – A search for evidence on which is better
#10As someone who's worked with both approaches, at all levels of the stack (both backend and frontend), I think the paper (at least, its abstract) is missing the point.
While I do "feel" faster when working with GraphQL, I think the main benefit is that it abstracts away the busywork of transferring data between frontend and backend.
Writing a backend becomes more about describing what data is available, on what terms, how it fits together, and the operations you can do on it (mutations). Gone is the busywork of writing routes, handling CRUD in a zillion slightly different ways, etc.
On the frontend, Apollo-client lets me just write my app, not having to handle data-fetching, loading & caching for the zillionth time. I need an additional field? Just add it to the query! No need to get everyone involved.
Of course, there are traps you can easily fall into with Apollo's caching, N+1 queries on the backend, etc. But in my experience, while you do have to "drop down a level" sometimes to fix these, you spend most of your time at the "higher level".