Can I safely use the @include directive for an exp...
# apollo-kotlin
s
Can I safely use the @include directive for an experimental field in our schema which may in the future be removed in a backwards incompatible way? I'm thinking about adding a remotely controlled feature flag, the client uses that flag in the directive to conditionally query or not query for that field. Then if the backend keeps the field we keep the flag on, if the backend removes it in this backwards incompatible way, we flip the flag off and the old clients continue working perfectly fine since the @include is
false
so it would never even ask for the field in the first place. Or is it that it still sends it in the request, but the backend knows not to return it if the directive is set to false? So if the backend doesn't even know about the field in the first place then it'd fail the entire thing.
e
the client sends the whole query, whether or not the
@include
condition is true or false. and maybe it depends on the backend but everything I've worked with will validate the query against the scheme before considering the
@include
directive. so no, it is not useful for removing experimental fields in a compatible way
s
Welp, good to know. I was hoping it'd just not be sent at all from the client if the directive was evaluated as false. But no, I will have to build two separate queries then, and conditionally use one or the other in client code depending on the flag instead of using
@include
Thanks!
w
Fwiw you can test the behavior against your backend by adding a random field in the schema file (locally) and querying for it just like you explained, behind an include directive
m
Only way this would work is if you manipulated the query AST at runtime to remove the skipped fields.
w
Would that work with APQ? At least would make it more difficult to figure out hashes of known queries
e
yeah you'd have to recompute the query hashes, or at least precompute 2^N of them (with N conditions)
m
APQ would make a cache miss and then work automatically but for PQs yea, it grows exponentially with the number of feature flags
Also for regular PQs you'd need to do this both at build time (to register the queries) + run time (to prune the fields)