The whole post shows the author hasn't fully understood what GraphQL actually is, and why it's used. But this one: > 6. REST is better for error handling and

The whole post shows the author hasn't fully understood what GraphQL actually is, and why it's used. But this one: > 6. REST is better for error handling and tooling > Error handling in REST is easier when compared to GraphQL. RESTful APIs follow the HTTP spec with regards to resources and returns various HTTP statues for various API request states. GraphQL, on the other hand, returns the 200 Ok status for every API request, including for errors. This makes it difficult to manage errors and makes it hard to integrate with monitoring tools. This is a misconception that seems to be quite hard to shake. Yes graphql returns 200 OK even when there's errors inside the response. But thats not a bug, it goes to the design of the whole thing. Think of graphql as a data transport layer. Any HTTP code that indicates an error is likely unrelated to your query, and is usually handled somewhere else. For example if you get a 4xx response your auth token is probably expired. Any errors in your query in a well designed schema can be seen inline. type Me { name: String email: String | AccessDeniedError } If you weren't allowed to access `me.email` you'd get the type `AccessDeniedError` which you can handle directly in your code. Instead of having to chuck out the whole query and return a HTTP Status code. GraphQL can also be sent over web sockets. HTTP means nothing to it. This talk explains it way better than I just did, but note it's a really powerful feature. https://www.youtube.com/watch?v=RDNTP66oY2o https://www.youtube.com/watch?v=RDNTP66oY2o