The most practical use case for GraphQL, and the one it was originally

designed to support, is a client (iOS or Android app, or Web app)

requesting data from a server.

REST is often the right choice when you need your data access to align
tightly to HTTP. For example, if you rely heavily on HTTP-level caching,
or if you need to represent data spread across many different domain
services which use URLs to reference other data.

GraphQL is often the right choice when network speed and latency is
the primary concern and data isn't spread across different domains
but is instead centralized to one product. In this case a single network
request can load many different kinds of resources at once, and selectively
include only what that client needs. Particularly on mobile network
connections, this can be a dramatic performance improvement. However
caching data may require more sophisticated techniques.

Below are some of the usecases (problems that it solves) for GraphQL :

UseCase 1 - Fetching associated data often requires multiple

HTTP calls. [AppManager Usecase – No, May be yes]
REST APIs are built on the principle that every endpoint should return only one type
of resource. For instance, when fetching GET /products/1, you should receive the
information for product 1 (i.e. title, description), but nothing more. Following this
principle means that if you want a product’s variants, images, and metafields you
would end up having to do at least four HTTP calls.

UseCase 2 - Apps receive way more data than they actually

need. (Over fetching and Under fetching problems).
[AppManager Usecase – No/May be]
To solve the above problem, we end up breaking away from “true” REST APIs by
embedding certain associations to certain end-points when the need arises. For
instance, GET /products/1 now returns information about the product, but also its
variants, images, and options. Ultimately we end up with one-size-fits-all responses
where you cannot request less nor more than what we give you.
UseCase 3 - We don’t know what data an app actually needs.
[AppManager Usecase - No]
Related to the above problem, when an app requests a REST endpoint, we have no
way of knowing if they are actually using every piece of data we return. It’s as if you
did a SELECT * to a SQL database. This is problematic because when we need to
make breaking changes like remove an attribute from a response it’s near impossible
to know who it will affect. We know what clients call what end-point, but we don’t
know what subset of those clients are using the attribute we are trying to remove. It
is also problematic when some attributes are costly to compute. If we had a way of
knowing the app doesn’t need that costly attribute, we wouldn’t need to compute it in
the first place.

UseCase 3 – REST APIs are weakly typed (no schema),

While GraphQL is not and Also Helps maintain up-to-date API
documentation.
[AppManager Usecase - Yes]
This means apps rely on documentation (in the case of REST) that tend to fall out-of-
date or worse are incomplete. Everything in GraphQL is typed and everything you
want to expose is part of a schema. Clients craft queries and get back only what they
requested. Not only does this solve the over-fetching data problem, it also means as
an API provider, we know exactly what each app is using, making it easier for us to
evolve our API over time.

Usecase 4 – Fetching data from multiple datasources

[AppManager Usecase - Yes]
When you have data being fetched from variety of datasources, in the REST world,
Handling this would require an API gateway no matter what. Otherwise we would be
making a large number of requests.
Ref - https://labs.mlssoccer.com/implementing-graphql-at-major-league-soccer-
ff0a002b20ca

An visual example below

Here you can see that we have multiple UI points that require data from different
resources, all needing to be displayed co-located. These types of problems are
where GraphQL really shines.

Usecase 5 - Caching [AppManager Usecase - No]

REST APIs can leverage the browser based caching out of the box (by adding the
ETags etc) while GraphQL would need a custom caching strategies. The reason is
that unlike REST API, GraphQL GraphQL operates as a query language POSTing
against a single endpoint, HTTP is demoted to the role of a dumb tunnel, making
network caching tools like Varnish, Squid, Fastly, etc. entirely useless.
The GraphQL site seems happy to suggest the client should take care of caching on
their end.

Coursera’s journey to GraphQL, and highlight a few of our successes and failures
along the way
https://blog.apollographql.com/courseras-journey-to-graphql-a5ad3b77f39a
(1) fetch all data in a single roundtrip
(2) providing structured documentation for our APIs.

Problems which GraphQL can easily solve -

 How do we query our data efficiently when we need to hit multiple databases
and internal API endpoints?
 How do we ensure we are not over-fetching or under-fetching data?
 How do we document all of the properties associated with accounts,
balances, and currencies?
A lot of things changed since i wrote this. GrapQL has become a lot more
mature since i wrote this. There are many more reasons to go with GraphQLnow.

 Most implementations have own batch data loaders now. No N+1

DB queries anymore. For example this Python implementation of
GraphQL Graphene-Python has one.
 Apollo and Relay, the frontend frameworks became more mature, and do
things like client side caching far better.
 Community has grown significantly-> Best practices started to establish.
 There’s are really cool open source based and community drive BaaS
provider for GraphQL: graph.cool.
It also depends on the complexity of your API. I think it makes more sense for APIs
that have very varying data needs.

If your endpoints look like this:

/users/posts?sortBy=date&fields=title,description&likes_above=3

then you should consider using GraphQL

If you, on the other hand completely control the API consumer (e.g. your own SPA or
mobile app) + the requests look more like:

/users/posts/2

and the consumer will use allmost all fields returned by this request,

a REST approach might be faster and easier.

—————————————————————————————————————

I was asking myself the same question for our backend services. ..

Something upfront:

We use all the new stuff on the frontend of our SPA. (React.js, ES6, Mobx State Tree
etc.) But on the backend we decided not to use GraphQL and go with REST.

When to use GraphQL:

 The data needs of your client will change constantly maybe on a daily or
weekly basis -and this is by design!
 You use Node.js on the backend. (The best and proven GraphQL
implementation is still on Javascript). Others are mostly not well enough
tested or are changing to often.
 If you aren’t using Node.js, you are ready to write low level stuff like batch
loaders yourself.
 You are willing to accept inapt or lacking documentation.
 You are developing in an extreme form of continuous deployment,
changing and “breaking” the API on a daily or weekly basis.
For most cases: I would stay with REST.

 It’s a proven methodology of building services. This means:

o There are best practices for it.
o There are helpful frameworks for it. (e.g. in Python World: Flask or
Django RESTful)
o You get content and help easier and faster.
o You can find much more existing examples of REST APIs on every
scale. (From small service API to billions of requests)
 Implementing GraphQL on the other hand is more like hitting a moving
target. A lot of things are changing in GraphQL implementations, especially
non JS-ones.
 But an API should not depend on constantly changing libraries.. It should
be the most stable part of the system (except the DB).
 GraphQL is not solving the issues of complex and changing data needs on
the client, it’s just shifting the complexity from [client → server] to
[server→database.]
 Watch out for N+1-query problems, especially with relational databases.
You will need a piece of code for batch querying. Most current graphQL
implementations ignore this serious performance problem. Here is a nice
explanation: