Coincidentally I was reading through that exact part of the spec on errors yesterday and found a few neat things:
There is only one requirement for the relationship between data and errors return value: if the query is null/empty there must be an error message
The spec recommends that implementations provide a char index in the query in the error message where the error occurred. I don't think all servers I've tried follow this, but the major ones do IME
Overall, the GraphQl spec doesn't enforce a whole lot with the response format - it doesn't even need to be JSON!
I do like that the rules needed to have reliable interaction are pretty rigorously defined but it leaves room for extension of the protocol.
Hey André, thanks for a great post! I'll definitely use some of these pointers in my project.
Do you have any strategy for bulk-adding the handler helmet for all resolvers, without having to wrap all of them explicitly with helmet(resolver)? That'd be useful, at least in the beginning of a project before any needs for custom handling depending on resolver is needed, if ever
GraphQL Middleware package is doing exactly what you need. Try it.
I was pointed here by a question I posted on Spectrum:
This is exactly what I needed, thank you! 🙌
Awesome, glad that you like the article. You are very welcome 🙂
Hi, just made an account on dev.to to say thank you for this article! This was a missing piece in the puzzle that is GraphQL for me :).
That means a lot, Kees. Glad the article was the last puzzle piece. Awesome 🙂
Now this was exactly what I needed. Thanks for posting
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.