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.
I love this channel because of how clear concise and concrete it is. What's really impressive to me is how he managed to learn to write backwards for almost 10 minutes.
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.
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.
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.
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.
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!
Excellent explanation. The video was concise, easy to understand & I loved the way you introduced us to both of your "colleagues" and then telling us who they were. All in all 10/10 video.
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!
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.
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.
Great explanation! So even though I am making a query one single time when using GraphQL I assume it is still fetching the data in the resolvers which also would take some time. So bottom line GraphQL only facilitates developer experience by providing a single endpoint but doesn't do much with performance, is that right?
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.
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
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
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.
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".
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?
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
5 місяців тому
you can, but every API implements it slightly differently, so while for your own app this could work, this breaks down for a public API where consumers cannot be aware of all your custom API features hidden behind random query params
the first statement - REST has no relation to HTTP. the second statement - REST is not for JSON or XML. It's for getting required resources for the client in the way the client can utilize them. f.e. we can create REST over grpc. Or GraphQL. Or JSON over HTTP. REST is something abstract that many "programmers" do not understand. Or make false assumptions.
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?
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 ;)
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.
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.
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.
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.
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.
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.
@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!
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.
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
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
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.
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.
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.
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
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
rest (json apis) vs GraphQL (or falcor, lol) vs REST (actual rest with hypermedia). Poor hypermedia, it doesn't even get to be in the discussion and it's the best option
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…
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.
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.
I love this channel because of how clear concise and concrete it is. What's really impressive to me is how he managed to learn to write backwards for almost 10 minutes.
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.
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.
Your explanation is lot better than this IBM guy
Your explanation is much clearer. Thanks
You forgot about costs graphql is expensive to maintain
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.
It would be really great to hear pros and cons of each as well. Would appreciate it if you can provide that info too.
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.
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!
Excellent explanation. The video was concise, easy to understand & I loved the way you introduced us to both of your "colleagues" and then telling us who they were. All in all 10/10 video.
This guy is my favourite IBM presenter....by far . This one was good.
And he is also a beer expert!
thank you for that helpful comparison.. to my understanding REST is also Protokoll agnostic.. despite probably beeing widely implemented on HTTP
Best explanation for REST vs GraphQL
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!
I thought I recognised him 😂
Excellent video, I really like the side by side comparison, no idea how that works (writing on a board while facing a camera) 😂
Best simplified explanation
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.
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.
Does GraphQL add possible risks like possible high server load or a kind of SQL injection?
What about schema changes, is there a versi9ning?
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.
My gosh love your explanation, now I clearly get the idea of graphql is
I already knew it. But still the best explanation in simple words.
This man's handwriting backwards is better than mine forwards.
They almost certainly flipped the video.
But how did he do it? Is he standing in front of a glass panel?
Great explanation! So even though I am making a query one single time when using GraphQL I assume it is still fetching the data in the resolvers which also would take some time. So bottom line GraphQL only facilitates developer experience by providing a single endpoint but doesn't do much with performance, is that right?
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.
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
My beginner brain can understand this. Thank you!
Oh man, hello Cambodia friend from Vietnam, your video you sing Final Masquerade is awesome 👍
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
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.
I enjoy your Brewlosophy videos as well as these. Keep up the good work.
Can we expect video related to how to use graphQL using as wrapper on Rest in future
I had that implementation in my project. We have created wrapper over rest using graphql
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".
Please make a video about REST vs WebSocket.
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?
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
you can, but every API implements it slightly differently, so while for your own app this could work, this breaks down for a public API where consumers cannot be aware of all your custom API features hidden behind random query params
Love your explanation, Martin! Thank you so much
I solved the file formatting problem, as well as the transport and communications issues.
Just waiting to commit to code.
the first statement - REST has no relation to HTTP.
the second statement - REST is not for JSON or XML. It's for getting required resources for the client in the way the client can utilize them.
f.e. we can create REST over grpc. Or GraphQL. Or JSON over HTTP.
REST is something abstract that many "programmers" do not understand. Or make false assumptions.
thank you for the best explanation so far :)
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?
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 ;)
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.
Amen to that! With restful ODATA, you can pretty much get the data you want filtered the way you want.
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.
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
@@simonsimonian8306 ODATA isn't REST anymore.
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.
He didn't mention GraphQL subscriptions. How does REST provide a stream of data?
GraphQL uses websockets under the hood for subscriptions. GraphQL dis not invent anything, websockets is just http
WebSocketUpgrade
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.
Martin, Excellent video as always!
Thanks for the video sir....
why not just take the complex data, put them into services and turn it into one rest api endpoint?
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.
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.
@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!
Nicely explained, thank you very much!
Very clear explanation. Thanks
Pls also explain grpc and message que technologies
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.
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
Thanks a lot for this clarification.
Can't you prevent over fetching by passing in query params?
That was a comparison btw http crud and gql. Have not seen any rest.
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
really good explain
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
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
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.
@@chaybislam This can be solved by rest api too
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.
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.
Can somebody explain how his vide was shot?
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
Bro is writing in the opposite direction while explaining complex code terminologies. Nice.
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
So you can write with your left hand and also from right to left?
No, they just mirror the video
is GraphQL more performant?
for those who are wondering how he can write backwards that good, the video is flipped horizontally xD
Yes, it only took me two days.
Any examples of an API management tool? Either for G / R 😉 currently using Postman ...
When using AWS as a backend, Appsync would be the API service for graphQL.
rest (json apis) vs GraphQL (or falcor, lol) vs REST (actual rest with hypermedia).
Poor hypermedia, it doesn't even get to be in the discussion and it's the best option
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…
Good
Can we say oDATA sites between REST and GraphQL.?
Probably not exactly. It tried to cope with some shortcomings of REST, while also seeming to sacrifice some REST foundations, right?
Does anyone noticed that he had to write everything backwards?
how he is writing in mirror image from right to left 🤨🤨🤨
the person is left handed or right handed?
See ibm.biz/write-backwards
How is this guy writing everything in invert and that too using left hand!!!
Search on yt about this, inverted glass writing board system lime something
Gonzalez Maria White Nancy Rodriguez Angela
My only question is How is he writing with the camera facing forward and it's not reversed !?
See ibm.biz/write-backwards
Neither, HATEOAS is the better than either of those for 95% of cases. There are some corner cases that GraphQL is better.
I spent the first minute buzzing out about how this backwards writing is going on
Please, guys, we are still struggling to get rid of soap, we don't need another clone...
hi is he writting backwards?
Timo responded in another comment, the video is likely mirrored before uploading so everything looks right to us.
BIg ups
pls someone tells my how is he writing on the board
See ibm.biz/write-backwards
Hey doesn't this guy make beer?
Martin Lisa Perez Laura Lee Sarah
any chance I get a job in your company
Wilson Eric Robinson Dorothy Miller Christopher
How does OData play along? Isn’t that a way to query the restful http get request?
my g
Garcia Lisa Lopez Donna Jones Brenda
Johnson Michael Perez Donald Lopez Laura
Garcia Linda Anderson Edward Thompson Susan
Thompson Amy Hernandez Sarah Lee Amy
And tbh, graphql doesn't look meat at all
Just casually writing backwards huh??
You have to start this video answer: GraphQL
¬¬
lol
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.
I agree.
Another Useless talk.
More impressed by your backward writing capabilities but thank you for the overview.
Thanks! But search on "lightboard videos" for more.
GraphQL is for mobile developers who are too stupid to understand promises.
That's why it is only used in mobile environments, he!? :head_bang:
Please pick a lane......