DEV Community

[Comment from a deleted post]
Collapse
 
valeriavg profile image
Valeria

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?

 
valeriavg profile image
Valeria • Edited

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.