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

51–60 of 103 posts

Re: GraphQL vs. REST APIs: a complete guide

#51

Post by nonethewiser »

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…

There is a fair amount of practical gain in terms of specifying fields. Can go a long way in terms of making flexible endpoints that don’t pass around extra data. This often isn’t necessary. But when it is you would cry at the thought of using REST instead.

Re: GraphQL vs. REST APIs: a complete guide

#52

Post by nonethewiser »

mattmanser wrote: post #48
chiefalchemist wrote: post #39

Earlier quoted context omitted.

I haven't used it a lot but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Also, as I understand it, when implemented properly, you can get more complex (?) data back. For example, instead of getting 10 orders, and then 10 more requests for the items f…

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.

Re: GraphQL vs. REST APIs: a complete guide

#53

Post by IceDane »

dmitriid wrote: post #45
IceDane wrote: post #33

Earlier quoted context omitted.

How is GQL a "huge burden"? Would you care to elaborate?

GQL, in no particular order: - GQL allows unbounded arbitrary queries. The awkward workarounds turn it into REST with none of REST semantics - default query method (POST) cannot be cached by literally anything in the infrastructure because POST is not cacheable by definition. The awkward workarounds require you to parse and look up fields in both request and response. Both of them arbitrarily large. - instead of dele…

> - GQL allows unbounded arbitrary queries. The awkward workarounds turn it into REST with none of REST semantics

This is essentially a solved problem. You simply give all your fields a complexity value and then you limit the allowed complexity.

> - instead of delegating requests to optimized queries (db or services) you now collect all that data manually, in-memory, on the server with little to no insight into what the data is, and how to optimize its retrieval

Or you simply integrate tightly with an ORM or something and generate optimized queries from your GQL queries.

> - default types doesn't provide useful primitives like dates

Just not really an issue in practice, and really comes down to the underlying transport medium. JSON is limited. If you send a date over the string, it's either going to be a timestamp or a string. Your consumer will still need to know it's actually a date that needs to be deserialized. At least in GQL this is easy to do.

> - you now have to keep up with evolution of every single microservices you depend on

How is this a problem with GQL? Do you think that API versioning is in any way easier to when you have REST APIs? It's actually the opposite, because OpenAPI schemas suck and there is no great tooling that helps you stay on top of the changes. In contrast, there is excellent tooling for GQL that literally diff your new schema vs the old and tell you if any recent clients would be affected. You can do all this as part of your workflow(in CI etc) and act accordingly.

Re: GraphQL vs. REST APIs: a complete guide

#54

Post by marcosdumay »

twodave wrote: post #17

I like GraphQL because it allows me to describe my API like a domain rather than just a collection of resources. REST is difficult to map to a true domain model because domains aren't just collections of resources. They have nuance. And with GraphQL your API matches your domain, so there's no limit to what your application can accomplish. For example, adding another feature to your front-end no longer requires going…

Yes, GraphQL allows you to expose a domain. What is a really big problem, because websites are organized as an hierarchy of resources, applications are organized as a collection of actions, and nobody on the user-facing side ever thinks about a domain of small interrelated things.

With nobody thinking about the interface, you are left with the classical dilemma between usability and security. And all GraphQL tooling seems to floor their feet on the usability side.

Re: GraphQL vs. REST APIs: a complete guide

#55

Post by [deleted] »

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…

[deleted]

Re: GraphQL vs. REST APIs: a complete guide

#56

Post by nonethewiser »

The anti GQL circle jerk goes too far. GraphQL is often overkill but it’s awesome if you take advantage of the powers of federation and field specification. If you don’t see a difference between retrieving all fields and just the ones you need then you just haven’t encountered the cases where it makes a difference.

Re: GraphQL vs. REST APIs: a complete guide

#57

Post by lmarcos »

timr wrote: post #40
chiefalchemist wrote: post #39

Earlier quoted context omitted.

I haven't used it a lot but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Also, as I understand it, when implemented properly, you can get more complex (?) data back. For example, instead of getting 10 orders, and then 10 more requests for the items f…

> but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Sort of (the sibling comment explains well why this example is an illusion). But even if this were an advantage, you have to implement the logic (simple in this case, but not so simple once people go…

> probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need.

That's the only reason why teams use GraphQL. Decoupling taken to the extreme.

Re: GraphQL vs. REST APIs: a complete guide

#58

Post by JanisErdmanis »

gtramont wrote: post #42

I take not mentioning hypermedia in a post discussing REST as a huge red flag. The author mentions Roy Fielding's dissertation, but apparenly they didn't read it thoroughly. Furthermore, I believe that a huge confusion comes from not understanding what a "resource" is: it is not a database table*; it is not your domain model*; it is a _representation of state_. Like this very orange page you're looking at. This whole…

The naming of "resource" is a bit unsettling. From the perspective of the server, it seems natural to think of all databases and external machines. "Representation" sits better with me, but ultimately in the code, I would prefer to name the REST endpoint as a "service".

Re: GraphQL vs. REST APIs: a complete guide

#59

Post by lmarcos »

IceDane wrote: post #47
timr wrote: post #38

Earlier quoted context omitted.

I could write a book on this, but just a few: * your teams will now spend a big portion of their time thinking about GQL primitives and mapping and syntax (oh my) and otherwise caring for and feeding this beast. * you still haven't solved the underlying problem -- you still have to figure out why your GQL requests are hammering the back-end(s...let's not forget that a lot of this stuff came from poor decision-making…

> * your teams will now spend a big portion of their time thinking about GQL primitives and mapping and syntax (oh my) and otherwise caring for and feeding this beast. What exactly do you mean by this? My team spends exactly zero time "thinking about GQL primitives and mapping and syntax"? What programmers have a problem understanding GQL syntax? I have explained GQL and set people to work in a 30 minute session. I'v…

The problem is:

REST = http

GraphQL = http + GQL + resolvers

Sure, one more layer of abstraction here and there may be justified. In the case of GraphQL, it's not.

Re: GraphQL vs. REST APIs: a complete guide

#60

Post by nonethewiser »

gtramont wrote: post #42

I take not mentioning hypermedia in a post discussing REST as a huge red flag. The author mentions Roy Fielding's dissertation, but apparenly they didn't read it thoroughly. Furthermore, I believe that a huge confusion comes from not understanding what a "resource" is: it is not a database table*; it is not your domain model*; it is a _representation of state_. Like this very orange page you're looking at. This whole…

REST is such a bastardized term. At this point it’s often used synonymously with JSON/HTTP or simply meant to contrast between SOAP, GQL, gRPC, etc. without respect to its actual tenants.
Post reply on HN