GraphQL vs REST: Which is Better for APIs?

Create, manage, secure, socialize and monetize APIs with IBM API Connect → www.ibm.com/products/api-connect
What is a REST API? → ibm.biz/what-is-REST
If you're a developer, you're probably familiar with REST APIs, but there's another query language for APIs that you should add to your programming toolkit: GraphQL. In this video, Martin explains the two different approaches these frameworks take for building APIs and compares their strengths and weaknesses. Spoiler alert: It's not an either/or choice, and it's worth knowing both approaches and applying them where it makes the most sense.
Read SmartPaper to learn how to unlock the full potential of your APIs → ibm.biz/BdMpX6
Sign up for a live demo of API Connect, IBM's API management solution → ibm.biz/BdMpXU
Try IBM API Connect free for 30 days → ibm.biz/BdMpX5
#restapi #graphql #query

[@InfoSecGSO]

I've got to say, that not only is this is the best breakdown of REST vs GraphQL that I've come across, but also, the best high-level overview /explanation of GraphQL in a concise context.

[@htk0002]

GraphQL simplifies API building because you don't have to create custom endpoints for every single scenario. You just define the schema and thats it, you can query what ever you want. Imagine you're building a house, and you need to order materials from different suppliers. With REST, you'd have to order each material separately, and each supplier would give you a fixed set of materials, regardless of whether you need them all or not. With GraphQL, you can specify exactly which materials you need, and each supplier will only give you what you asked for, reducing waste and improving efficiency.

[@dhruvangdave3695]

But it won't be more reliable use in such applications where we want full controller over what details we are providing... For that Rest will be more suitable.

[@jasper5016]

Your explanation is lot better than this IBM guy

[@charlesclayman3909]

Your explanation is much clearer. Thanks

[@elijahmalewo1683]

You forgot about costs graphql is expensive to maintain

[@midophriya3657]

if you want to REST api same as GraphQL fetch, you have to create a request with data sql in it. ofcourse, it is not safe but you have to filter the sql. drop, delete, update, insert and etc are not allowed.. only select will allowed.

[@amsimun]

thank you for that helpful comparison.. to my understanding REST is also Protokoll agnostic.. despite probably beeing widely implemented on HTTP

[@donaldduck682]

It would be really great to hear pros and cons of each as well. Would appreciate it if you can provide that info too.

[@Steven26789]

Best simplified explanation

[@MrThurobrand]

I enjoy your Brewlosophy videos as well as these. Keep up the good work.

[@jstevh]

Thanks! Caught me up. When was paid to code in ancient times was arrival of XML was the big deal. I love XML. Now got info on the new stuff. Ok.

[@valerielampkin7718]

Martin, Excellent video as always!

[@paultaylor9963]

The final project in my bootcamp involved working with GraphQL. I could definitely see the benefits and enjoyed working with it, but it was probably overkill for what I was doing at the time.

[@MaulikParmar210]

Until you start with existing rest tooling and enormous support in almost every stack, graphql seems like a dream that doesn't come true when it comes to practical solutions. For starters, FB, where it originated, took more than 5 years to transition and few more until it became mature. But then they always have mutating endpoints effectively against fixed schema philosophy. No framework is perfect!

[@AmmarTheTrainer]

Best explanation for REST vs GraphQL

[@jaimedan2358]

Thanks a lot for this clarification.

[@thomaspotterdotexe]

My gosh love your explanation, now I clearly get the idea of graphql is

[@tyronefrielinghaus3467]

This guy is my favourite IBM presenter....by far . This one was good.

[@ptdive]

And he is also a beer expert!

[@awakenwithoutcoffee]

thank you for the best explanation so far :)

[@nicklaspillay7923]

Excellent video, I really like the side by side comparison, no idea how that works (writing on a board while facing a camera) 😂

[@smrutikantnayak3652]

Hey Mate thank you for this lesson. If we consider the performances of both REST and GRAPHQL, which is faster in terms of providing responses if we aren't worried about network call latency. If I understood correctly that graphQl is another layer that we are adding after fetching data from the sources. I mean we are adding probably a presentation layer inside the logic before passing the response data to the client. I know thats the requirement of the client, but can't we achieve the same in REST? Or we should only and only consider GRAPHQL in case where we have to collect data from various sources and bring it to be in a desired format that the client needed?

[@julienwickramatunga7338]

Nicely explained, thank you very much!

[@ifeanyiilonze5485]

I don't see anything fancy about graphql. Cos with with rest, you can still return the specific data the client wants. It all boils down to how you write your code

[@sreekanth850]

With exact paylod or query string i can get precise output data from a rest endpoint. So why should i go for graph ql with 10x overhead of implementation and maintenance?

[@olafschermann1592]

Does GraphQL add possible risks like possible high server load or a kind of SQL injection? What about schema changes, is there a versi9ning?

[@LawZist]

Very clear explanation. Thanks

[@shubhamdas6519]

Thanks for the video sir....

[@Stopinvadingmyhardware]

I solved the file formatting problem, as well as the transport and communications issues. Just waiting to commit to code.

[@antonivashchyk2021]

That moment when you've known Martin as a beer bowler for several years and now realize he is a software engineer 😁. Thank you for the good explanation!

[@pharmajoe990]

I thought I recognised him 😂

[@axelrod-_-]

really good explain

[@user-hw4td5zc1g]

ok i have a question what if the user contains millions of data and you fetch data only in 1 request i think thats bad practice we only want to use pagination for requesting another data when the user scrolls infinitescrolling

[@MasayaShida]

My beginner brain can understand this. Thank you!

[@peterdo4652]

Oh man, hello Cambodia friend from Vietnam, your video you sing Final Masquerade is awesome 👍

[@pankaj16octdogra]

Pls also explain grpc and message que technologies

[@vengateshvaidyanathang550]

Can we expect video related to how to use graphQL using as wrapper on Rest in future

[@ramdafale]

I had that implementation in my project. We have created wrapper over rest using graphql

[@dirkp.6181]

Honestly I doubt that this makes sense. To hide REST under GraphQL leaves all possible disadvantages of REST in the given solution. GraphQL is not and never was a _replacement_ or _successor_ of REST. As said, the GraphQL layer would have to deal with possible disadvantages and could not play its strengths. If used as integration layer over some/many REST APIs, over-fetching issues and lack of filtering and other stuff cannot be vanished and therefore remain. What you want to "wrap" is your data model or data source - even though I wouldn't exactly call it "wrap", but "access".

[@ErikWillekens]

It is hard to understand the downsides of GraphQL aside from it's complexity - The question I have though is if it is suitable if you have a complex set of interrelated tables which are organised in a sql database yet follow the structure of graphs.

[@ifeanyiilonze5485]

For instance, if you need to retrieve name and age from a database using rest, you simply fetch data from a data source that has a lot of fields in them including the name and age and all you have to do is extract the name and age from it

[@ryanshannon7703]

I've worked at companies that do this and I got paid *A LOT* to optimize their application. "Oh, you're retrieving 50+ columns because the UI needs these 4 columns? STOP DOING THAT!" I learned quite a bit from that company and their methodology, though, so that was great skill builder for me. Now that I'm elsewhere and we're planning on integrating multiple business units into an uniform GUI, I'm definitely interested in pursuing this. There were countless times where over 1 gig of data was being retrieved just to pare it down to maybe 20 or 30 MB for the result set on the UI.

[@rjwhite4424]

Can't you prevent over fetching by passing in query params?

[@rizkygabriel7587]

Please make a video about REST vs WebSocket.

[@SpinnedRock]

Any examples of an API management tool? Either for G / R 😉 currently using Postman ...

[@allanbengco670]

When using AWS as a backend, Appsync would be the API service for graphQL.

[@SamWestonJ]

from my reading of the graphql docs, blog explanations, and now youtube presentations, i guess you do get a single endpoint, but the server still needs to talk to every data source to combine and return relevant results. i'm not sure how this necessarily makes anything easier than just writing a well thought out REST API. Complex data appears pretty expensive to implement with graphql, unless I'm misunderstanding everything I just got done reading, whereas you can just combine and filter those resources with REST in a pretty straightforward fashion.

[@shriramsakthivel2851]

Exactly this is what Im thinking of right now. Im just getting started with graphql, created a REST api server and implemented a layer of graphql on top of it. I think so, there may be some more features or so associated with graphql🤔🤷🏻, as companies like netflix, facebook, etc., are using graphql. Just I wish somebody could get me up with the leverage of using graphql

[@sram666]

That was a comparison btw http crud and gql. Have not seen any rest.

[@hmlchy]

As an automation/integration dev, I love Rest over Graph, graph increases unnecessary development time for the end user imo. Also Rest is just easier to understand looking at the documentation. However, graph is efficient for the platform, that's why large corporations are embracing it.

[@dirkp.6181]

That seems to be an under-complex view of the problem. If one's working with rather simpler models and clients where over-fetching is not a problem for whatever reasons, REST maybe fine. However, if it comes to complex data structures and manifold requests over the schema, GraphQL comes to rescue. Besides traversing the schema, already simple operations like client side sorting, filtering, paging are not natively supported and honestly pain in the ass problems with REST to solve, while leading "out of" REST. HATEOAS can give hints for traversing a schema, but the other problems remain and HATEOAS not only increases client comfort, but also the amount of response data. Btw, never was the question to rate one over the other as they serve (almost completely) different purposes and goals.

[@WilliamShrek]

So you can write with your left hand and also from right to left?

[@spyroninja]

No, they just mirror the video

[@davidmurphy563]

Ugh, I gave up on making a GraphQL query earlier this week - was trying to get httpx to log into a website - had it been rest I'd have done it in ten minutes. But that's my lack of familiarity with it and the fact I don't have access to the schema - just the request in my browser. I get the reasoning but I found it a pain.

[@Chatbot121]

is GraphQL more performant?

[@RichardNeswold]

He didn't mention GraphQL subscriptions. How does REST provide a stream of data?

[@whilechannel]

GraphQL uses websockets under the hood for subscriptions. GraphQL dis not invent anything, websockets is just http

[@saadisave]

WebSocketUpgrade

[@Meleeman011]

why not just take the complex data, put them into services and turn it into one rest api endpoint?

[@bekazandukeli7451]

Can somebody explain how his vide was shot?

[@timovanasten]

camera -> glass -> presenter Presenter writes normally on the glass, so on the footage the writing is mirrored. Then during editing, we can mirror the footage again so the viewers can read it

[@Stopinvadingmyhardware]

Yes, it only took me two days.

[@pusabodhisattva2183]

recently, I applied to IBM for an engineering job. They sent me a personality test, trying to test whether my personality is good to fit into IBM. So either they think some personalities are not good, or that people can't fake an answer they want to see. I now see the person in this video, having a good personality.

[@hitmanvivek]

Can we say oDATA sites between REST and GraphQL.?

[@dirkp.6181]

Probably not exactly. It tried to cope with some shortcomings of REST, while also seeming to sacrifice some REST foundations, right?

[@cleric4933]

I know this channel has the authority of IBM themselves, but the moment an instructor says "Liberries" all credentials are off the table. 4:15

[@vaibhavgupta7429]

I dont understand this advantage of having a schema and getting only the required information in graphql, we can also get the same benefit in REST APIs by using query parameters isnt it or I am missing something

[@clivejefferies]

My guess would be scalability and also the fact, that you can get data from multiple places and merge them together. Rest would require multiple requests. He does mention this

[@chaybislam]

It solve the peoblem of overfetching, if you fetch from a movies api for example you don't need the production company the date of release, you need just the name and actors.

[@Cysecsg]

@@chaybislam This can be solved by rest api too

[@TheDolmant]

These are just two different ways of querying and updating information, neither gives you more functionality. As with any form of schema or framework they make certain things easier and other things harder. In graphql for example it is extremely difficult to debug and optimise the performance of a complex query, whereas in REST it is harder to do complex queries like optionally fetching related data, batching requests or providing computed properties. You need to decide what you care about. I HIGHLY value simplicity and in my opinion anything that adds another interface to communication needs to have enormous benefits to compensate. Personally I am not a fan of graphql because I dont think it has many benefits and most of the problems it solves (like overfetching) were not high on my list of concerns to start with.

[@fuhoo5836]

the "multiple requests" comment is nonsense. you can manually make an endpoint that combines data across multiple sources and still call it restful. graphql is for frontend engineers who want to pretend that they are fullstack engineers.

[@olafschermann1592]

How does OData play along? Isn’t that a way to query the restful http get request?

[@nireshmaharaj2682]

GraphQL adds an unnecessary level of complexity to applications which will require more time and effort when it comes to debugging. Also, it consumes more resources on the server than a REST API so it won't be suitable for a company internal server because all of the network clients connecting to it are sitting idle and can do the query processing instead. From an energy efficiency point of view, it's not suitable for data centers either because again the clients are sitting idle, consuming the same power but not doing the processing locally (which may actually be faster, depending on the server load). With local caching, the strain on network resources will also be diminished although that's hardly a consideration with today's bandwidth, but still worth considering for energy efficiency.

[@felipechaves6100]

GraphQL will only require more effort to debugging if the application is highly complex or the team is not experienced in the technology. What do you mean by it expending more resources in the server? 🤔 And what you mean about the clients sitting idle? How’s that different from REST? Imo you should use graphQL when you have complex queries and/or multiple data sources, it’s also good for mobile applications where bandwidth is a concern. You do lose on HTTP cache tho, so you need to test if the bandwidth gain is worth it or not.

[@dirkp.6181]

@Niresh Maharaj: As explained earlier, this explanation is completely wrong and expresses a fundamental lack of understanding, what GraphQL is, what the conceptional differences to REST are and where and when either of these have their advantages. Never was either of these meant as replacement or successor of the other and therefore treating them a just interchangeable, as the comment implies, is plain wrong. Btw, also the assumptions drawn considering "efficiency" in different aspects are "pseudo-clever", seem overly generalized, weird and misleading. - Think yourself: Facebook only introduced and still uses GraphQL to heat up their server farms?! Others do so too... Sorry to be so straight, but the comment is in almost ever aspect nonsense!

[@segus_faultise]

BIg ups

[@chswin]

You can bury graphQL with odata both promise a simplistic interface to the consumer with increasing complexity on the backend.. by time you organize your data, indexes and provide an authorization layer it become a jumbled mess…

[@ericbersan6557]

pls someone tells my how is he writing on the board

[@IBMTechnology]

See ibm.biz/write-backwards

[@nikhiltokas4206]

Bro is writing in the opposite direction while explaining complex code terminologies. Nice.

[@neel75]

the person is left handed or right handed?

[@IBMTechnology]

See ibm.biz/write-backwards

[@Glicerol]

Graphql schema is difficult to maintain with a lot of repetition for input and output types, it is an interesting idea but very poorly implemented. And actually, with the REST you can achieve the same effect using query parameters, so no real benefits ;)

[@Dmytro-kt3fr]

it depends. I m trying the hasura graphql to get rid of maintenance actually and simplify(almost get rid of) the cross department communication. We have a need in general data access api for the gold layer of deltalake architecture. And sql endpoints to databricks are crazy money, writing apis is hell (cos no reqs, no people, no time) and its almost perfect If money for non direct costs (infra maintenance, dev efforts, lack adequate product and fe reqs, tons of stakeholders that do not want to talk, rapid dev needed) are much larger then cost of pure scaling of solution - it may be a wise option I liked the hasura concept, because you have cruds autogenerated, you have explain for each request and things like filters, sorts and pagination are done ad hoc. Thing that were previously weeks of wait are now minutes. If you have smth more complex - just write sql and back it up with gql endpoint. You need expose rest instead of gql - 2 click here you go. New db - here you have an api in a min. Need smth fully customized - fApp and proxy through hasura. No crazy estimates for things that can be done in a minutes. We got quite a nice result with hasura+cosmos for pgsql(hyperscale azure or citus). But price is not for startups.

[@simonsimonian8306]

Amen to that! With restful ODATA, you can pretty much get the data you want filtered the way you want.

[@vilkazz]

Latest iteration of the schema spec do include interfaces that you can also apply in the federation mode, thus the repetition can be contained IF the backend under is composable.

[@boniedwin]

agree, graphql also just ignore anything about REST (PUT, POST, GET) in favour of just using POST, and it's only return http status code 200

[@dirkp.6181]

@@simonsimonian8306 ODATA isn't REST anymore.

[@iko089]

my g

[@MarcosMelo-dr3pb]

Does anyone noticed that he had to write everything backwards?

[@benjaminhon86]

The more I use gql the more I hate it. It is only good for 1 use case that that is only READ list of dicts. Should never even do mutation in GQL

[@VaibhavSharma-zj4gk]

hi is he writting backwards?

[@rkalla]

Timo responded in another comment, the video is likely mirrored before uploading so everything looks right to us.

[@drivebuss8079]

any chance I get a job in your company

[@agdevoq]

Please, guys, we are still struggling to get rid of soap, we don't need another clone...

[@stevenstone307]

Hey doesn't this guy make beer?

[@BERTDELASPEED]

My only question is How is he writing with the camera facing forward and it's not reversed !?

[@IBMTechnology]

See ibm.biz/write-backwards

[@Edu4Dev]

You have to start this video answer: GraphQL ¬¬ lol

[@michaelholopainen2822]

Neither, HATEOAS is the better than either of those for 95% of cases. There are some corner cases that GraphQL is better.

[@ifeanyiilonze5485]

And tbh, graphql doesn't look meat at all

[@imukai]

More impressed by your backward writing capabilities but thank you for the overview.

[@IBMTechnology]

Thanks! But search on "lightboard videos" for more.

[@jimiscott]

GraphQL mutations are god damn awful, nonsensical and a computer science abomination. GraphQL abandons the good things about REST (PUT, POST, GET) in favour of just POST. The syntax of GraphQL is awful....why was it made to be JSON non-compliant? It would have much more sense to use JSON as the base syntax for a GraphQL query/mutation. I really to struggle to see how it got any sort of foothold.

[@TheDolmant]

I agree.

[@_diversable_]

Please pick a lane......

[@waytospergtherebro]

GraphQL is for mobile developers who are too stupid to understand promises.

[@dirkp.6181]

That's why it is only used in mobile environments, he!? :head_bang: