GraphQL vs REST: обзор

Phil Sturgeon, “GraphQL vs REST: Overview”, public translation into English from English More about this translation.

Translate into another language.

Participants

Big_Shark 82 points
Join Translated.by to translate! If you already have a Translated.by account, please sign in.
If you do not want to register an account, you can sign in with OpenID.
Pages: previous Ctrl next next untranslated
1 2 3 4 5 6 7 8 9 10

In these scenarios, GraphQL beats the pants off of REST APIs that try to hand-roll their own query language functionality, but I would suggest hand-rolling your own query language is a bad idea anyway. GraphQL gives you a query language syntax, and SDKs for your programming language to fetch the right models for that, but so do things like OData, a project with the slogan "A Better Way to REST".

This is another example of folks saying that REST cannot do something, just because many REST APIs don't do it, or because its implemented poorly by many that do. Saying that, remember that the more customisation an endpoint-based API adds to the request, the fewer cache hits are likely at a network caching level, making the REST/HTTP approach less rewarding, and forcing you down the route of the application caching and database reorganisation that GraphQL forces anyway.

If your API is highly customizable, it's another ticked box for considering GraphQL.

GraphQL Removes "Include vs Endpoint" Indecision

Another customisation consideration that comes up a lot is when to offer included relationships, and when to use another endpoint. This can be a difficult design choice, as you want your API to be flexible and performant, but includes used past the most trivial uses can be the opposite of that.

You start off with overly simplistic examples like /users?include=comments,posts but end up on /trips?include=driver,passengers,passengers.avatar,passengers.itineraries and worse.

I call this the "Mega Include of DOOOOOOM", and it is crap solution to a genuine concern, when clients strive for performance over all else. Includes are a common convention found in REST APIs, recommended in specs like JSON API, but actually bends the rules of REST a bit.

REST would call for a HATEOAS approach, which would have you make one call to the /trips endpoint, then hit "links": { "driver": "https://example.com/drivers/123" }, and again for passengers, and again for child data of each of those passengers. In this case, it would be worse than the dreaded n+1, and more like n+(2+(num passengers*2))!

Pages: previous Ctrl next next untranslated
1 2 3 4 5 6 7 8 9 10