[hn_throwaway_99]

This is what I see as a huge misconception of GraphQL, and unfortunately proliferates due to lots of simple "Just expose your whole DB as a GraphQL API!" type tools.

It's quite simple (easier in my opinion than in REST) to build a targeted set of GraphQL endpoints that fit end-user needs while being secure and performant. Also, as the other user posted, "edges" and "nodes" has nothing to do with the core GraphQL spec itself.

[slow_donkey]

I don't disagree with you, but graphql just lends itself well to bad decisions and many times when I've poked at graphql endpoints they share these issues (missing auth after first later, exposing schema by accident, no depth/cost limit). I think a combination of new technology w/o standardized best practices and startups being resource constrained proliferates poor security with graphql.

Of course, the same could happen for standard REST as well, but I think the foot guns are more limited.

[hn_throwaway_99]

I think I would agree. I'm a huge GraphQL fanboy, but one of the things I've posted many many times that I hate about GraphQL is that it has "QL" in the name, so a lot people think it is somehow analogous to SQL or some other generic query language.

So you get these very generic GraphQL APIs that map closely to the DB, when the exact opposite should be the case, that the APIs map as close as possible to the front-end use cases, and data is presented so that the front ends should need to have little, if any, customized view display logic. It even says so at the beginning of the spec:

> Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that.

[Aeolun]

> no depth/cost limit

Or you can do like us, there’s no depth at all, since our types do not have any possible subqueries.