[HN Gopher] I reviewed 1,000s of GraphQL vs. REST perspectives
___________________________________________________________________
I reviewed 1,000s of GraphQL vs. REST perspectives
Author : dphuang2
Score : 23 points
Date : 2023-08-10 16:54 UTC (6 hours ago)
(HTM) web link (konfigthis.com)
(TXT) w3m dump (konfigthis.com)
| adamredwoods wrote:
| It 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.
| injb wrote:
| A 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.
| plumeria wrote:
| I'm somewhat confused about what you mean by "expose your
| backend data model to your front end(s)", since you can disable
| introspection in production.
| mikecaulley wrote:
| 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.
| silisili wrote:
| 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.
| cheald wrote:
| Interestingly, the principle of single responsibility is
| specifically why I like GraphQL over REST. As your frontend
| complexity grows, your REST payloads tend to become
| carefully-balanced collections of complex shapes, and it
| becomes very difficult to maintain and refactor over time. In
| GQL, by comparison, each field or mutation has its own
| isolated implementation, authorization is handled at a
| granular level, and frontend queries can evolve as needed
| without imposing any significant need for changes on the
| backend.
|
| REST is great for small, compact APIs which serve a couple of
| views, but as the product grows in scope and complexity,
| GraphQL ends up feeling significantly easier to keep
| straight.
|
| The other thing is that it's very easy to build "complex"
| REST APIs on top of GraphQL - execute an internal query,
| reshape the result into a JSON payload to conform to the REST
| contract - but implementing GraphQL on top of a bunch of REST
| calls is a lot hairier. GraphQL feels more like a set of
| primitives, while REST is a coalesced interface.
| semiquaver wrote:
| 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.
| nesarkvechnep wrote:
| Are we talking about REST with HATEOAS? If we are, it's apples to
| oranges.
| ushakov wrote:
| Amazing 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
| [deleted]
| cameronfraser wrote:
| My 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.
| anotherhue wrote:
| We found that allowing the FE guys to iterate faster over
| relatively simple data models was worth the extra backend
| complexity. Additionally, every time a JSON deserialisation fails
| because someone typo'd a key an angel loses its wings, so that's
| nice to avoid.
___________________________________________________________________
(page generated 2023-08-10 23:01 UTC)