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

91–100 of 103 posts

Re: GraphQL vs. REST APIs: a complete guide

#91

Post by DangitBobby »

nonethewiser wrote: post #51
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…

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.

You can modify REST endpoints to support selects and filters.

Re: GraphQL vs. REST APIs: a complete guide

#92

Post by twodave »

marcosdumay wrote: post #90
twodave wrote: post #87

Earlier quoted context omitted.

Thanks, this is thought-provoking. I went and did some reading—-am I mistaken for thinking simply disabling introspection in production is a hard counter to this? I realize for a public API (or API product) that isn’t super helpful, but for my own use cases nobody on production needs it. Other than that, it seems that the answer is just performing object-level authorization to ensure you never leak resources a user i…

Yes, if your data is not entirely public, you will need object-level autorization. But the point is that no, it's not straightforward; the authorization must be designed to fit your needs. If you are not designing it, you can be certain that it's broken.

Thanks for taking the time to explain. You’ve helped me revise my opinion (yes, some folks are willing to receive new information and change haha).

Re: GraphQL vs. REST APIs: a complete guide

#93

Post by arwhatever »

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…

Do teams tend to use GraphQL Schema to synchronize syntactic expectations between FE and BE?

My experience in doing so is limited, but I do know that this synchronization tends to be difficult and really like the idea of an explicit contract-based synchronization strategy.

It seems like a very big potential benefit but again, I don’t have enough direct experience doing too so be willing to put much stake in defending it.

Re: GraphQL vs. REST APIs: a complete guide

#94

Post by satvikpendem »

timr wrote: post #32
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…

I mean...ok, but...wow. You built a compiler?? For writing a web app? And you're not Facebook? Look, maybe this is totally appropriate for your application domain. I don't know. But this kind of "power" is immensely complex. We have to be honest about the costs. I have to keep reminding people that essentially all functionality of the modern web existed prior to 2012.

Their entire company is developer tooling with GraphQL, so it's not like they made a compiler for their own specific web app; they're selling their service. I agree if you're just making a run of the mill web app that it's crazy but they're an infrastructure company, not a web app company.

Re: GraphQL vs. REST APIs: a complete guide

#95

Post by satvikpendem »

timr wrote: post #71
nonethewiser wrote: post #69

Earlier quoted context omitted.

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

Or you can use GraphQL and get all of that functionality for free.

Re: GraphQL vs. REST APIs: a complete guide

#96

Post by chiefalchemist »

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…

I'm not worried about the DB. Less down the pipe to the browser or app means the user can get to see something sooner. It also mean less for the hardware / browser + JS to swallow.

Minor? Maybe.

Until you have users with less powerful mobile devices using less than ideal wifi / internet connections.

If work provides you with a new device (either as a company perk or because you're well paid) and you live in a major city where mobile data speeds are great these things don't matter. For most everyone else they do.

I suppose this explains why so many mobile experiences are so bad? People like you feel the user experience is "utter bullshit". Shame on you.

Re: GraphQL vs. REST APIs: a complete guide

#97

Post by unusualmonkey »

dmitriid wrote: post #82
IceDane wrote: post #66

Earlier quoted context omitted.

> I don't want to get into a debate about this. I've told you what I believe and why I believe it. You've told me what you believe, but not why. You just made vague, handwavy assertions about things that you clearly understand rather poorly. Obviously you don't want to debate this, since your arguments are those of a flat-earther trying to explain their views. > I will add this: if you are truly at a company that has…

> It's not possible to build GQL query footguns. GQL literally allows unbounded queries. All the "tooling" around like "field complexity", "data loaders" and other hacks are literally that: hacks and workarounds, and they are not even consistently, evenly or even efficiently implemented among the various GQL libraries and frameworks. > it automatically comes with documentation for your API Unless it's specified in co…

1) If you're building an internal tool... why do you care about 'hyperoptimised queries'?

2) Try Hasura (or similar).

Sure, if your goal is 'I want to hand write hyper-optimized queries for every imaginable use-case' then graphql sucks. That's not what it's designed to do.

If your goal is to fast front-end development, reasonable efficient network usage, and combining different services together it's great. Tools like Hasura go an extra mile and offload a lot of work from the BE team.

Re: GraphQL vs. REST APIs: a complete guide

#98

Post by timr »

satvikpendem wrote: post #95
timr wrote: post #71

Earlier quoted context omitted.

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

Or you can use GraphQL and get all of that functionality for free.

Where "free" means "lots of developer burden", sure.

Let's kill this fly with a chainsaw. It's free!

Re: GraphQL vs. REST APIs: a complete guide

#99

Post by satvikpendem »

timr wrote: post #98
satvikpendem wrote: post #95

Earlier quoted context omitted.

Or you can use GraphQL and get all of that functionality for free.

Where "free" means "lots of developer burden", sure. Let's kill this fly with a chainsaw. It's free!

I've never experienced the problems you say you have with GraphQL, to be honest, and I've been using it for quite a while.

Re: GraphQL vs. REST APIs: a complete guide

#100

Post by yencabulator »

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.

It hasn't seen much outside adoption, you might enjoy the ideas behind Netflix's Falcor: https://netflix.github.io/falcor/

You can think of it as larger-than-what's-downloaded dynamically-generated JSON object with internal pointers where you can ask to access wanted paths. (Sort of like GraphQL is a larger-than-what's-downloaded dynamically-generated non-JSON object.) One trick they use is that the path segments can also be objects, so `{from: 100, to: 200}` is a valid path segment, and this is how you build fancier query logic with in.

https://youtu.be/hOE6nVVr14c?t=977

Post reply on HN