There has been some discussions recently about how to handle errors in GraphQL resolvers. I mentioned apollo-errors because I had very good exper...
For further actions, you may consider blocking this person and/or reporting abuse
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
helmetfor all resolvers, without having to wrap all of them explicitly withhelmet(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 everHi, 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 🙂
I was pointed here by a question I posted on Spectrum:
spectrum.chat/?t=6f834d41-f2c2-476...
This is exactly what I needed, thank you! 🙌
Awesome, glad that you like the article. You are very welcome 🙂
Now this was exactly what I needed. Thanks for posting