These are just assertions with little to back them up. As TFA says, you can make all the same claims for REST. And GraphQL works the same as REST. But instead of a complex mishmash if positional and named parameters, it has a super simple query structure.
When you create a stack of REST APIs, you’re creating a DSL. But it’s a DSL with arbitrary and frequently undocumented relationships between objects, no type safety, and masses of hidden complexity.
GraphQL is simple. If you don’t think it’s simple, you don’t understand it.
> One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs.
The clients are unnecessary. You can get ridiculously complex clients for REST, too. But you can also use GraphQL just using fetch().
The only material difference between the two from a client perspective is:
* REST gives you everything, even if you don’t want it
* GraphQL requires you to request what you want using a minimal query language.
GraphQL also lets you perform multiple queries in parallel, on the server, which REST can’t easily do.
REST is a PITA for any data model that’s more complex than CRUD.
When you create a stack of REST APIs, you’re creating a DSL. But it’s a DSL with arbitrary and frequently undocumented relationships between objects, no type safety, and masses of hidden complexity.
GraphQL is simple. If you don’t think it’s simple, you don’t understand it.
> One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs.
The clients are unnecessary. You can get ridiculously complex clients for REST, too. But you can also use GraphQL just using fetch().
The only material difference between the two from a client perspective is:
* REST gives you everything, even if you don’t want it
* GraphQL requires you to request what you want using a minimal query language.
GraphQL also lets you perform multiple queries in parallel, on the server, which REST can’t easily do.
REST is a PITA for any data model that’s more complex than CRUD.