As much as I opposed GeaphQL at first I found a use case for it and have been using it successfully for past 4 years. In my application GraphQL is just a layer on top of GRPC API. It helps to fetch data across different services and glue together different entities in one frontend friendly payload. Since GraphQL is essentially a proxy in front of GRPC (which is the real API, exposed over REST endpoints as an alternative to GraphQL) I haven't suffered from most of the issues described by author.
Authorization is performed by GRPC which returns only fields available to the user, rate limiting is performed on GRPC requests so at some point your data will start coming partially if you make too many queries or query that is too complex, N+1 problem is still there, but in a distributed system it's there even without GraphQL, the mitigation is caching in GraphQL server on GRPC request level.
In my experience GeaphQL really helped decouple frontend and backend and I'm pretty happy about it.
Besides GraphQL offers some standard way of making server side event streaming, it's not supported that well, but at least it's more comprehensive than bare web sockets.
I never got around to implement mutations though, individual change requests via REST are enough.
Authorization is performed by GRPC which returns only fields available to the user, rate limiting is performed on GRPC requests so at some point your data will start coming partially if you make too many queries or query that is too complex, N+1 problem is still there, but in a distributed system it's there even without GraphQL, the mitigation is caching in GraphQL server on GRPC request level.
In my experience GeaphQL really helped decouple frontend and backend and I'm pretty happy about it.
Besides GraphQL offers some standard way of making server side event streaming, it's not supported that well, but at least it's more comprehensive than bare web sockets.
I never got around to implement mutations though, individual change requests via REST are enough.