-
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
Support defer/stream spec proposal #3121
Conversation
Awesome, thanks for sending this! Any interest in adding equivalent support to the rust version of the compiler? :-) |
@josephsavona I added support to the rust compiler. I did not run it against any actual code though, just worked through the tests. |
@@ -125,6 +125,7 @@ impl<'s> ConnectionTransform<'s> { | |||
for arg in &connection_directive.arguments { | |||
if arg.name.item == DEFER_STREAM_CONSTANTS.if_arg | |||
|| arg.name.item == DEFER_STREAM_CONSTANTS.initial_count_arg | |||
|| arg.name.item == DEFER_STREAM_CONSTANTS.initial_count_arg_oss |
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 don't think this is the right approach. It should be either, not both. Have a look at how i'm currently supporting fb/oss for connection things.
https://github.com/facebook/relay/pull/3112/files#diff-86ef1b8ad53dcd24d2a88fabf01a1fc7R40
There is a few issues with it though, so still ironing out the kinks
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.
My assumption is the schema you are working with is not likely to support both. In this case if you did pass both initialCount
and initial_count
to a @stream_connection
directive, you will get a schema validation error that one of those args is invalid.
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.
No sorry. Its more that both shouldn't be supported at the same time. As the spec will dictate the oss variant should be used. All I was saying, is to instead of or the 2, put it behind a compiler flag, such that OSS people only get the spec version.
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.
Agree here: rather than have the code allow either argument name, this would ideally be a compiler config (similar to what we do for connections, which also have different naming internally and in OSS). Then the code would just check for that single name.
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.
@josephsavona is the compiler config for the js compiler in the Relay repo? I only see the OSS names https://github.com/facebook/relay/blob/master/packages/relay-runtime/handlers/connection/ConnectionInterface.js#L55
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.
Yeah we have an internal version of that file too, which uses FB's naming (basically the same but snake case). I think we can do the same thing, just put all the constants in a file similar to ConnectionInterface, and then we can maintain an internal version.
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.
@josephsavona I updated the PR to add a config to the JS compiler similar to the ConnectionInterface. '
The hasNext
=> extensions.is_final
is still a runtime check, since it is not a just a property name change (and the check is in relay-runtime not the compiler).
I also removed the rust change. @maraisr maybe you can help out and add it to your pr #3112?
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 1386365 for how we can add this to the config in the Relay Rust compiler (we could rename connectionConfig to schemaConfig or similar if we want to avoid bloat?)
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.
Awesome, the changes here look good. We can make any final tweaks when we import. However, I do think we should wait until the final version of the spec is approved (just to avoid extra work on our side). Has that already happened?
@josephsavona the spec is not approved. The consensus from the last GraphQL WG meeting was that the next step is to get |
56df551
to
3d745e1
Compare
@josephsavona @kassens official experimental branches of graphql-js with support for Do you think this can be merged so Relay users can easily start testing out Still working on/trying to get help on the rust compiler, I can open a separate PR when that is ready. |
it would be great for the next Relay release |
a5aecaf
to
76375df
Compare
@josephsavona @kassens I updated this PR to make the same change to the rust compiler. It was a little more involved than the |
76375df
to
03c75a3
Compare
Curious what the status of this PR is - it looks like it was being held until the spec was approved (which it has been now), but is now a bit stale and has conflicts. Definitely interested in using this and could help contribute. |
Oh, I see, they are still experimental. |
Would be great to have this merged soon, so we can start experimenting with defer and stream in Relay. Seems like Apollo Client has planned support for this in September. :-) |
1d4dcfb
to
b828aeb
Compare
@alunyov @rbalicki2 This branch up to date and working again. It's set up the same was as ConnectionInterface, a new DeferStreamInterface can be passed to the config, replacing the static DEFER_STREAM_CONSTANTS. The changes are somewhat large, but very repetitive, as the new interface needed to be passed to several transforms. I've separated the changes to relay-runtime, compiler code, test code, and test fixtures into separate commits which should make it easier to review. |
b828aeb
to
fb81711
Compare
transform_connections(&program, &project_config.schema_config.connection_interface) | ||
transform_connections( | ||
&program, | ||
&project_config.schema_config.connection_interface, |
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 think we should consider adding schema_config
directly to the program
.
We already have Arc<Schema>
there. And I think it would be easier if we can just always have them together: schema
and schema_config
.
Let me try this internally.
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.
Update: I could not come up with a better version of the Schema with Config. We have some some non-relay users of Programs/Schema, so adding a dependency on relay-config
doesn't make sense for them. And adding something like a trait for Program
is a bigger change.
Let's keep it for now, but maybe in this specific line: let's pass a &project_config.schema_config
to the transform_connections
instead of individual config options.
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.
@alunyov I've updated transform_connections
to accept schema_config
fb81711
to
26ee9b4
Compare
@alunyov has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@robrichard, I have imported this PR internally. It still needs some additional handling to land it internally. Also, @rbalicki2 was working on this integration recently. I think, once Robert is back from the holidays, he may have some feedback. But overall, this looks great, and I'm pretty optimistic that this will land soon. Thank you for your work! |
26ee9b4
to
1726748
Compare
# Conflicts: # packages/relay-runtime/store/RelayModernQueryExecutor.js
# Conflicts: # compiler/crates/relay-compiler/tests/compile_relay_artifacts/mod.rs # compiler/crates/relay-lsp/src/graphql_tools/mod.rs # compiler/crates/relay-typegen/tests/generate_flow/mod.rs # compiler/crates/relay-typegen/tests/generate_typescript/mod.rs
1726748
to
9ecd619
Compare
Any updates on this? |
Continued in #4467 |
This change will allow Relay to support
@defer
/@stream
in the form that is currently being proposed to the GraphQL WG:Draft Spec: graphql/graphql-spec#742
GraphQL-js: graphql/graphql-js#2319
This works by allowing either
initial_count
orinitialCount
as an argument for@stream
. Whichever one is passed will be forwarded to the GraphQL server.Additionally, either
extensions.is_final: true
orhasNext: false
will be used to track final payloads.