I don't see how you back your statement with any real arguments. Why do you think it's an improvement? A lot of the time people argue GraphQL is better than REST, what they actually mean is that they didn't want a set of conventions but rather an opinionated framework that made the decisions for them. REST gives you a lot of freedom to do it wrong. GraphQL on the other hand makes some assumptions and decides a few things for you. This makes it easier to use if you don't want to dive into the complexity of designing and building proper REST APIs. The outcome will be more or less identical.
Because those conventions are rarely ever followed. That freedom to do wrong is not a perk for most organizations, and having an opinionated and consistent data layer provides a lot of value to large teams.
That coupled with GQL automation and type generation has literally taken months off of the development cycle for the last two products I've built. That has a real $ value that has led to actual success for those products. Not to mention that these API's are extremely flexible for the end user in a way that comparable REST api's could only dream.
I really like your answer. I think that's a very good argument if you want to convince someone to start adopting GraphQL. Do you have anything beyond that?
We have a pretty robust unified graphql api that handles millions of requests per second. Its has recently replaced siloed REST api's and now provides a common interface and RBAC for all of our data, which is housed in 5 different DB engines.
Previously most of the data was in MongoDB, so implementing GQL allowed up to regression test the api surface while migrating the underlying data. Remote schemas and persistent queries were pretty integral to that effort.
