-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow persisting to also include the query text for safe migration #3917
Conversation
Love it @tomgasson good moment this. |
e8836f5
to
688714f
Compare
Summary: We noticed that some of our query text contains a significant amount of unnecessary whitespace. Unlike server->client requests, client->server requests generally aren't compressed and would require a js compression library to do so. This PR adds a feature flag to compact the query text. I saw the pre-existing `compact` mode wasn't wired up to anything, so I've co-opted it. As an example of the benefit, we have one query which this shrinks from `84kb` to `31kb` We're slowly [making our way to persisted queries](#3917), but this is an immediate improvement and I imagine we're not the only ones who will benefit from smaller network payloads Happy to make this a config rather than a feature flag, if you don't think this should be the default output Pull Request resolved: #3983 Test Plan: Imported from GitHub, without a `Test Plan:` line. Static Docs Site previews have moved into the custom phabricator field "Static Docs", and will no longer modify test plans after 5th October 2022. Reviewed By: captbaritone Differential Revision: D39891556 Pulled By: captbaritone fbshipit-source-id: c11e0914beafe80069e170b9b5800ef507356ada
108abba
to
7b80335
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your PR and for your patience! Seems like a reasonable idea! I left some feedback.
|
||
match request_parameters.request_format { | ||
Some( | ||
RequestFormat::Text(Some(ref text)) | RequestFormat::Migration(_, Some(ref text)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above: Can RequestFormat have a method text() to get the text from the underlying variant?
params_object.push(id_prop); | ||
params_object.push(metadata_prop); | ||
params_object.push(name_prop); | ||
params_object.push(operation_kind_prop); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we unconditionally initialize the params object with the ones we know we are going to include and then just have one push for the request_format case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done it like this in order to maintain the existing artifact ordering. If I change this, it will invalidate all existing artifacts (even without this feature on). If that's okay to for you at Meta, I can do this - but wanted to reduce your churn
compiler/Cargo.lock
Outdated
@@ -1580,6 +1580,7 @@ dependencies = [ | |||
"graphql-test-helpers", | |||
"intern", | |||
"lazy_static", | |||
"relay-config", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this intentional?
pub enum RequestFormat { | ||
ID(QueryID), | ||
Text(Option<String>), | ||
Migration(QueryID, Option<String>), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we rename this to something more concrete? TextAndID
maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've simplified the structure to no longer need this additional struct
d6a1e23
to
ad7853f
Compare
@tomgasson and @captbaritone Thanks a ton for seeing this PR through. Do you know when can we expect this to be merged and available ? |
@captbaritone has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've imported the diff and it uncovered some Flow errors. I also left some requests to avoid the tuple matches and replace with nested if/else statements
ad7853f
to
4c3cf3d
Compare
4c3cf3d
to
50bbdb3
Compare
@captbaritone has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@captbaritone merged this pull request in 95c54b4. |
This has landed. Folks can try it out by using the @main NPM tag. Make sure you upgrade all of |
FYI, if you use local persist query you have to use the field name in snake_case, not camelCase. |
Hi folks.
We're attempting to start using persisted queries. However, we're not 100% confident in our ability to switch over to them in one big step safely.
Fetching the persisted documents is a new capability for our GraphQL server. If something goes wrong fetching the document, or if it introduces unexpected latency to our existing production queries we want to be able to fallback to the query text until we're more confident in its maturity.
Relay currently supports outputting the query text, or outputting the persisted document id. This PR introduces a middle state, where the text and id are both output. When both are sent with the GraphQL request from the client to the server, the server is able to control the rollout of persisted queries via a feature flag.
This PR introduces a
safeMigration
bool to the remote persist config, which when set will also output the query text in the operation params as well as the idThe benefits of persisted queries (saving the network bytes) won't come until we've progressed past the migration stage, but it makes it possible to do the move in the first place.