Hacker News Reader

Comment by DrFell | Hacker News Reader

GraphQL is a technology only a frontend webdev could love. You really want the burden of understanding the database schema and building the JS framework app? You really want ad-hoc data models written in some weird 'query language' littered throughout your frontend code? Building an API is actually easy, if you bother. 'No! GraphQL is lit!' OK kid, have fun snicker.

View on HN

Don't be snarky.

https://news.ycombinator.com/newsguidelines.html

No, I prefer writing an API endpoint and controller method for every resource I need to use on the client.

It is just as easy as lots of things we take for granted, line making a new app route, or component. That is a non issue.

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.

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

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.

It's clear from your comment you've not actually used the thing you are criticizing.

Nothing about the spec necessitates duplicating your DB schema.

In terms of the data models, you only need to spec out models based on what you want returned.

It's perfectly fine to have limited data models for only what's being requested in a specific use case.

Reply on news.ycombinator.com