feat: add @mask directive

[vladar]

Work in progress

Initial implementation of the @mask directive as discussed here: #11666 (comment).

A potential solution for #11514

[netlify]

👷 Deploy request for apollo-client-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	28c3e6e

[changeset-bot]

⚠️ No Changeset found

Latest commit: 28c3e6e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[jerelmiller]

Hey @vladar 👋 Thanks for the PR!

Just an FYI, I'm still working through the data masking implementation and getting the APIs added to the appropriate spots in the codebase. I've got my in-progress work on the data-masking branch. The changes there may change significantly between now and any public release, so just be aware that anything you add in this PR may require refactoring to work with the changes introduced in that branch. I'd hate for you to spend a bunch of time maintaining this branch as things are still in flux.

Until I'm a little further along in the implementation and determine whether the @mask directive makes sense, I won't be able to accept these changes. For now, feel free to follow along on that branch for the in-progress work.

[vladar]

@jerelmiller this is just a playground PR, mostly for you if you want to play with @mask. Great to see progress on data masking in Apollo, thanks for driving it!

[jerelmiller]

Got it. Appreciate the context!

[jerelmiller]

Hey @vladar 👋

Thanks for your patience! We've had several team discussions and still really believe that the @unmask approach is the right approach for adopting the feature. We are going to move forward with that and won't be introducing a @mask directive to counter it. We believe in the long-term that a @mask directive will cause too much room for human error.

I agree with you that having a way to try out the data masking feature in a small subset of places is valuable. We will likely instead recommend in these cases that you create a separate client instance with the dataMasking option enabled and pass that to the client option in your hooks. It creates a bit more friction, but we believe this is ok for a "just trying it out" approach where you might want to create a proof-of-concept or test the feature.

Regardless, we'll try and include some kind of recommendation in our docs if you're looking for a "just try it out" approach.

As such, I'm going to go ahead and close this out. Thanks again for the PR and the idea!