I reviewed 1,000s of GraphQL vs. REST perspectives
konfigthis.com
I reviewed 1,000s of GraphQL vs. REST perspectives
1–10 of 48 posts
Re: I reviewed 1,000s of GraphQL vs. REST perspectives
#2A question you should ask yourself at the start that I rarely here any discussion of: how much do you want to expose your backend data model to your front end(s)?
If your answer is "completely", which it sometimes is, then GraphQL might be a good option. It's only a question of implementation details.
If the answer is "not at all" then GraphQL is probably going to be a bad idea because that is the whole point of GraphQL.
The reason people don't realize this is because sadly most people's idea of a REST API is already just a plain 1-1 mapping from DB tables to JSON objects served over HTTP. If you're doing that, you're already coupling any front ends or other consumers to your data model, so what do you have to lose with GraphQL (other than the complexity of deploying it)?
When REST was coined the goal was to hide as much data model stuff as possible. This is really really important if your backend app needs a high degree of interoperability across organizational boundaries, because data migration is hard! But if your API is consumed only by a small number of components that your organization has total control over, you might not care that much.
Years ago I used to see people implementing crude remote procedure call patterns over HTTP because they thought that's what REST was, and had been told it was better because of reasons. But this wasn't a better way of doing remote procedure calls. It was a much worse way! Now I see people using frameworks that just expose all their DB models as HTTP endpoints because they think that's what REST is and have been told it's better. That isn't really what REST is, and GraphQL might be a better way of doing that if that's what you need.
REST is a bunch of constraints that make interoperability and scalability easy to achieve. Maybe you benefit from those constraints and maybe you don't. But that's what you need to think about before you think about GraphQL.
Re: I reviewed 1,000s of GraphQL vs. REST perspectives
#3It comes down to the right tool for the job. But the problem comes from scaling. I worked at a place that was using REST apis, but when they grew, they needed lots of bundling (or filtering down of excess data)d. Graphql gets bundling for almost free. While not unique, it also couples dataloaders, which essentially caches api calls on the request level.
Good ideas, but extra features require extra implementation.
Re: I reviewed 1,000s of GraphQL vs. REST perspectives
#4My conclusion is that there isn't much value in evaluating 1000s of perspectives, they're the same exact arguments you'd find in any blog or technical documentation comparing the two.
Re: I reviewed 1,000s of GraphQL vs. REST perspectives
#5[deleted]
Re: I reviewed 1,000s of GraphQL vs. REST perspectives
#6A question you should ask yourself at the start that I rarely here any discussion of: how much do you want to expose your backend data model to your front end(s)? If your answer is "completely", which it sometimes is, then GraphQL might be a good option. It's only a question of implementation details. If the answer is "not at all" then GraphQL is probably going to be a bad idea because that is the whole point of Grap…
I've always found REST more logical. In a way, it's like the Unix philosophy...do one thing(at a time) and do it well. Implementing Graphql on the backend turns into a clusterf of spaghetti code real quick. And there are a lot of footguns.
I've noticed a lot of frontend folks especially like GraphQL, as they just want the data in as few calls as possible, which I can't fault them for.
I've read about an apollo bridge that basically does GQL over REST. I'm pretty curious how well that works, because it sounds like the best of both worlds. Clients who want GQL have it, clients that want REST have it, and backend logic itself is massively less complex.
Re: I reviewed 1,000s of GraphQL vs. REST perspectives
#7Are we talking about REST with HATEOAS? If we are, it’s apples to oranges.
Re: I reviewed 1,000s of GraphQL vs. REST perspectives
#8A question you should ask yourself at the start that I rarely here any discussion of: how much do you want to expose your backend data model to your front end(s)? If your answer is "completely", which it sometimes is, then GraphQL might be a good option. It's only a question of implementation details. If the answer is "not at all" then GraphQL is probably going to be a bad idea because that is the whole point of Grap…
How you model the data at rest does not need to match the GraphQL specification. The GraphQL specification should be similar to your REST entities but they have traversable edges to other entities.
Re: I reviewed 1,000s of GraphQL vs. REST perspectives
#9A question you should ask yourself at the start that I rarely here any discussion of: how much do you want to expose your backend data model to your front end(s)? If your answer is "completely", which it sometimes is, then GraphQL might be a good option. It's only a question of implementation details. If the answer is "not at all" then GraphQL is probably going to be a bad idea because that is the whole point of Grap…
It’s very much possible to keep your backend data model from leaking too much into your GraphQL schema, it’s just more work than for example using some kind of generator that creates a GraphQL schema from your database schema.
The harder thing in my experience is to make a GraphQL API that is performant across all edge cases and properly cost-limited. That takes an enormous amount of internal analytics infrastructure and work and is often not worth the effort.
And after all that effort, integrators don’t usually want to take the trouble to learn enough GraphQL to actually use the API.
I’ve come to the conclusion that GraphQL is a pretty good system for internal APIs for web and mobile, but a pretty poor one for public-facing APIs.
Re: I reviewed 1,000s of GraphQL vs. REST perspectives
#10Amazing findings! Really admire your effort here
Btw. If you're building a GraphQL API using TypeScript, you should take a look at garph (https://garph.dev) which helps you to create type-safe GraphQL APIs without code-gen