I understand that most people use GraphQL over HTTP and that from a developer perspective you’d rather have HTTP status codes like every other REST API. To which I’d say, why don’t you just use REST instead?
There are a bunch of legitimate reasons why a clean separation of transport layer and application layer makes sense - you just aren’t using them so it feels like an arbitrary frustration to you.
Have you ever run an application like a golang REST API behind an envoy or nginx proxy or load balancer and gotten an HTTP status 500 back and wrongly assumed it was coming from your application/golang code, only to later find it was a problem at the proxy or load balancer? If so, you’ve experienced the misdirection of combining transport and application layer being forced to share a status field. This isn’t a trivial example - time is wasted every day by developers misdiagnosing errors originating from transport as application errors, and vice versa.
You might not like it, but separating them IS smart design.
misdiagnosing errors originating from transport as application errors, and vice versa.
Shouldn’t the response body disambiguaite clearly whose fault it is? I mean you have to anyway if you advocate for ‘200 for everything’. You still have that same response body whether the HTTP status code is 200 or 500.
We honor the status code while providing an error body and it’s always blatantly obvious whether it’s an infrastructure issue or “true backend” issue when we see an issue. In my team I can’t recall anyone ever getting confused for even a little bit about whether an observed anomaly was web infrastructure or the backend, despite us setting HTTP status codes to error when, you know, we see an error.
Logs, logs, logs, you’ll pour over logs anyway. Hands up anyone who has run GraphQL over anything but http? Won’t be many. And then another show of hands please: who’s written a basic request using http tooling instead? Bet there’s tons!
They threw away loads of tooling for the sake of vanity imo
What do you mean? You can literally run GraphQL without HTTP. This isn’t just a GraphQL-ism, gRPC also does it https://grpc.io/docs/guides/status-codes/
I understand that most people use GraphQL over HTTP and that from a developer perspective you’d rather have HTTP status codes like every other REST API. To which I’d say, why don’t you just use REST instead?
There are a bunch of legitimate reasons why a clean separation of transport layer and application layer makes sense - you just aren’t using them so it feels like an arbitrary frustration to you.
Have you ever run an application like a golang REST API behind an envoy or nginx proxy or load balancer and gotten an HTTP status 500 back and wrongly assumed it was coming from your application/golang code, only to later find it was a problem at the proxy or load balancer? If so, you’ve experienced the misdirection of combining transport and application layer being forced to share a status field. This isn’t a trivial example - time is wasted every day by developers misdiagnosing errors originating from transport as application errors, and vice versa.
You might not like it, but separating them IS smart design.
Shouldn’t the response body disambiguaite clearly whose fault it is? I mean you have to anyway if you advocate for ‘200 for everything’. You still have that same response body whether the HTTP status code is 200 or 500.
We honor the status code while providing an error body and it’s always blatantly obvious whether it’s an infrastructure issue or “true backend” issue when we see an issue. In my team I can’t recall anyone ever getting confused for even a little bit about whether an observed anomaly was web infrastructure or the backend, despite us setting HTTP status codes to error when, you know, we see an error.
Logs, logs, logs, you’ll pour over logs anyway. Hands up anyone who has run GraphQL over anything but http? Won’t be many. And then another show of hands please: who’s written a basic request using http tooling instead? Bet there’s tons!
They threw away loads of tooling for the sake of vanity imo