3 ms·

That's just moronic, I would even go as far that GraphQL is something only backend dev could love, the only benefits frontend dev gain using GraphQL is not havi

That's just moronic, I would even go as far that GraphQL is something only backend dev could love, the only benefits frontend dev gain using GraphQL is not having to wait on backend dev to change some random endpoint response. From a backend dev perspective GraphQL completely removes that chunk of work, solves the issue of over-fetching/under-fetching, and more importantly allows you to map your REST APIs into a single interface (and break your monolith into microservices transparently). If you're API is a todo list CRUD, then yes, you prob don't need GraphQL.

dang 7y ago
When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
DrFell 7y ago
If you're a backend dev that makes APIs, you probably won't like GraphQL (I am not one of those, BTW). If you have a big project with a team split into API devs and app devs, and you have to wait, then that is poor planing. Plus, just wait, jeez. Don't blame the separation of the work into roles for your problems, it is usually good, and often necessary. Then again, if you're full-stack developer, you can just go fix the endpoint yourself. I know the argument about over-fetching with an API is that you have to make one call, than loop through and make secondary calls, but you can mitigate that, it is rare, and is actually fine. Ad-hoc data modeling encourages over-fetching in it's own way. You always make in-situ calls for exactly the model shape you need right there. "That model is not quite the shape I want, I will do another query." Plus, with pre-defined data models you can save them, in like a state object, they are more reusable. You can even use them in a totally different program.

dang 7y ago

When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

DrFell 7y ago

If you're a backend dev that makes APIs, you probably won't like GraphQL (I am not one of those, BTW). If you have a big project with a team split into API devs and app devs, and you have to wait, then that is poor planing. Plus, just wait, jeez. Don't blame the separation of the work into roles for your problems, it is usually good, and often necessary. Then again, if you're full-stack developer, you can just go fix the endpoint yourself. I know the argument about over-fetching with an API is that you have to make one call, than loop through and make secondary calls, but you can mitigate that, it is rare, and is actually fine. Ad-hoc data modeling encourages over-fetching in it's own way. You always make in-situ calls for exactly the model shape you need right there. "That model is not quite the shape I want, I will do another query." Plus, with pre-defined data models you can save them, in like a state object, they are more reusable. You can even use them in a totally different program.