GraphQL vs REST: what you need to know

It's time to explore together the wonderful world of GraphQL and REST. Let's take a look at what GraphQL is, what REST is, and when you should choose one over the other.

What is the need they exist to serve?

Why and how to use them?

And we'll see the four advantages GraphQL has over the REST-full style of APIs.

And then the 2 major disadvantages that you have to watch out for if you use or create an API in GraphQL.

But before that, let's start at the beginning: 

What is GraphQL?

GraphQL is a way to create web APIs. I've already made a video talking about APIs in general, and REST web APIs in particular.

REST is the standard way to organise an API. But GraphQL is challenging that position of dominance.

To understand GraphQL, and to understand why it exists, I will be comparing it with the way REST APIs are organised. Because GraphQL is in part a response to the problems that REST has.

[goldenboy_]

This is a wonderful video. For months I’ve been using a GraphQL API but I never took a step back to determine WHY I was using it and the advantages of using it over REST API

[linonator]

Definitely a useful video ! Happy I watched this, very clear and concise with no fluf

[Warley]

I'm Brazilian and I thought the video was fantastic, congratulations.

[philipfwilson]

Very good clean, quick video.. thanks for the refresh

[nomad]

By far, the best video about GraphQL! Thanks a ton!!

[annbui]

Love the details info you provided!!! Keep up with the great work💪🏻

[jefvanderavoirt]

Only 2.9K views? Great video, thanks!

[stefan]

Very interesting video!
A small remark: the sound attached in the explanations (I don't have a term) is a little too loud in tune with the voice.
Otherwise... I hope the result is worth the effort :)

[gauninha]

Great lesson from Mr. Robot himself hehehe
Thanks!

[caerulemusic]

hey dude just some constructive criticism - i think the sound effect volume is too high in the mix. it's distracting. thanks for the vid!

[lydstyl]

Merci pour tes vidéos de qualité ! Je pense qu'il y a un autre inconvenient à GraphQL : on est, sauf erreur de ma part, obligé (ou presque) d'utiliser une librairie en backend et aussi en frontend comme par exemple Apollo server et Apollo Client. Cela rend moins accessible l'API et rend la maintenance plus compliqué sur le long run (mise à jour d'Apollo par exemple).

[igboanugwocollins]

I like your teaching... You just got a subscriber

[manofculture]

Just trying to really understand GraphQL's benefits. Can't you use REST to do exactly what GraphQL does? Doesn't that just depend on how you've built the API?

I can build a /user endpoint that takes the required columns as a parameters, and returns only the needed columns and relationships.

Not sure what GraphQL does that REST can't aside extra documentation. Could someone explain?

[MegaBaellchen]

OpenApi is the defacto standard for rest api documentation

[dxhelios]

@Kodaps Really? Let me count mistakes:
1. REST and RESTful API and REST web APIs are different things
2. "where each row represents an object" - why? who decided this? you? Somehow you went from API approach to ORM? And the only way to do ORM is object-row mapping in your context. That is not actually the case.
3. And you say it loudly REPRESENTATIONAL state transfer. You transfer REPRESENTATION, not the whole state, because, where there are relations, state also includes relations. It is just logic.
4. REST purpose is not to communicate items, its purpose is to communicate representation of the state of an object. Why you need to add some flavor to interpretation?
5. Why I should care about relationships if I sometimes care just about property in the state of the object? You present it like it always important to work with relationships. IMHO in mutation scenarios, relationships are less important than just mutating the state of a known object (which ID is already known). I do not need to navigate through relations to update state at all! The thing that you present as advantage are virtual and it is not always important and can be easily covered by REST API and sufficient API management
6. "We define response shape on a client". This was solved years ago with OData and OData is a standard for REST. Yes, you can define the shape of the response.
7. Strong typing is viable as much as tooling supports it. For REST APIs we have strong tooling, for GraphQL it is missing.
So overall I do not see any significant advantage of GraphQL. In some teams differences may play positive role, in others they will make no difference, in others they may introduce unnecessary bottlenecks. I do not see GraphQL as viable alternative to simple RESTful API with API management.

[mirzasisic]

All right, here's the signal for YouTube's algorithm.