Is REST tired? GraphQL a stimulant?

Based on my quick review, it seems a company should add GraphQL to their tech stack. It’s not an either/or situation.

Representational State Transfer (REST) is the architecture underlying the WWW. It scales. The REST concept is also be used to create RESTful services as an alternative to older technologies such as Remote Procedure Calls (RPC) and SOAP. REST architecture scales.

REST has some limitations and critiques. For example, few REST APIs are truly “RESTful”. The level of REST is captured in the Richardson Maturity Model (RMM). The highest level requires use of HATEOAS, see “Designing a A True REST State Machine”.

“A very strong argument could be made that if most APIs are REST-ish instead of REST-ful, and assuming that most of the conventions that we’re actually using boil down to making URLs consistent and basic CRUD, then just maybe REST really isn’t buying us all that much.” — @brandur

One claim is that REST has issues since it is misapplied:
“…“REST is intended for long-lived network-based applications that span multiple organizations” according to its inventor. This is not a requirement for APIs that serve a client app built within the same organization.” —

GraphQL was created to fill a hole in modern web API. GraphQL unlike common REST queries, describes the ‘shape’ of data to retrieve from a single end-point. The structure of that data at the end point is a black box. The host knows how to fill in the shape to create the response. Kind of like SQL (in a very rough kind of comparison): In SQL the data has a shape, the Relational Model, and the single end-point queries, declaratively describe what to get from that shape. In REST when you ask for a cup you get the kitchen sink and all the cabinets.

“GraphQL is a declarative data fetching specification and query language for APIs. It was created by Facebook back in 2012 to power their mobile applications. It is meant to provide a common interface between the client and the server for data fetching and manipulations. GraphQL was open sourced by Facebook in 2015.” — GraphQL vs REST

The single endpoint is a critical distinction. To get distributed, consolidated, or nested data a REST endpoint could, of course, invoke an integration service on the backend, or use techniques such as API Chaining. in GraphQL the “integration” exists semantically on the client query. The declarative query just describes the result and the server provides it. And since the shape determines the data desired at the single endpoint, the over/under fetching of REST is avoided. The query is ‘resolved’ on the server which may invoke of existing multiple SQL, REST services, MQ, or other services. This affords natural growth of the API. In contrast a REST API grows via more endpoints and/or addition of query parameters (which could morph to disguised RPC).

Image on

“GraphQL was our opportunity to rethink mobile app data-fetching from the perspective of product designers and developers. It moved the focus of development to the client apps, where designers and developers spend their time and attention.” —

In “How GraphQL Replaces Redux” after the team started to use GraphQL they had three ‘Startling Realizations’:

  1. Most of our state management code was concerned with merging and mutating data from discrete REST resources into the right shape for our UI (reducers, selectors, actions etc.).
  2. A lot of our most complex state management was trying to manage the asynchronous nature of getting all that data in the right order for a specific route (sagas, middleware, thunks etc.).
  3. Practically everything else, UI state, worked great with plain old React state.

And, then they deleted a lot of code. A similar experience shown here: “Reducing our Redux code with React Apollo”,


  • GraphQL is not a replacement, both can be used; even “GraphQL over REST”
  • GraphQL allows less chatty communication
  • GraphQL is not perfect
  • For simple API GraphQL will only add complexity.
  • Has been proven in many production applications and sites.

Critiques of GraphQL
New technology hype hardly ever gives the true efforts and failed approaches that it took to make something work. GraphQL is no exception.

1. “GraphQL Seems Like We Do Not Want to Do the Hard Work of API Design”,
2. “Just Because Github Has a GraphQL API Doesn’t Mean You Should Too”,
a. API chaining is fix for chatty REST?
3. “Are there any disadvantages to GraphQL?”,
4. “Semantics and complexity of GraphQL”, Provides an algorithm for determining response size of a potential query.

Learning GraphQL
1. Introduction to GraphQL:
2. “A Front End Developer’s Guide to GraphQL”,
3. “The Fullstack Tutorial for GraphQL”,
4. tutorials:
5. “Five Common Problems in GraphQL Apps (And How to Fix Them)”,
6. “GraphQL Deep Dive: The Cost of Flexibility”,
7. GibHub explorer using GraphiQL:
8. “Thinking in Graphs”,
9. “Dan Schafer, GraphQL at Facebook”,

1. Prisma:
2. Apollo client:
3. Relay:
4. GraphQL.js:
5. Apollo Server:

YouTube Videos

Further Reading
1. “Is GraphQL Moving Toward Ubiquity?”,
2. “Top 5 Reasons to Use GraphQL”,
3. “GraphQL over REST at Reactathon 2018”,
4. “What are advantages and disadvantages of GraphQL, SOAP and REST?”,
5. “…And GraphQL for all?”,
6. “REST versus GraphQL”,
7. “Simplify relational logic with GraphQL”,
8. Who is using GraphQL?
9. “GraphQL is SQL for Knowledge, not Data”,
10. “GraphQL vs REST comparison – Is This Solution from Facebook Worth Taking the Risk?”,
11. “Sharing data in a Microservices Architecture using GraphQL”,
12. StarBucks use of GraphQL:
13. “Richardson Maturity Model”,
14. “2 Fast 2 Furious: migrating Medium’s codebase without slowing down”;
15. “Cartoon Guide to Facebook’s relay”,
16. “Thinking in GraphQL”,
17. The GitHub GraphQL API:
18. You don’t need a fancy framework to use GraphQL with React (All you need is a good naming strategy) :
19. “How GraphQL Replaces Redux”,
20. “Reducing our Redux code with React Apollo”,
21. The GitHub GraphQL API:
23. “The Evolution of The New York Times Tech Stack”,
24. “Designing a A True REST State Machine”,
26. “The Evolution of The New York Times Tech Stack”,
27. “Here’s my follow-up to REST is the new SOAP: let’s talk about the Original REST”,
28. “GraphQL vs REST: Overview”,
29. “Reflections on REST — FSE’17 Keynote”,
30. “A Journey Through React Apollo – Peggy Rayzis aka @peggyrayzis at @ReactEurope 2018”,
31. “Dan Schafer – GraphQL: Client-Driven Development”,
32. “A Real-World GraphQL Application in Production”,
33. “What it takes to run the world’s largest GraphQL server”,
34. “From REST To GraphQL”,