4 ms·

What you've said is true of any aggregating intermediate API, graphql or not. If you don't want to make n calls, you make a single API endpoint that makes two c

What you've said is true of any aggregating intermediate API, graphql or not. If you don't want to make n calls, you make a single API endpoint that makes two calls for your one, just like when you compose functions in code. You don't need GraphQL for this. GraphQL only really brings a novel way of defining what data you want. That's it. GraphQL fixes none of your data fetching problems if you're responsible for the actual end to end solution - if anything it gives you more. It's marketed at front end devs, who in my experience, really love _easy_ solutions, rather than simple. As far as I can see, there is precisely one scenario where GraphQL makes sense - and that's where you are trying to build a lot of separate frontend clients which will consume the same large, complicated data model. And unless both of those things are true, GraphQL is going to cost you more than the value it adds.

shantly 7y ago
> As far as I can see, there is precisely one scenario where GraphQL makes sense - and that's where you are building an unbounded number of front end clients which will consume a complex data model. And unless both of those things are true, GraphQL is going to cost you more than the value it adds. That matches my impression. Frankly I don’t think it’s very interesting. But damned if 3/4 the webtech-focused job postings I see don’t list “graphQL experience” under the nice-to-haves.
jholman 7y ago
> As far as I can see, there is precisely one scenario where GraphQL makes sense - and that's where you are trying to build a lot of separate frontend clients which will consume the same large, complicated data model. And unless both of those things are true, GraphQL is going to cost you more than the value it adds. Exactly