What I really like about GraphQL is that it completely get rides of the silly verb questions such as
- POST or PUT or PATCH?
- Why can't my GET or DELETE requests have a JSON body?
It is just a better interface, even if it where to be used exactly as REST without any nesting. I used the Appollo server in NodeJS and it was so natural to make parallel queries and let the query planner take care of the parallelism for me...
If you don't like the verbs you can always just use POST for everything...
My experience with GraphQL was a pain. We could have reduced queries if we changed our front end dev patterns, but we didn't and had the same number of queries as a REST pattern would have provided. Our GraphQL backend was a cobbled together mess of microservices that struggled with performance and stability. Queries could fail and we often wouldn't know why and bugs persisted for months despite work on them. We couldn't do simple things like cache queries to be reused between application launches without backflips and juggling expertise, Apollo client and all... And on and on and on.
Granted, not the best engineering shop. But in poor shops I find REST is simpler and thus less broken in practice.
- POST or PUT or PATCH?
- Why can't my GET or DELETE requests have a JSON body?
It is just a better interface, even if it where to be used exactly as REST without any nesting. I used the Appollo server in NodeJS and it was so natural to make parallel queries and let the query planner take care of the parallelism for me...