Open enisdenjo opened 6 months ago
Ideal scenario in this lib is to not have a graphql-js dependency. Therefore @skip and @include for pre-execution.
I’ve been doing it all pre-planning, which is nice because it renders the request into its final shape early (before planning and execution). The downside is that plan caching becomes more nuanced because the plan includes contextual state. Apollo plans everything statically I believe, then evaluates conditionals while executing the plan and again while shaping the result. I like the static nature of their plans, but dislike handling the concern at multiple steps in the workflow.
In what capacity? Pre-rendering the request shape or evaluating conditions during both pre- and post-execution? If the later, why? I'm on the fence about the value of it.