3 ms·
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
by dmitryminkovsky 7y ago
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.
- adamscybot 7y agoThat 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.
- dmitryminkovsky 7y agoLocally, 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.
- dmitriid 7y ago> 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.
- dmitryminkovsky 7y ago> 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 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.