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.

REST
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.” — https://reactjs.org/blog/2015/05/01/graphql-introduction.html

GraphQL
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 www.graphql.com

“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.” — https://code.facebook.com/posts/1691455094417024/graphql-a-data-query-language/

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”, https://dev-blog.apollodata.com/reducing-our-redux-code-with-react-apollo-5091b9de9c2a

Summary

  • 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”, https://dzone.com/articles/graphql-seems-like-we-do-not-want-to-do-the-hard-w
2. “Just Because Github Has a GraphQL API Doesn’t Mean You Should Too”, https://www.programmableweb.com/news/just-because-github-has-graphql-api-doesnt-mean-you-should-too/analysis/2016/09/21
a. API chaining is fix for chatty REST?
3. “Are there any disadvantages to GraphQL?”, https://stackoverflow.com/questions/40689858/are-there-any-disadvantages-to-graphql?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa
4. “Semantics and complexity of GraphQL”, https://blog.acolyer.org/2018/05/21/semantics-and-complexity-of-graphql/ Provides an algorithm for determining response size of a potential query.

Learning GraphQL
1. Introduction to GraphQL: http://graphql.org/learn/
2. “A Front End Developer’s Guide to GraphQL”, https://css-tricks.com/front-end-developers-guide-graphql/
3. “The Fullstack Tutorial for GraphQL”, https://www.howtographql.com/
4. Graphql.com tutorials: https://www.graphql.com/tutorials/
5. “Five Common Problems in GraphQL Apps (And How to Fix Them)”, https://medium.freecodecamp.org/five-common-problems-in-graphql-apps-and-how-to-fix-them-ac74d37a293c
6. “GraphQL Deep Dive: The Cost of Flexibility”, https://edgecoders.com/graphql-deep-dive-the-cost-of-flexibility-ee50f131a83d
7. GibHub explorer using GraphiQL: https://developer.github.com/v4/explorer/
8. “Thinking in Graphs”,
9. “Dan Schafer, GraphQL at Facebook”, https://www.youtube.com/watch?v=Ey3BtXDO2UM

Implementations
1. Prisma: https://twitter.com/GraphQL
2. Apollo client: https://www.apollographql.com/client/
3. Relay: https://facebook.github.io/relay/
4. GraphQL.js: http://graphql.org/graphql-js/
5. Apollo Server: https://www.apollographql.com/server
6.

YouTube Videos
*TODO*

Further Reading
1. “Is GraphQL Moving Toward Ubiquity?”, https://nordicapis.com/is-graphql-moving-toward-ubiquity/
2. “Top 5 Reasons to Use GraphQL”, https://blog.graph.cool/top-5-reasons-to-use-graphql-b60cfa683511
3. “GraphQL over REST at Reactathon 2018”, https://www.slideshare.net/sashko1/graphql-over-rest-at-reactathon-2018
4. “What are advantages and disadvantages of GraphQL, SOAP and REST?”, https://www.quora.com/What-are-advantages-and-disadvantages-of-GraphQL-SOAP-and-REST
5. “…And GraphQL for all?”, https://apihandyman.io/and-graphql-for-all-a-few-things-to-think-about-before-blindly-dumping-rest-for-graphql/
6. “REST versus GraphQL”, https://blog.pusher.com/rest-versus-graphql/
7. “Simplify relational logic with GraphQL”, https://scaphold.io/community/blog/querying-relational-data-with-graphql/
8. Who is using GraphQL? http://graphql.org/users/
9. “GraphQL is SQL for Knowledge, not Data”, https://react-etc.net/entry/graphql-is-sql-for-knowledge-not-data
10. “GraphQL vs REST comparison – Is This Solution from Facebook Worth Taking the Risk?”, https://www.netguru.co/blog/grapghql-vs-rest
11. “Sharing data in a Microservices Architecture using GraphQL”, https://labs.getninjas.com.br/sharing-data-in-a-microservices-architecture-using-graphql-97db59357602
12. StarBucks use of GraphQL: https://twitter.com/davidbrunelle/status/961103308957147136
13. “Richardson Maturity Model”, https://martinfowler.com/articles/richardsonMaturityModel.html
14. “2 Fast 2 Furious: migrating Medium’s codebase without slowing down”; https://medium.engineering/2-fast-2-furious-migrating-mediums-codebase-without-slowing-down-84b1e33d81f4
15. “Cartoon Guide to Facebook’s relay”, https://code-cartoons.com/a-cartoon-intro-to-facebook-s-relay-part-1-3ec1a127bca5
16. “Thinking in GraphQL”, https://facebook.github.io/relay/docs/en/thinking-in-graphql.html
17. The GitHub GraphQL API: https://githubengineering.com/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) : https://edgecoders.com/you-dont-need-a-fancy-framework-to-use-graphql-with-react-b47b436626fb#.hu577b1ln
19. “How GraphQL Replaces Redux”, https://hackernoon.com/how-graphql-replaces-redux-3fff8289221d
20. “Reducing our Redux code with React Apollo”, https://dev-blog.apollodata.com/reducing-our-redux-code-with-react-apollo-5091b9de9c2a
21. The GitHub GraphQL API: https://githubengineering.com/the-github-graphql-api/
22. https://twitter.com/GraphQL
23. “The Evolution of The New York Times Tech Stack”, https://stackshare.io/posts/evolution-of-new-york-times-tech-stack
24. “Designing a A True REST State Machine”, https://nordicapis.com/designing-a-true-rest-state-machine/
25. https://twitter.com/GraphQL
26. “The Evolution of The New York Times Tech Stack”, https://stackshare.io/posts/evolution-of-new-york-times-tech-stack
27. “Here’s my follow-up to REST is the new SOAP: let’s talk about the Original REST”, https://medium.freecodecamp.org/follow-up-to-rest-is-the-new-soap-the-origins-of-rest-21c59d243438
28. “GraphQL vs REST: Overview”, https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/
29. “Reflections on REST — FSE’17 Keynote”, https://www.youtube.com/watch?v=6oFAmQUM8ws&feature=youtu.be
30. “A Journey Through React Apollo – Peggy Rayzis aka @peggyrayzis at @ReactEurope 2018”, https://www.youtube.com/watch?list=PLCC436JpVnK3xH_ArpIjdkYDGwWNkVa73&time_continue=1&v=fCXYA3lZTbo
31. “Dan Schafer – GraphQL: Client-Driven Development”, https://www.youtube.com/watch?v=vQkGO5q52uE
32. “A Real-World GraphQL Application in Production”, https://www.youtube.com/watch?v=6bRFElKG0a8
33. “What it takes to run the world’s largest GraphQL server”, https://www.youtube.com/watch?v=nOYyix0NpvY
34. “From REST To GraphQL”, https://www.youtube.com/watch?v=ntBU5UXGbM8&t=690s

Leave a Reply

Your email address will not be published. Required fields are marked *