relay-transforms: optionally use native gql fragment spreads for unmasked fragments

[sjbarag]

When Relay encountered a fragment spread with the @relay(mask: false) directive, it would previously inline that fragment text into the query itself. This is completely valid and equivalent to a native GraphQL fragment spread. That inlining can dramatically increase the size of serialize for a query with multiple fragments. Such repetition compresses extremely well, but clients and servers still pay the cost of having uncompressed strings in-memory (plus compress/decompress time).

Allow relay users to opt out of fragment inlining for @relay(mask: false) fragment spreads in queries, using a native GraphQL fragment spread. The reader AST and type generation are not affected so there's no impact to the relay runtime.

CC @Lalitha-Iyer

[evanyeung]

Hi @sjbarag, thanks for the PR. However, we generally discourage the use of @relay(mask: false) as an anti-pattern now as it breaks component encapsulation. Instead, a similar directive that fulfills the usual cases for @relay(mask: false) is @inline. Rather than updating the @relay directive, does this meet your needs?

[sjbarag]

Hi @sjbarag, thanks for the PR. However, we generally discourage the use of @relay(mask: false) as an anti-pattern now as it breaks component encapsulation. Instead, a similar directive that fulfills the usual cases for @relay(mask: false) is @inline. Rather than updating the @relay directive, does this meet your needs?

Heyyy @evanyeung! Netflix has ~300 uses of @relay(mask: false) at the moment, so it's a pretty expensive migration. We'd like to get there, but it'll take quite a bit of time.

In the meantime though, this PR would reduce some of our query text strings by 93% (from 343_773 bytes to 22_078 bytes). That feels like a major win for anyone using @relay(mask: false) with minimal maintenance cost, even if it's discouraged.

[sjbarag]

Hi @sjbarag, thanks for the PR. However, we generally discourage the use of @relay(mask: false) as an anti-pattern now as it breaks component encapsulation. Instead, a similar directive that fulfills the usual cases for @relay(mask: false) is @inline. Rather than updating the @relay directive, does this meet your needs?

Heyyy @evanyeung! Netflix has ~300 uses of @relay(mask: false) at the moment, so it's a pretty expensive migration. We'd like to get there, but it'll take quite a bit of time.

In the meantime though, this PR would reduce some of our query text strings by 93% (from 343_773 bytes to 22_078 bytes). That feels like a major win for anyone using @relay(mask: false) with minimal maintenance cost, even if it's discouraged.

(bump) Any further thoughts on whether this PR will be considered? 🙂