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

21–30 of 48 posts

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

#21

Post by ajjenkins »

Regarding the “it’s not worth the extra complexity” argument, I think it depends on how you’re creating your GraphQL server. If you’re writing the server logic yourself, I think GraphQL is absolutely not worth the extra complexity. Making a REST server is way easier than making a GraphQL server.

But I think the balance can tip in favor of GraphQL if you’re using a managed GraphQL server like Hasura. I’m using Hasura for a solo project and I actually find it simpler than maintaining my own REST API code. All I need to do is specify my data model and never need to write any boiler plate for new endpoints. I know there are similar services for REST that can automate the boiler plate code away (like Supabase). But Hasura automates away the hard parts of GraphQL, and I prefer the experience as a client of GraphQL over REST. I like being able to specify exactly what data I want from the API and being able to get values for foreign tables in one query without needing to join the data client-side.

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

#22

Post by windexh8er »

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…

Happened to have worked with an API security product for a while that was sitting in front of a lot of large brands. One retailer that had APIs constantly under attack from bot and organized crime invested a lot of time and money into remapping their old rest API such that they could better protect the pieces of it in different ways.

Then, out of the blue, we learned they were moving everything to GraphQL because they had done cost analysis on how many fewer calls they'd need to make, creating efficiency gains of over 50% of all session transactions. What they failed to take into account was that all of the time and money invested in the prior methods to protect really relied on the structures of their REST schema. Now everything would need to build back up and many of the security introspection gates were within the chaining of the REST calls which could no longer happen.

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

#23

Post by ttymck »

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…

This explanation is evident of a lack of understanding. I should know, because I felt exactly the way you do before I implemented a GraphQL server.

Unfortunately, I still don't know how to explain in words why your understanding is inaccurate, I only know how what it means in practice, by example. GraphQL is still elusive in that regard.

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

#24

Post by blacksoil »

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 endpoint.

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

#25

Post by fswd »

ttfkam wrote: post #17
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…

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.

writing graphql resolvers by hand was what I did in ... 2017. I've been using postgraphile since and couldn't be happier. I don't think I've written a single line of Apollo in 5+ years.

And with postgraphile, and a remix/next BFF, you don't even need a backend!

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

#26

Post by randomdata »

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'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 datacenter.

The Unix philosophy remains. You are still calling individual REST services, assuming you hold true to GraphQL's intent. The only difference is that the client is able to leverage GraphQL to push that work to inside of the datacenter, where latency is much more tolerable. If REST services are your individual Unix tools, the GraphQL resolver is the shell that ties them all together.

Granted, if your clients are known to be on solid connections you likely don't need to even bother with a BFF layer, but GraphQL comes from Facebook where a large segment of their users are on spotty mobile networks where round trip reduction is critical to providing a usable experience.

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

#27

Post by nivertech »

1. Apples vs Oranges: GraphQL is a protocol with an open spec, REST is an architectural style.

2. Nevermind how good or a bad GraphQL is, the de-facto standardization provides lots of benefits, in the same way as Docker did for containers.

3. GraphQL complexity is mostly an essential complexity in software engineering, with a bit of accidental complexity due to novelty and unaddressed problems/missing features.

4. GraphQL allows better modeling of the domain. It fits well to use with DDD/CQRS/ES/Sagas/Persistence Ignorance/TBUIs[1]. If all you need is a generic app managing a tabular collections of items, then you can use generic architectural styles like CRUD/REST/RDBMS/ACID transactions/ORM/generic Web Admin UIs, either coded manually, using AI copilots, nocode, or lowcode tools like Hasura or PostGraphile.

---

[1] Domain Driven Design, Command-Query Responsibility Segregation, Event Sourcing, Task-Based or Task-Driven UIs

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

#28

Post by casperb »

After 15 years of heavy restful API usage, building 10 restful API’s, using the GitHub and Shopify GraphQL API’s and providing our own GraphQL API in PHP, I think this article puts the nail on the head.

It is nice to only get the data you need as a client. The Graphiql explorer is very nice to try to get the right data. But that is mainly an advantage if the restful endpoints are badly designed. The Shopify API around inventory is very bad and became worse over time. You would need 15-20 rest requests or 1 complicated Graphql request to get the 3 fields you need together. But in most cases, even as a front end user, if the API is designed nicely it is not worth the complicated whole of the system of Graphql.

GitHub’s API works better as rest then as Graphql in my opinion. And the Stripe API is also very nice. I don’t need Graphql there as a user.

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

#29

Post by flagged24 »

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…

If you consume your own graphql endpoint you can add some layer of security by only allowing predefined queries and inspect the provided query variables. I use PostGraphile as an Express middleware and only allow whitelisted requests.
Post reply on HN