I reviewed 1,000s of GraphQL vs. REST perspectives • Hacker News Board

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#11

Post by cheald » Thu, Aug 10, 2023, 9:21 PM UTC

silisili wrote: post #6

injb wrote: post #2

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 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…

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.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#12

Post by anotherhue » Thu, Aug 10, 2023, 9:34 PM UTC

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.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#13

Post by plumeria » Thu, Aug 10, 2023, 10:08 PM UTC

injb wrote: post #2

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 Grap…

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.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#14

Post by injb » Thu, Aug 10, 2023, 11:42 PM UTC

plumeria wrote: post #13

injb wrote: post #2

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 Grap…

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.

The issue I'm talking about is allowing clients to make arbitrary queries via GQL. Maybe I've misunderstood it, but that's how I've seen it used before. If clients can do that, then they need to know about the model. And if they can't then I'm not sure what GQL does that REST doesn't do.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#15

Post by appplication » Thu, Aug 10, 2023, 11:47 PM UTC

cameronfraser wrote: post #4

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.

I actually found this very helpful. There’s so much cruft and bullshit and promotion among web frameworks and tech, it’s difficult to get a sense of what is the right decision if you’re new to web dev.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#16

Post by patrickthebold » Fri, Aug 11, 2023, 12:55 AM UTC

injb wrote: post #14

plumeria wrote: post #13

Earlier quoted context omitted.

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.

The issue I'm talking about is allowing clients to make arbitrary queries via GQL. Maybe I've misunderstood it, but that's how I've seen it used before. If clients can do that, then they need to know about the model. And if they can't then I'm not sure what GQL does that REST doesn't do.

My understanding is "arbitrary queries" "arbitrary _database_ queries". So you can have some abstract "graph" that can be queried, and separately implement "resolvers" (IIRC) that actually tie parts of the graph to actual queries. (So there is a layer of indirection.)

What you get is a way for clients to tell you precisely what fields it needs and a way for it to coalesce what would be multiple api calls in a REST world into a single request.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#17

Post by ttfkam » Fri, Aug 11, 2023, 1:00 AM UTC

silisili wrote: post #6

injb wrote: post #2

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 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…

Postgraphile https://postgraphile.org/

Hasura https://hasura.io/

Stop writing GraphQL resolvers by hand, especially if you're working off of a relational database model.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#18

Post by tango12 » Fri, Aug 11, 2023, 1:14 AM UTC

Given the complexity vs DX trade off with GraphQL presented in the post: perhaps GraphQL goes the way of SQL.

SQL is a phenomenal API but nobody builds a “sql api server” at work.

People do build products that present a sql api, because it’s a great API.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#19

Post by injb » Fri, Aug 11, 2023, 1:54 AM UTC

patrickthebold wrote: post #16

injb wrote: post #14

Earlier quoted context omitted.

The issue I'm talking about is allowing clients to make arbitrary queries via GQL. Maybe I've misunderstood it, but that's how I've seen it used before. If clients can do that, then they need to know about the model. And if they can't then I'm not sure what GQL does that REST doesn't do.

My understanding is "arbitrary queries" "arbitrary _database_ queries". So you can have some abstract "graph" that can be queried, and separately implement "resolvers" (IIRC) that actually tie parts of the graph to actual queries. (So there is a layer of indirection.) What you get is a way for clients to tell you precisely what fields it needs and a way for it to coalesce what would be multiple api calls in a REST wo…

Thanks, that's a more nuanced understanding of it than I had. Still, when I try to think about keeping that model in sync with the real underlying model, it scares me.

It sounds to me like there is still bound to be some correlation between querying flexibility on the client side, and coupling between the client and server. But that is OK in many cases and in fact is how many REST apis are already being implemented.

Re: I reviewed 1,000s of GraphQL vs. REST perspectives

#20

Post by cmgbhm » Fri, Aug 11, 2023, 2:09 AM UTC

One problem I’ve seen is graphql comes over for some high profile project needs. It feels elegant to get the fields you want in the way you want them.

The trouble comes when REST API parity is not maintained.

The dev experience then becomes an O(N) search through the autogenerated graphql docs to determine X is missing and the thing you are trying to do can’t be done elegantly.