DEV Community

loading...

Discussion on: What if we would share code instead of packages?

Collapse
imkleats profile image
Ian Kleats

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 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.

Collapse
valeriavg profile image
Valeria Author

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.

Collapse
imkleats profile image
Ian Kleats

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?

Thread Thread
valeriavg profile image
Valeria Author

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.