Man I got excited until I saw the date. I disagree with always returning 200 (why should the caller need to parse the response to find out there was an error). Then again I don't understand why you would reach for graphql unless you are a massive org with a lot of front end teams (which isn't my works use case even though someone got distracted by the shiny thing and made it the standard) so my opinion is probably skewed.

1. The problem is with using HTTP for APIs, not with GraphQL. HTTP was designed for rich (hypertext) documents, not for APIs. So layering GraphQL or any other APIs over HTTP is a hack.

2. GraphQL is useful for small remote teams b/c of mandatory staticly-typed schema and built-in schema documentation. Otherwise it's lots of back-and-forth between backen, frontend, QA, etc. You forced to use external tools like Postman collections, and still having communication problems.