Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

konfigthis.com

Post reply on HN
Print view View original

31–40 of 48 posts

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

#31

Post by mannyv »

GraphQL makes front end work easier because FE folks can't seem to handle the complexity involved in making multiple calls to a backend. GraphQL moves that complexity somewhere else (ie: the backend).

From a BE POV GraphQL makes things more difficult because the failure behavior is more complicated. If a failure occurred in the FE then the FE presumably knows what to do. If a failure occurs in a graphql call chain it's unclear what the FE would like to happen, and the FE developer is probably clueless as to what they want, since the structure has been abstracted away.

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

#32

Post by JackMorgan »

My main takeaway: GraphQL moderately improves developer enjoyment (DevEx) by majorly increasing the cost of making production ready APIs.

I've worked on bigger teams where the job was boring and there was plenty of spare capacity to improve DevEx. Spending a lot for a more enjoyable DevEx was worth it to retain good talent. They typically spent about 50% of their total capacity on DevEx and technical debt. Those teams would probably benefit a lot from GraphQL.

Other projects it's just me building an entire product with extremely tight timelines. Or it's a small team without a lot of spare capacity. I probably won't elect to use GraphQL in that situation.

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

#33

Post by zifeo »

blacksoil wrote: post #24

Personally I found GraphQL to be a God-sent for prototyping. Tools such as Hasura and postgraphile are just amazing to whip out fully-working backend very quickly. I do agree with some of the posts though about security being a bit of a hassle. It's not impossible to secure GraphQL endpoints (e.g. through row-level or column-level security for Postgres-based backend) but it's not as straight-forward as securing REST…

That's the reason we have developed field-level access control [1] with policies on the top of rating-limiting [2] for Metatype.

[^1] https://metatype.dev/docs/tutorials/policies-and-materialize...

[^2] https://metatype.dev/docs/tutorials/authentication-and-secur...

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

#34

Post by SlickStef11 »

randomdata wrote: post #26
silisili wrote: post #6

Earlier quoted context omitted.

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…

> I've always found REST more logical. They shouldn't be at odds with each other. GraphQL was explicitly designed to sit in front of your REST services - occupying the so-called backend for frontends (BFF) layer – allowing your service graph to be navigated by query in order to allow frontend folks to roll up all their calls in a single request to reduce the high round trip costs that can be found outside of the data…

For more info on BFFs: https://bff-patterns.com/

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

#35

Post by flashgordon »

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…

I dont konw if this is a good practise. I start off initially with REST endpoints that expose (basic) data models - and then have the API the calls it needs. Over time there is a tendency to bloat your REST calls (a good sign is you need to combine two different models - joins). At this point what I have found useful is instead of putting a full blown layer graphql layer that does this scatter-gather for you - I add explicit "viewmodel" APIs. I am sure this was what graphql was for - but for some reason for me having explicit protos/rest specs to model your view models seems more incremental and less stressful. Or may be just old-school thinking?

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

#36

Post by dphuang2 »

karmajunkie wrote: post #30

I’m surprised no one has mentioned the obvious interest of the author working for a company that provides REST tooling, reaching the conclusion that REST is a better option.

We use GraphQL internally but I admit I am currently more biased towards REST after battling with GraphQL, building a OpenAPI-based company, and playing with ergonomic REST-based frameworks like FastAPI. I still think the GraphQL DX is still miles ahead of OpenAPI and I really admire the best practices in GraphQL prescribed by Relay. But right now, REST is king for me.

Your observation is sort of the point of this article. Everyone has their opinion but nobody is de facto right.

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

#37

Post by pests »

injb wrote: post #19
patrickthebold wrote: post #16

Earlier quoted context omitted.

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.

GraphQL exposes your backend model the same way your json response to a REST api exposes the backend model - they dont. It's up to your REST api to assemble data from the database (or elsewhere) and return them in a structured format.

GraphQL resolvers do the same. You can hit another API, query a database, or return file data. It's up to you what you want each field to resolve to.

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

#38

Post by DGCA »

mannyv wrote: post #31

GraphQL makes front end work easier because FE folks can't seem to handle the complexity involved in making multiple calls to a backend. GraphQL moves that complexity somewhere else (ie: the backend). From a BE POV GraphQL makes things more difficult because the failure behavior is more complicated. If a failure occurred in the FE then the FE presumably knows what to do. If a failure occurs in a graphql call chain it…

1. async/await is a thing.

2. The GraphQL spec tells you how errors should be handled.

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

#39

Post by nivertech »

dphuang2 wrote: post #36
karmajunkie wrote: post #30

I’m surprised no one has mentioned the obvious interest of the author working for a company that provides REST tooling, reaching the conclusion that REST is a better option.

We use GraphQL internally but I admit I am currently more biased towards REST after battling with GraphQL, building a OpenAPI-based company, and playing with ergonomic REST-based frameworks like FastAPI. I still think the GraphQL DX is still miles ahead of OpenAPI and I really admire the best practices in GraphQL prescribed by Relay. But right now, REST is king for me. Your observation is sort of the point of this ar…

You should have put a proper disclosure in the post to avoid speculation.

Also it seems off to do all this research, and then instead of summarizing it properly, throw evewrything away and finish it with your own sentiment.

I remeber there was a paper where the reserches asked students to implement the same API using either REST/HTTP, or GraphQL, and the conclusion were in favor of GraphQL.

I would've added reviews of the research papers on this subject, in addition to the social media posts. The former adding more rigor than the latter.

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

#40

Post by dphuang2 »

nivertech wrote: post #39
dphuang2 wrote: post #36

Earlier quoted context omitted.

We use GraphQL internally but I admit I am currently more biased towards REST after battling with GraphQL, building a OpenAPI-based company, and playing with ergonomic REST-based frameworks like FastAPI. I still think the GraphQL DX is still miles ahead of OpenAPI and I really admire the best practices in GraphQL prescribed by Relay. But right now, REST is king for me. Your observation is sort of the point of this ar…

You should have put a proper disclosure in the post to avoid speculation. Also it seems off to do all this research, and then instead of summarizing it properly, throw evewrything away and finish it with your own sentiment. I remeber there was a paper where the reserches asked students to implement the same API using either REST/HTTP, or GraphQL, and the conclusion were in favor of GraphQL. I would've added reviews o…

Fair points, I added a disclosure for clarity in future reference.

That being said, the Pro REST perspectives do scare me away from GraphQL in production. But seeing some posts about PostGraphile + Persisted Queries is interesting.

Also, research papers would have been nice to address but I am satisfied with the many hours this took to compile. A future follow-up may be necessary.

Post reply on HN