After 6 years, I'm over GraphQL

thats not a graphql thing. my startup uses graphql and it does not map anywhere near closer to 1:1 with our database. what you're talking about is the litany of RAD api backend apps that take your db and expose a graphql endpoint.

Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article.

In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time debugging, this is true for any codebase.

But GraphQL has everything in it to make such problems even harder. And both these projects had clear signs of "learning-on-the-go" with loads of bad practices (especially for the N+1 problem). Issue descriptions were much vaguer, harder to find in logs and performance issues popped up in the most random places (code that had been running and untouched for ages).

Fun fact; in both these projects the original devs who set it up were no longer involved. Probably spreading their evangalism further elsewhere.

RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.

That might be what they meant by "robust permissions model".

I still love GraphQL, but much of the love comes from using tools like PostGraphile which generates the API for you based on your database schema. I then add my own Javascript plugins as necessary. Going back to REST and hand writing everything gives me the shivers, how much time am I spending just translating data A to data B?

Authorization: I do it in the database using roles, row level security and column level security. It works well and I defer everything to PostgreSQL's security controls, it feels like the right place to do it and I don't have to worry about it going out of fashion, PostgreSQL is here to stay. Anybody else who talks to the database directly is also subject to the same authorization rules, which is nice.

Introspection: this should really be disabled on production services. Only enable it for development.

N+1 problem: I don't really have a problem with N+1 because PostGraphile converts the request into an efficient query. In other cases this problem presents itself in REST too and the article proposes hoisting N+1 queries to the controller, but that's just really moving the problem around, and you can do this with GraphQL too.

The other problems, yeah sure they are present and a worry if you're running some highly visible/very loaded public API.

Whenever you see REST in the article, think RPC. The author even says REST is simpler than GraphQL but I suspect they hadn’t implemented a REST API… ever.