This is a great write-up. I was already aware of most of the drawbacks that the author wrote about in the early days of GraphQL... Another category of solutions which was ignored completely is CRUD with field-granularity over WebSockets.

I've built platform which does just that: https://saasufy.com/

This approach has allowed me to create a library of highly generic components which can be composed into surprisingly complex front ends and where all data updates in real time (in a targeted, efficient and scalable way): https://github.com/Saasufy/saasufy-components?tab=readme-ov-...

You can build just about any front end you can imagine just by assembling these components. Almost no code needed. It takes me hours to build web applications which would take weeks or months to build. The real time update features come free. The dev experience is essentially bug free; any 'bugs' you may encounter have clear visual symptoms which can be 'debugged' by observing the HTML DOM.

I'm currently observing people getting hyped up over HTMX and it's kind of funny to realize that developers do actually like the declarative approach... And yet they're going in the wrong direction again. Just as they did with GraphQL.

It would have been impossible to do this with GraphQL because field-granularity/autonomy is essential. GraphQL queries combine different resources and fields together in complex ways and this makes it impossible to efficiently avoid real time update conflicts on the front end.