> there is a lot more work a team has to do to build and maintain a GraphQL API

I wouldn't say that. It's simple and straightforward to get around some pitfalls of GraphQL, if you treat it as an enumerated set of RPC-style endpoints.

The commenter I was replying to stated "Thr fact that you're arguing that it should not be treated as a generic query language when it's in the name and this is how it's sold is hilaruous". Perhaps so. By far the biggest mistake I think the original designers of GraphQL made was putting "QL" in the name, as many people think it's in the same category of tools as SQL (I heard someone ask once on HN "Can you do joins in GraphQL?", which isn't even a question that makes sense). It should be treated as a competitor to OpenAPI, and there are reasons why I would prefer using GraphQL in many scenarios.

I think I'll probably write some longer form blog posts at some point about how I think GraphQL is easy to set up and get running quickly, and how to avoid some common misconceptions.

As a beginner to GraphQL, I found your comments very informative, thanks. Though, it could have come off more personal to GP, with this sentence, "I strongly disagree with every single one of your points." It may have been a bit strong. But, this is intellectual discourse, and we're here to learn.

Back to it, thinking of GraphQL as more the way you describe it being similar to OpenAPI, is interesting. Would love to read more if you do blog on it. Any resources you recommend to understand it better?

> It's simple and straightforward to get around some pitfalls of GraphQL

It isn't

> if you treat it as an enumerated set of RPC-style endpoints.

It's not that.

> I think the original designers of GraphQL made was putting "QL" in the name, as many people think it's in the same category of tools as SQL

"GraphQL is a query language for APIs" is literally the tagline at https://graphql.org/

And the frankly insane complexity of GraphQL comes from the fact that you now have to implement that query language, often over completely different sources of data.

Which leads to frankly inane solutions like the requirement to inspect the full request and the full response on the fly just to be able to cache responses.

> By far the biggest mistake I think the original designers of GraphQL made was putting "QL" in the name

No. The biggest mistake why not emphasising to people the usecase they solved which was having many many different front end consumers and having to create many permutations of the same endpoints to cover web, mobile, various applications in different states, time to deliver endpoints to the teams. Etc

Most people are not working on the same number of implementations that Facebook or similar need. But they want to be on the bandwagon.