I think you may have been fortunate enough to use a lot of well documented rest APIs.
I work in the public sector, we integrate with more than 600 different IT systems. I’d say around 10% of them have the documentation they ought to.
With graphql, the API is the documentation.
On our own end, it’s improvee production and quality because it’s faster to build an API with it, that lives up to our standards for APIs. It’s also harder to fuck it up without realizing because it’s typed and forces schemes.
The last advantage is that it allows for an easy way to get the data you need from a general query, that might not be important in a lot of places, but when you build apps for workers who use them in a rural setting, it’s kind of nice to minimize the data they need to transmit to the bare essentials. You could do that with a rest api, but it would take a lot more time to implement.
I'm not going to rehash the numerous argument against GraphQL. My point is Plenty of people who have experience with REST, SOAP, various old school RPC protocols, and GraphQL (myself included) prefer REST.
The superiority of GraphQL is not as self-evident as you believe it is.
I work in the public sector, we integrate with more than 600 different IT systems. I’d say around 10% of them have the documentation they ought to.
With graphql, the API is the documentation.
On our own end, it’s improvee production and quality because it’s faster to build an API with it, that lives up to our standards for APIs. It’s also harder to fuck it up without realizing because it’s typed and forces schemes.
The last advantage is that it allows for an easy way to get the data you need from a general query, that might not be important in a lot of places, but when you build apps for workers who use them in a rural setting, it’s kind of nice to minimize the data they need to transmit to the bare essentials. You could do that with a rest api, but it would take a lot more time to implement.