3 ms·
Then you haven’t used them. They are to rest apis what rest were to soap times ten. You don’t have to take my word for it though, try it yourself: https://grap
by eksemplar 8y ago
Then you haven’t used them. They are to rest apis what rest were to soap times ten.
You don’t have to take my word for it though, try it yourself: https://graphql.org/swapi-graphql/ https://graphql.org/swapi-graphql/
- pjmlp 8y agoYou mean like dropping the documentation and schema validation tools that REST still wasn't able to match beyond what Swagger kind of offers?
- learc83 8y agoThat's a very strong statement. I have used them and I dont agree with this at all. I suppose next you're going to say I haven't used them enough?
- eksemplar 8y agoI 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.
- learc83 8y agoI'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.