GraphQL vs REST: What's The Difference And When To Use Which?

GraphQL vs REST: they're both popular approaches to developing backend services. In this video I show you what the difference is between REST and GraphQL, how to build a basic API using either of these approaches and when to choose one over the other.

🎓 Courses:

👀 Code reviewers
- Yoriz
- Ryan Laursen
- Sybren A. Stüvel
- Dale Hagglund

🔖 Chapters:
0:00 Intro
1:37 What is REST?
2:35 Creating a REST service in Python
8:12 Issues with REST services
9:45 What is GraphQL?
11:01 Creating a GraphQL service in Python: scaffolding
14:19 GraphQL: defining types and queries
20:14 GraphQL: mutations
21:40 GraphQL: field resolvers
24:35 Limitations of GraphQL
25:56 GraphQL vs REST: when to use which?

#arjancodes #softwaredesign #python

DISCLAIMER - The links in this description might be affiliate links. If you purchase a product or service through one of those links, I may receive a small commission. There is no additional charge to you. Thanks for supporting my channel so I can continue to provide you with free content each week!

[Dpark]

You are the link I've been missing between programming theory and programming practice. I can't tell you how much you've helped me improve my programming skills. Your examples are concrete and applicable, not too simple or too advanced. Thank you.

[warpmonkey]

After developing some applications that store many millions of records, I can say that REST API's are the only way to go. The security issues around REST are easy to manage if you enforce Swagger definitions of what endpoints expose, as accidental leakage of data can be picked up through exceptions with the approved Swagger data structure.

Also, GraphQL has huge performance issues, where you can't fine tune heavily indexed database queries to speed the query like you can with REST. With REST, you know how the data will be structured, so targeted database indexes can improve query performance from 10x to 200x faster.

GraphQL may be good for small exploratory queries, but when writing a full stack application, you know exactly how the API's will be called, because you wrote the front end, so again, REST API's stand out as the preferred solution for a full stack application, or an application that consumes the APIs in a predictable way.

I would only implement GraphQL if it was necessary to have a 'Supports GraphQL' marketing line on the product home page, otherwise, for me, it is a cool but inferior technology.

There are many ways to solve the 'many API calls for REST endpoints' issue. The key with REST API's is, 'It's important to understand the intent of REST API's, so that you can break those rules in a consistent manner'.

And yes, it's almost always necessary to break the hardline REST API rules for endpoints to get an application of even medium complexity to operate at speed.

[Exirel]

> "There is no standard way of doing [controlling the fields you get]".

Aside from the fact that REST isn't a protocol so "standard" is a hard thing to define here, there are many ways to overcome this issues, and all of them are standards in HTTP and pretty natural in REST design principles:
- HTTP cache on GET request; which is always useful
- Always return empty response on PUT/POST/DELETE request, with a location header if the resource modified is at a different location
- Use content negotiation (request's ACCEPT header and response's Content-Type header) to return smaller response

Most problem with "you can't control what you get" are coming from badly designed API and a lack of understanding of what HTTP has to offer. And also, most people don't know more than type-marshalling and think their internal datamodel is the same as the returned resources.

[astronemir]

Would be interested in you talking about “database stuff” especially with how to interface with some different ones using python. Thanks again Arjan!

[BobDobalena]

After working in graphql for a year after working in rest for a ~decade, I am not even slightly sold on using graphql. Ignores how HTTP response codes work, every api call is made to /graphql, etc. I don't see a ton of scenarios. for the overfetching/underfetching problem.

[InkaStudios]

I liked the content, however I have to disagree, that is why we have the concept of DTOs inside endpoints when using restful api, because you do not send all the object, you can send a partial object, you might not be allowed to send certain fields or receive them in the request. So this precise security issue would be more from the bad design rather than restful functionality.

[jordansilke]

Great video as always! I haven't had a chance to look into GraphQL yet, so I found the summary and comparison with REST here to be quite informative.

[stvv]

Great video Arjan! Concepts were explained very clearly with nice examples! I would also love to see a video on FastAPI!

[wizardfix]

An excellent video tutorial as usual. Now, with a Flask/GraphQL/Ariadne backend, the question becomes, how to design and implement the front end, that will actually fire off the GraphQL queries and display, or otherwise handle, the results. As well as minimising database queries from the backend to the GraphQL server, requests to the backend from the frontend could also be reduced by smart caching of some kind.

[TheRadicalCentrist.]

Great video. I have the opposite conclusion. I think GraphQL works for small needs, but handcuffs you at scale. REST has more things to worry about initially, but you can control them in the end game when the requirements get nuanced and intertwined. We did extensive analysis of both for a major application, and went with REST over GraphQL precisely for the ability to maintain control at scale.

[a-rezhko]

REST + ODATA is really powerful and perfectly exposes data layer as API.

[jakefischer]

Love to see how much the channel as grown! You da man Arjan

[marookegberosamuel]

Just found your channel and I just know it's uphill from here for me. Thank you ArjanCodes! 💖

[Archfile]

This was an excellent explanation of the difference between GraphQL and REST, very nice, Thank you!

[salvaje]

When I used the api I had created for the frontend devs at our, I realized how difficult it is to use. I focused so much on the data structure and forgot about usability. I was considering migrating at least certain parts of the api to GraphQL and this video really helped me understand it. This video has helped me understand which parts are better left as REST.

[westonbarnes]

I was already subscribed, but when you said that you are nuanced people, I hit the bell button. Great video!

[MakkyNZ]

If you use ODATA for REST you typically wouldn't need to make separate calls to get related objects. e.g Author details of the Blog post. It has a keyword named "EXPAND" that your specify in the api call to do this.

[dimitro.cardellini]

There is a mistake in GQL Schema:

1. Never use [Type], because it means nullable array of nullable items of type T. The allowed values for this includes: null, [], [null] and [null, null] and so on.
Use [Type!]! -- it includes an empty list bust the null for value and items is disallowed

2. Never use Type! as return type in queries if you are not sure that the corresponding value exists.
blog(blogId: ID!): Blog -- returns Blog or null if blog couldn't be found by id

3. Never use GraphQL errors to pass business logic errors -- just because there is no way to describe the errors with the GraphQL schema.

[TheDolmant]

I enjoyed this breakdown. My personal experience with GraphQL has me putting it in the bin, probably permanently. The N+1 problem and subsequent design limitations have been such a gigantic issue that I would sooner code my own custom batch endpoint than use graphql. It is a nice idea though, I am sure it works very well for lots of applications that don't come up so hard against the limitations.

[lux-conl]

More videos like this please! I would also enjoy if you talked more about different types of databases and how to interact with them in Python :)