GraphQL vs REST: обзор

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

Translate into another language.


Big_Shark 82 points
atygaev.mi 16 points
Join to translate! If you already have a 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

Includes start off with the best of intentions, but can grow to be a bottleneck in a REST API, with unwieldy queries happening against the data store. GraphQL not only removes this design question, but forces the include approach, and forces you to consider efficient means of fetching this data.

This is a big win for GraphQL, as forcing the include approach, and forcing efficient "Mega Includes of Doom", the GraphQL will be both efficient and consistent. Trying to make a REST API be include-only would be bizarre and unusable, so consistency will never work there.

GraphQL will not help with your database queries, so you still need to fine tune those indexes and cache fragments of the data intelligently. If you skip this, clients will surprise you. At a previous job we had a poorly-tuned mega include from the iOS app taking about 20s+ to respond, which was bloody terrifying. We almost just had them curl down a latest.sqlite to process locally.

Scoped Includes Suck in Both

Using that trip example again, a client may be including passengers but realize that includes historical passengers. Don't want to see people who left the carpool? The client has to iterate through passengers locally, removing any models where model.status != "active", which is a waste of processing on the client side.

The REST way to do this would be to use /passengers?trip=123&status=active which is obviously more flexible, but clients will skip this due to the extra requests required.

With client-side filtering being a poor choice, and the extra request not being ideal, REST API developers are often forced to add a new include: /trips?include=activePassengers. These are tough to pre-empt, so I was hoping GraphQL could help clients define their own scopes, filtering these includes to be the appropriate data themselves, which would help identify the scoped includes the API should add as convenience methods.

It seems like GraphQL doesn't help API developers in this instance, but there does seem to be talk of adding @filter to do this in the future.

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