@include and @skip should omit the value entirely from a request payload

[BrentMifsud]

Use case

At my company, we often test our graph changes in a staging environment before doing our weekly releases.

So as a result, our schema often has new values in staging, but not in prod.

In this scenario, if our mobile changes are ready before our back end changes, our GQL queries will fail (Obviously because the new schema values aren't available in prod yet).

The first solution that came to our mind was to block those new values off with an @include(if: false) statement.

However the queries still fail in this scenario because the new fields are still passed along.

This ends up blocking our progress on mobile as we cant merge our changes in until back end is ready.

Describe the solution you'd like

@include(if: false) and @skip(if: true) should completely omit a value from a graphQL query's json request payload.

[AnthonyMDev]

Thanks for the suggestion @BrentMifsud.

The @include/@skip directives are evaluated with the input variables server side. While I understand your use case for what you are asking for, this isn't really what @include/@skip is intended for, and it's probably not a viable approach here.

If we did do this, it would have to be an opt-in feature, so we would have to maintain both sets of functionality. Changing the actual query document at runtime would be possible, but it adds a lot of complexity to the system. It also completely breaks with persisted queries and only allowing known operations, which is a recommended best practice in production.

---

I think that this issue with dev/production environments is still a pain point for clients. Apollo has done a lot of work to make this easier for backend teams with GraphQL, but we don't have a great story for this on any of our clients right now. I'd definitely like us to improve upon this. But I don't think co-opting the @include/@skip directives is the right approach.

This is really a tooling and DevOps issue, and until we have a solution for how to improve upon it baked in, I think you should be thinking about it from that perspective. You need to structure your repository and development environment in a way that accounts for differences in staging vs prod.

One approach I've used In the past, is having a dev branch that really functions as our primary branch for development work. This can work against a staging server, and you can merge feature branches into it. Then, when production is updated and you are ready to cut a release, you can merge the dev branch into your main or release branch.

Every project is different, so you'll have to figure out what approach works best for your team.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.