What Is GraphQL? REST vs. GraphQL
HTML-код
- Опубликовано: 29 сен 2024
- To get better at system design, subscribe to our weekly newsletter: bit.ly/3tfAlYD
Checkout our bestselling System Design Interview books:
Volume 1: amzn.to/3Ou7gkd
Volume 2: amzn.to/3HqGozy
ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.
GraphQL was designed by Facebook to solve over fetching problems aggregating data lakes containing overlapping/duplicate data sometimes from uncontrolled 3rd parties for a global service that processes millions of write and read queries per hour 24/7. It can be useful for taming bloated data lakes or getting more out of old systems. If you are building a new system ground up you probably won't need it unless your data models are very complex with giant records, but probably a just bad design.
I have seen startups fail because they wasted time and money on GQL when they didn't really need it or the complexity it adds made getting the service to work well difficult or fragile. Don't engineer like FB and Google until you are that big and make a system that gets the objective work done well and code it so it can grow and modularize later if needed.
It always seemed to me that graphQL is only worth it beyond a certain level of complexity and when you're dealing with an extremely varied array of clients each needing different fields, different data, different implementations. This gives the clients maximum flexibility and you move a lot of the complexity to the client side. If you don't want to implement hundreds of endpoints and API's you just create the graphql middleware, schemas and you're good to go.
But security is a big risk, you need to make sure sensible data is not being returned in any way, not to mention you introduce a lot more possibilities for bugs.
Exactly, for me it's pretty clear that the main use case of graphql it's one where you have as you said a varied array of clients who evolve independently from your api implementation and you have a complex data model that otherwise requires multiple endpoint implementations. Only in this case the tradeoff between this extra layer of complexity and cost it's worth for a business.
very clear explanation!
instantly subscribed!
amazing animations, a very clear explanation, thank you!
Very Well explained.
5 star video
I liked the nod to the SpaceX Dragon capsule in the GraphQL schema 😏
great breakdown, thanks
Thank you! Great video.
So where to use Graphql?
Where are they better to use in terms of safety and cost?
Miller Cynthia Taylor Mary Davis Daniel
I have realised that top companies like Meta & Google only create solutions for their heavy workload. Small teams with a 25k user base should not bother trying to implement what companies like Facebook created. It is highly unnecessary. I have a 2k daily user base app. I don't need GraphQL
Nice video!
Hmm so like it's a tool to make queries, so it's for smaller companies who can't afford many programmers. Or maybe even none. That's cool I guess. But why would any company want that, who can actually afford developers? It makes it more difficult to customise products or services. You want to do something that GQL (or other) has not implemented? Forget it, follow the boxes of the master, and pay us for it too mmmuuuuuhahahahahahahahahaaaaaaa!! 😉
Why not simply run SQLike query at frontend 🤣 GraphQL ~= SQL ?
Walker Kenneth Jones James Martin Michelle
Hall Michelle Smith Sarah Martin James
enligsh is 困难 to understand
Probably the most easy to understand video I've seen about differences between REST and GraphQL. Thank you!
Nicely explained! In ten years down the line, GraphQL will be identified as an anti-pattern in the industry. Though it may seem very easy and attractive initially, it would become more complex once the schemas become big. REST is simple and easy to implement. The only caveat with REST is multiple api calls to backend. The better and a traditional approach should be by introducing orchestration services for any frontend that requires more complex data models from the back end.
Can you give an example of orchestration services for frontend which will circumvent GraphQL? Your comment was interesting for me.
probably better if you turned off your camera. i got a little distracted😅😅
GraphQL seems like an ambitious & interesting idea, as well as a horrendous footgun. Thanks for the wonderful explanation as always!
In my company we use GraphQL as primary API and it is not good. We are planning to move everything to REST api. Knowledge gap is the biggest trade off for us. New talent is having hard time wrapping their head around GraphQL queries. REST is pretty simple and easy to understand thus less development time for all the developers.
same here. biggest mistake we've ever done. REST API is way more mature. when graphql reaches that point then we might re-consider.
Might be a bit of devs fault. New hire or not, graphql for FE is something you learn in a couple of days if you have some experience
@@TheVasx in our case, it wasn't the knowledge gap but the performance. all graphql requests are POST, therefore is really hard to cache them. We thought for bigger project would be better, but that was proven to be a naive thought.
@@alexkey9372 oh yea, if you depend on caching its all a big clusterfuck 🔥🔥
@@TheVasx Agree. And sooner or later, caching will come into the picture for sure.
There are two arguments I have against GraphQL -
1. Why can't you write efficient REST APIs so they offer precise data in one call?
2. Assuming GraphQL Apollo React client talks to Apollo backend server, I assume the Apollo backend server is doing more querying before returning precise data to the client. There is performance overhead on the server-side, GraphQL is just offering ease, not performance optimization.
If my above two arguments are true, GraphQL will be replaced someday by an easy-to-use REST API abstraction on the server-side, this abstraction will offer the GraphQL benefits in REST.
The graphics and animations are simply next level.
It is most quick , constructive and comprehensive essence of knowledge without any extra BS payload like memes and distracting videos. Thank you, sir.
Did you just roast fireship?
Frankly I didn't understand the part with the table scan that could bring the DB down. Someone care to elaborate please?
I'm not sure what the details are of his example, but as presented, that risk is possible with REST calls too. Unsure why he singled it out as a GraphQL problem
For example "find a user whose name matches a regex", and the name column in the DB has no index. In practice, I don't think such a query is likely to bring down the entire service, although it's possible. It would depend on how many of these queries are executed. In a bad scenario, all other queries become slow because the DB is overloaded, which causes more and more requests to accumulate, until everything fails. I don't know how GraphQL works, but with simple REST + SQL, you would use the circuit breaker pattern and use a "bouncer" (a proxy) in front of the db
@@DF-ss5epYou put your sql inside a resolver like you will do it in rest api. It’s not a graphql problem or rest …
Great video!
But sincerely I would continue to use JSONAPI instead of GraphQL.
JSONAPI is super nice, supported by a lot of frameworks and it's build around the specific fields to be fetched just when they are needed... not to mention the pre-build filters that you can specific on your resources and simplify the way you filter for particular records and collections
Thats the biased devloper inside u
@@sadashivshinde9150 Maybe 😂
which good resources are available for learning JSONAPI. i have found a small number and i dont understand it fully
which software you use to crate this kind of animation video? please tell me. and thank you so much for shareing this wonderful explanation.
i used to like graphql, i just realize it really sucks for handling advance api! specially when integrating with frameworks and libraries. the only thing about it is that it's database agnostic. other than that graphql really sucks. rest good but too much stuff to work. trpc is coming, and i think it's better than these two. but to see is to experience. just like graphql it sucks at the end.
Great piece!
Would love to have a piece elaborate on the caching behaviors of HTTP GET leveraged by browser, CDN and servers mentioned in the video.
Awesome video...receiving all resources from one request seems great for GraphQL. However, not sure about its security capabilities and the fact caching is a headache. As a lead Engineer, I'll recommend GraphQL for our internal tools still not convinced about using it in our production apps.
How would GQL differ from a security perspecific than any other HTTP based API...
@@M3t4lstorm Makes you wonder about the Lead Engineer....
@@M3t4lstorm Not really a security issue per se, but graphql makes it easier to write very expensive queries, rest can rely on basic rate limiting but graphql also needs to block clients spaming tremendously expensive requests
Tried graphql recently, after a few api, yea it's great, work smoothly, easy to implement. Then going bigger, n+1 problem, shit define, hard to track. GraphQL is shit imo
thanks for content! suggestion: Odata, or maybe a video about "Rest vs. Odata vs. GraphQL"
To be fair, you can also accidentally do a full scan of a table in SQL too. Maybe it's just a bit less likely because developers who build the queries are more aware of what's in it than frontend developers
Totally agree on that. But the main misconception with GraphQL is the following:
Maybe this is the biggest mistake in GraphQL implementations. While it is meant to be a form of contract between the client and the server, in which the backend side plays the role of the aggregator that fetches data from different sources, people use it to communicate with the database layer instead.
@@yannistheodorakopoulos5916 I thought it was obvious that graphql should be used as a backend for frontend more than for data access layer, guess people relying on it to do stuff it's not that good for...
Graphql should just stay away from your domain/business layer
GraphQL seems like it would be AMAZING for our application, but then once you deep dive in, you realise it's actually the worst..
Our data structure is mutable from 1 call to another since it's the user who defines what their data looks like.. (We basically have a database in a database)
I have combination with Rest API. Most complex get calls in graphql and mutation from Rests only which gives granular control.
Sounds like you are doing something wrong. You should only expose things you want to mutate to the schema. Search for GQL best practices around mutations.
Everything in our data is mutatable. It's user defined, and linkable.
Interesting. I implemented some similar features in the H2O-3 REST API framework back in 2015. You can white- or black-list fields, and specify which if any child objects to return in the payload, so you didn't have to make many REST requests and assemble an object graph yourself inside the client. The query language was just REST with a couple optional parameters on top of it. It doesn't require a schema (it's schema-on read, with automatically-generated rich metadata for the schemas), or a special query language. You just specify the field paths for any child or grandchild classes you want returned.
The API is defined in a very lightweight way, simply by creating a parameterized class for each class in the API. No boilerplate, no IDL.
the work on animation is incredible very inspiring
It's neat, it makes sense mostly, but don't you get tired of learning all these better and more innovative tools to communicate / integrate contemporary applications?!! Or is it just me? 😞
I can predict with absolute certainty that this GraphQL will be yet one of the many technology junks littering the software landscape.
Thank you for the great video. What tool / software are you using for the video animation?
I would presonally just pass in an additional parameter to grab smaller or fuller version of the request, where some data could be nullable.. but if you really need that kind of flexibility then fine 😅 but is slower so...
Rest: simple to implement and use, with inefficiency in specific occasions because of multiple API calls required
GraphQL: flexible and efficient to use, but complex to implement and use and often relies on extra tools
This reminds me of xsd xml soap from back in the day, but graphql is better designed and controlled by smart people.
Lewis Joseph Gonzalez Amy Martinez Scott
Great video, but I don’t see the advantage of GraphQL over JSONAPI. Also, there are several open source implementationsfor JSONAPI.
I would only maybe use GraphQL to describe relations not predicted by a JSONAPI REST API, if that much.
It is indeed a good way of getting data, a proper design will help the same. I love GraphQL. Imagine I ask for a name query from an api and it gives me 200 fields that I don't even want ! See ?
That's solvable with REST as well. You just get a small subset of columns by default and pass a query param to get additional ones. Sure, GraphQL is still more flexible, but I don't see how the tradeoffs are worth it.
anyone knows the software used for graphic and animation slides?
how is this in principle different from soap and exchangign wsdl schemas?
The way you explained is TOP NOTCH
Martin Linda Thomas Angela Robinson Betty
Like, your video content is very professional, what software did you use to make the video? thanks
Is it same persistent tables for GraphQL and REST? If so, can GraphQL guarantee atomic operations across tables?
graphql is just a specification for http requests, it does not interfere with your tables.
Nice video 👏👏. Which tool are you using for making such great videos?
ByteByteGo 中文名称是啥呐? 字节奔跑? 字节行动?
I like this channel.
Valuable technical system design series.
thank you for this! extremally valuable resources, please keeping making this content
Lopez Carol Rodriguez Angela Harris Laura
Perez Steven Wilson Margaret Wilson Linda
What is the GraphQL analogue for HATEOAS? I.e. how do you discover resources?
Important question!
any one understood at 4:21 . What he meant? How does the entire table span occurs?
Lopez Jose Wilson Dorothy Thomas Larry
Martin Dorothy Davis Shirley Lewis Gary
such a great video - love the channel!
Great work as always ! I'm really impressed by the quality of your slides
u put ; after $petType, but : after $name. is it correct?
Perez Carol Lewis Michael Lewis Donna
White Gary Wilson Kenneth Thomas Kevin
Amazing video, thanks for it
Lee Daniel Jones Eric Anderson Thomas
Nice explanation
Good explanations ... good animations !!
Lee Margaret Miller Daniel Taylor Kimberly
Should I use GraphQL？ If you ask yourself such a question, that already suggests NO. GraphQL is very dangerous if not implemented carefully.
Dude, you are the best. Thanks! Keep it up!
Hall Gary Moore Amy Davis Sarah
Moore Gary Taylor George Allen Larry
Thanks for the quality content.
2:11 to 2:21 a superb concise explanation of the difference.
In previous video I just watched they told that n+1 problem is a problem of GraphQL approach, in this video they told that n+1 problem is a problem of REST approach 🤯
But still we can prepare query in REST that we specify parameters and others things.
What about rest and GRpc
Thanks for your sharing
this was best ! because everyone was speaking regarding graphql directly and i was thinking its a sql languange XD
hey what if the query is too long ?
Thank you for great video, tRPC is now gaining growth and replace graphql
Binod. Good.
Fantastic Motion animation btw
I immediately went to your channel to watch more videos, but the count is very low. But thats the catch, quantity > quality.
This looks really nice but it adds extra complexities users might not want to adopt.
I don’t get why the problem described at the end is specific to GraphQL.
Seems like graphql is not so good and we should keep using rest, did I understood correctly?
Cool. Thanks. I know this might by obvious for some people. But what about "security". Is possible to implement that with Graphql?. I know with rest API I can limit the information an user can have and who can access that. I don't have experience with Graphql
You should be able to. I was using graphql-ruby in my previous job and you can use pundit with it to control which users are allowed to see which objects and which fields. I'm sure other graphql libraries will have similar features
This kind of 'security' doesn't even belong in the API layer, so yes GQL can
you can make requests require tokens for authentication in the auth header of a graphql request
Ofcourse. Oauth or other can be enabled as you know the endpoint being exposed. Frameworks allow that seamless.
Which program do you use for animations?
Thx! So helpful!!
To the point and precise explanation. Nothing bla bla !!
Very nice!
exactly what i thought - nice to spend exactly the minutes required to appraise oneself of a technology. plus i especially liked his no nonsense take on the pros and cons. a really good job/video
Thanks
This is a fantastic video! Thanks for the comparisons, it really helped me understand what was going on. I was having trouble understanding the concepts seeing as not many people explain it this simply and I didn't have time to dig into the documentation... Thanks a lot. I'll be sharing this video for anybody else who needs a quick, no fuss intro to graphql.
Really clarify my understanding of their usage
Excellent explanation, thanks! subscribed 👍