5 ms·
How else would you handle error codes without reducing efficiency by sending extra requests? One of the benefits of graphql is that you can query many different
by TheCoelacanth 5y ago
How else would you handle error codes without reducing efficiency by sending extra requests? One of the benefits of graphql is that you can query many different things in a single request, so some parts of your query could have errors without the whole thing resulting in an error.
- OJFord 5y agoThere's nothing special about the enum status code and binary (header described) response data of today. GQL has little choice, it can either call the whole thing an HTTP error, or, to be honest it probably does the right thing, it can call it a success and describe the error in the response data. In an hierarchical model of your choice, that's genuinely an HTTP-level success. In the sort of respecifying I'm describing, you could expand status codes to describe 'mixed' results, or 'upstream error's, or whatever. I don't really have great suggestions ready because my only point is that I think the status quo is bad.