@maxd Thank you for sharing these important concerns and that article. You've raised valid points about GraphQL that definitely deserve careful consideration.
I completely agree that authorization and rate limiting present significant challenges in GraphQL implementations. The article you shared highlights these pain points well, and they're issues I've also witnessed in production environments.
That said, I'm still drawn to GraphQL + Relay because of the tremendous productivity benefits they offer on the client side. In my experience, features like declarative data fetching, automatic request batching, optimistic UI updates, and built-in pagination handling can dramatically reduce client-side complexity for certain applications.
Marc-Andre Giroux's thoughtful response article Why, after 8 years, I still like GraphQL sometimes in the right context acknowledges these challenges while offering a more nuanced view. As he points out, persisted queries are practically essential for addressing security and performance concerns - they transform GraphQL from “hard mode” into something much more manageable.
You're absolutely right that for open public APIs with untrusted clients, the challenges you mentioned become significantly harder to overcome. There's a reason we see fewer public GraphQL APIs compared to REST/OpenAPI ones.
I'm still learning and exploring this space myself, so I really appreciate your perspective. I think ultimately it comes down to carefully weighing these tradeoffs based on the specific context—the nature of the clients, team expertise, and data access patterns all factor into whether GraphQL's client-side benefits justify the server-side complexity for any given project.
Thanks again for adding this important dimension to the conversation!
