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

GraphQL vs. REST APIs: a complete guide

airplane.dev

Post reply on HN
Print view View original

71–80 of 103 posts

Re: GraphQL vs. REST APIs: a complete guide

#71

Post by timr »

nonethewiser wrote: post #69
timr wrote: post #64

Earlier quoted context omitted.

I can think of painful examples in REST in my life where I had an endpoint that was being used for something new, and now I had to join with some new data model to solve the new problem which made the old use sub-optimal (or vice-versa). But when that happened, what it really told me was that it was time to introduce a new endpoint and refactor the code to adapt to the change in use case. Painful? Sure. But so are th…

Right. In GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose. It separates the API from how it’s used. If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints.

> GraphQL you wouldn’t need to make a new endpoint for the same resource just because you’re calling it for a different purpose.

Yes, but I'm saying that's a feature, not a bug.

It's not absurd to make new endpoints. Each endpoint is a different need. You can optimize them independently...or not.

> If you’re querying different fields on the same resource 50 different times it’s rather absurd to keep making new endpoints.

In my career, I can count the number of times that a field has mattered in a response on one hand. Usually the problem is the joins, or the total number of queries. Point being: you don't generally write new endpoints just because the number of fields in a response is slightly different.

Re: GraphQL vs. REST APIs: a complete guide

#72

Post by brasic »

ElijahLynn wrote: post #25

Article could be improved by mentioning that the smaller rest requests will have a much higher cache hit ratio when used with HTTP/2.

Everything is higher than zero. GraphQL is inherently not meant to be cached at the transport layer which is why it’s often exposed behind HTTP POST. If caching GraphQL makes sense for your application you probably didn’t need GraphQL in the first place.

Re: GraphQL vs. REST APIs: a complete guide

#73

Post by unusualmonkey »

timr wrote: post #26
jensneuse wrote: post #9

Here's how you do it: - REST/Hypermedia when you're actually building a website (not app) and your "site" is a state machine - OpenAPI when you expose and API to 3rd parties - Isomorphic TypeScript APIs when you're using TS on both backend and frontend [0] - GraphQL when the frontend needs to talk to an API layer provided by different teams - OpenAPI when one backend talks to another backend - gRPC might be an option…

Simplify that to: - REST by default - everything else might be an option, but you need to justify it with specific reasons. Also, having a JS-driven front end or multiple teams is not an automatic justification for the complexity of GraphQL. GraphQL is a huge burden, for very little practical gain. Most companies have very small number of examples of conflict areas where queries need to be optimized, and for the most…

> GraphQL is a huge burden, for very little practical gain. Most companies have very small number of examples of conflict areas where queries need to be optimized, and for the most part, these can be resolved through smarter front-end engineering (like not throwing React at CRUD websites).

We use Hasura to provide GraphQL and find the exact opposite.

* Need to filter by X? Already done.

* Want to join two different entities? Done.

* Pagination? Done.

* Aggregation? Done.

* Security? Done, just set it.

* Streaming data? Done.

We don't have traditional API code, and yet have an API is more sophisticated and powerful than any API I've built professionally.

Re: GraphQL vs. REST APIs: a complete guide

#74

Post by b212 »

I had the pleasure of working with Apollo + GraphQL for the last 2 years and I don’t understand the hype. I haven’t seen anything so over engineered and complex in my whole 20 year long career. To make things worse I quickly found out all the problems GraphQL tries to solve are still there. Like over-fetching is around the corner if you don’t pay attention.

REST on the other hand feels really straightforward, maybe easier to mess up but also much easier to fix. I’d take Redux over Apollo anytime even though Redux is dying according to many.

Re: GraphQL vs. REST APIs: a complete guide

#75

Post by jasfi »

unusualmonkey wrote: post #73
timr wrote: post #26

Earlier quoted context omitted.

Simplify that to: - REST by default - everything else might be an option, but you need to justify it with specific reasons. Also, having a JS-driven front end or multiple teams is not an automatic justification for the complexity of GraphQL. GraphQL is a huge burden, for very little practical gain. Most companies have very small number of examples of conflict areas where queries need to be optimized, and for the most…

> GraphQL is a huge burden, for very little practical gain. Most companies have very small number of examples of conflict areas where queries need to be optimized, and for the most part, these can be resolved through smarter front-end engineering (like not throwing React at CRUD websites). We use Hasura to provide GraphQL and find the exact opposite. * Need to filter by X? Already done. * Want to join two different e…

Caching as an option is also good.

Re: GraphQL vs. REST APIs: a complete guide

#76

Post by mb7733 »

blagie wrote: post #37

I don't like GraphQL due to the complexity. It's not JSON or YAML, and requires a lot of custom stuff on both ends. I'd like something like GraphQL, but built on standard data formats.

Every graphql API I've ever seen returns JSON. It's definitely the standard. What are you referring to?

Re: GraphQL vs. REST APIs: a complete guide

#77

Post by 4RealFreedom »

jensneuse wrote: post #31
timr wrote: post #26

Earlier quoted context omitted.

Simplify that to: - REST by default - everything else might be an option, but you need to justify it with specific reasons. Also, having a JS-driven front end or multiple teams is not an automatic justification for the complexity of GraphQL. GraphQL is a huge burden, for very little practical gain. Most companies have very small number of examples of conflict areas where queries need to be optimized, and for the most…

I more or less agree, but recent advances in tooling has changed this. E.g we've built a GraphQL to JSON RPC compiler [0], so we're hiding GraphQL behind a JSON RPC wall which also enables powerful code generation. We're using this successfully to build our own cloud [1] using our own tooling and I quite like it. Shameless plug, I'd love to get feedback if you have the time to try it out. [0]: https://docs.wundergrap…

Maybe I'm just not understanding the use case here but your using graphql with a compiler to produce rest (JSON RPC) endpoints? Why not just write rest endpoints? I can see how it might be easy for simple endpoints but as soon as you have to optimize anything you'll need to add features to your compiler.

Re: GraphQL vs. REST APIs: a complete guide

#78

Post by habitue »

mb7733 wrote: post #76
blagie wrote: post #37

I don't like GraphQL due to the complexity. It's not JSON or YAML, and requires a lot of custom stuff on both ends. I'd like something like GraphQL, but built on standard data formats.

Every graphql API I've ever seen returns JSON. It's definitely the standard. What are you referring to?

I think they're referring to the query language itself not being json or yaml

Re: GraphQL vs. REST APIs: a complete guide

#79

Post by chrisandchris »

4RealFreedom wrote: post #77
jensneuse wrote: post #31

Earlier quoted context omitted.

I more or less agree, but recent advances in tooling has changed this. E.g we've built a GraphQL to JSON RPC compiler [0], so we're hiding GraphQL behind a JSON RPC wall which also enables powerful code generation. We're using this successfully to build our own cloud [1] using our own tooling and I quite like it. Shameless plug, I'd love to get feedback if you have the time to try it out. [0]: https://docs.wundergrap…

Maybe I'm just not understanding the use case here but your using graphql with a compiler to produce rest (JSON RPC) endpoints? Why not just write rest endpoints? I can see how it might be easy for simple endpoints but as soon as you have to optimize anything you'll need to add features to your compiler.

Sometimes we just need to create another immensly complex layer on top of something, because the 10-year-old boring technology that already works is lame.

Re: GraphQL vs. REST APIs: a complete guide

#80

Post by mattmanser »

nonethewiser wrote: post #52
mattmanser wrote: post #48

Earlier quoted context omitted.

That's not an advantage, from the DB side the two queries are indistinguishable because they use the same indexes. They will take virtually the same CPU to complete. If your user has authorization to access this extra data, the actual cost of sending those extra fields properties over the wire is ridiculously trivial. Think a kilobyte or two, if not a few bytes. Any justification you think you have for just sending t…

Not at all - removing select “*” from queries is perhaps the lowest hanging fruit for optimizing queries. https://stackoverflow.com/a/25093454 I agree that GraphQL is often overkill but specifying fields is powerful and sometimes a big boon.

That's not true unfortunately.

Posting a SO Question that's been upvoted by 24 people in a decade is not evidence.

Think about this a bit more, those are LOCAL network calls you're talking about. Not calls over the internet.

It doesn't matter.

Obviously if there's a massive blob in your DB table you're not going to be sending it up regardless if you are using graphQL or not.

Post reply on HN