4 ms·
One of the issues with graphql is that it doesn't use HTTP semantics. Errors are 200 status with an error field in the body. Queries are POST /graphql for eve
by regularfry 5y ago
One of the issues with graphql is that it doesn't use HTTP semantics. Errors are 200 status with an error field in the body. Queries are POST /graphql for everything (ok, so they don't have to be, but once you've got anything in your system that needs to go over a POST request, everything else will).
This is problematic in any environment which expects those arguments to have been settled a decade ago and has built its monitoring around them. Ask me how I know.
- rswail 5y agoGraphQL is a query language that is being bent out of shape to support modifying things at the server end.
- schoenobates 5y agobut mutations have been in there since the beginning IIRC
- Chris2048 5y agoBut how does that cause problems? b/c the monitoring software cannot see the errors? Well, even if it did, it presumably wouldn't be able to make sense of the error field anyway; so it either has support for graph-ql specifically, or cannot see the errors. If the resolution of monitoring is literally is-200/not-200 a basic level of customisation should allow for "has error field" as a second error condition. Saying "expects those arguments to have been settled a decade ago" ignores that little in HTTP endpoints is settled, and building brittle software around these assumptions is the problem.