Hacker News Reader

Comment by dmitryminkovsky | Hacker News Reader

What’s the complexity you’re thinking of? In my experience, GraphQL is so much simpler than REST. There’s a whole category of thinking you don’t have to engage in (is this POST? PUT?). And to start I wouldn’t migrate from REST. I’d wrap a REST service with GraphQL and take it from there.

View on HN

That essentially means you are still overfetching underneath the hood but yeh -- for me the benefits are in its ergonomics anyway. The whole under/overfetch thing is overstated.

Locally, yes. But that’s not a big deal unless your network is that saturated. Also, with wrapping we’re just talking first steps. Anyway the overfetching thing is less about bandwidth and more about maintaining compatibility with older clients and knowing which clients require which fields. Since each GraphQL client explicitly states the fields it needs, it’s much easier to retire old fields.

> There’s a whole category of thinking you don’t have to engage in (is this POST? PUT?)

There’s a reason that category of thinking exists. But since GraphQL libs are now busy implementing caching in top of non-cacheable POST requests, this argument is lost on them.

> There’s a reason that category of thinking exists.

What's the reason?

> But since GraphQL libs are now busy implementing caching

What are you referring to? You mean like https://github.com/graphql/dataloader ?

> in top of non-cacheable POST requests, this argument is lost on them.

I think caching/serving HTTP results is a bad paradigm. It makes sense if you're serving HTML for a content site or something like that, but doesn't make sense when you're serving an API.

Reply on news.ycombinator.com