REST vs GraphQL and ordering a Pizza 🍕
Here is a good way to think about the difference between REST and GraphQL.
REST is like trying to order a pizza and only being able to say that you want a pizza, not what size of pizza or what you want on it. You wanted breadsticks too but you will have to call back and order that separately. The deliver guy shows up to your door. You get a pizza with everything on it when you just wanted only a select few toppings and he doesn’t have the breadsticks you had ordered, a second trip has to be made for those.
GraphQL is like ordering a pizza and breadsticks in the same call and being able to tell them exactly what you want on the pizza and getting exactly what you asked for the first time in a single trip.
Trending on Indie Hackers
Nothing prevents REST APIs from returning only selected fields or excluding fields that you don't need.
For example, Mailchimp's API offers query parameters
fieldsandexclude_fieldsjust for this purpose.Build with what you already know.
+1 for "Build with what you already know" - REST has powered an infinite number of high performance enterprise-level sites for decades. It's fine. REST is totally fine. GraphQL is also fine! If you know it and like it, use it. If you don't know it, and want to learn it, go for it ... it's always nice to have a new tool in your toolbox. But if you're in a rush or working with limited capital, and don't already know it, you don't NEED to have it, and you can always refactor after you're making money. GraphQL doesn't guarantee success or even a better codebase. It's just a nice way to give the front-end a bit more control over the data it's ingesting from the back-end.
Personally, I use both. Depends on the client, what they're looking for, whether we're building from scratch or bolting on to a legacy system, what their other engineers are comfortable with, etc. Doesn't really matter to me, because both are fine.
Couldn't agree more!
Totally agree, but only in the scenario where the same team doesn't own front and back-ends.
If you own the full stack you can keep a list of all your regular customer's favourite pizzas and have them ready ahead of time.
This is a good analogy, but it’s important to remember the developer’s perspective here. So with that in mind and keeping with the analogy:
The GraphQL way of ordering a pizza requires you to clearly define what constitutes a pizza and how you will go about placing your order (schema, resolvers, etc). This is unique to your use case of ordering the food as opposed to someone else. The REST way of ordering the food is like simply looking at the menu and calling to place your order, with more work to do once you get what you want. The upfront work of defining schema with GraphQL isn’t something you’d have to do each time you order (more like one initially plus some updating) but it’s more than trivial work and worthy a note :)
Schema can be generated. In fact, I built a library that does this. In GraphQL, you define what a pizza is, then when you order a pizza you will get a pizza. A good implementation will not let you deviate from this.
With REST, on the other hand, everything is up to the implementation. There's no static typing and no spec, every API behaves differently. When you order a pizza in REST, you may get a burger, or a plane, or nothing at all. Who knows.
As you said... "A good implementation will not let you deviate from this". That is true whether you use REST or GraphQL.
What I meant is that through static typing, your GraphQL framework can enforce that your code returns what it's supposed to. REST does not have a type system so there is no way to do this.
you can always use a wrapper to provide type safety with REST and sometime simple REST just does what is needed without having to use a query language.. other times GraphQL maybe more efficient..
I don’t really like this analogy. It’s written as if graphql is clearly superior to REST in every way. It’s not.
The reality is that each has their benefits. For example, REST aims to exploit the existing architecture of the web, which has proven it can scale massively by caching based on URLs. REST can do this with little effort. Graphql can do no such thing, since it exposes one endpoint and basically ignores HTTP.
For me, Graphql’s power comes into play when your requirements involve querying. The clue is in the name. It’s great at allowing service authors to pick the types of query they want to support, and then allows clients to pick the data from a well defined schema.
This is a very bad analogy. You can make your REST API behave however you like.
How do I downvote this?