Just some are info about the express-graphql example. Based on this closed issue (github.com/graphql/express-graphql...), it is intentional and based on the caching behavior of the graphql function that is being used. Even if that is the case, it's kind of interesting to the point of your article -- layers of packages can tell you what the function does (validate the schema), but not what the code does or why it is/isn't a performance hit.
Edit:
Instead of taking the word of the devs on the Issue, I checked for myself. Here's the code forvalidateSchema. The GraphQLSchema object contains an internal property called __validationErrors. The validation context will return an empty array which still triggers the short-circuit if there has been some previous validation with no errors.
Thank you, I was not aware of that. In my defence, I cannot imagine a use case where updating schema at runtime won't be a terrible idea.
Totally agree with you. Just wanted to add that complexity is a consequence of a "black box" approach in code sharing: it forces maintainers to introduce "what-if" and "who-knows" features to keep their module universal.
No defense needed (in my opinion). It just made me sweat a little bit given my use of express-graphql so I wanted to verify. I ran into a problem with Apollo just a couple weeks back where their "hidden" caching of query Documents was giving me problems because I hadn't been deep-copying parts of the resolveInfo that I was passing through part of my own library for modification. I mean, partially my fault for not writing a pure function in the first place, but there's also no disclaimer about their memoization/caching relying on you only ever using pure functions?
Edit: There used to be a code for graphql validation function, its explained much better in the comments above
In my case this server was meant to run in Kubernetes, so if my schema is invalid I need it to crush on start and therefore stop new deployment version rollout.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just some are info about the
express-graphqlexample. Based on this closed issue (github.com/graphql/express-graphql...), it is intentional and based on the caching behavior of thegraphqlfunction that is being used. Even if that is the case, it's kind of interesting to the point of your article -- layers of packages can tell you what the function does (validate the schema), but not what the code does or why it is/isn't a performance hit.Edit:
Instead of taking the word of the devs on the Issue, I checked for myself. Here's the code for
validateSchema. The GraphQLSchema object contains an internal property called__validationErrors. The validation context will return an empty array which still triggers the short-circuit if there has been some previous validation with no errors.Thank you, I was not aware of that. In my defence, I cannot imagine a use case where updating schema at runtime won't be a terrible idea.
Totally agree with you. Just wanted to add that complexity is a consequence of a "black box" approach in code sharing: it forces maintainers to introduce "what-if" and "who-knows" features to keep their module universal.
No defense needed (in my opinion). It just made me sweat a little bit given my use of
express-graphqlso I wanted to verify. I ran into a problem with Apollo just a couple weeks back where their "hidden" caching of query Documents was giving me problems because I hadn't been deep-copying parts of theresolveInfothat I was passing through part of my own library for modification. I mean, partially my fault for not writing a pure function in the first place, but there's also no disclaimer about their memoization/caching relying on you only ever using pure functions?Edit: There used to be a code for graphql validation function, its explained much better in the comments above
In my case this server was meant to run in Kubernetes, so if my schema is invalid I need it to crush on start and therefore stop new deployment version rollout.