Skip to content
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

Closed
wants to merge 4 commits into from

Conversation

robrichard
Copy link
Contributor

@robrichard robrichard commented Jul 7, 2020

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 or initialCount as an argument for @stream. Whichever one is passed will be forwarded to the GraphQL server.

Additionally, either extensions.is_final: true or hasNext: false will be used to track final payloads.

@josephsavona
Copy link
Contributor

Awesome, thanks for sending this! Any interest in adding equivalent support to the rust version of the compiler? :-)

@robrichard
Copy link
Contributor Author

@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
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Member

@kassens kassens Jul 30, 2020

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?)

Copy link
Contributor

@josephsavona josephsavona left a 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?

@robrichard
Copy link
Contributor Author

@josephsavona the spec is not approved. The consensus from the last GraphQL WG meeting was that the next step is to get @defer and @stream merged to graphql-js behind an experimental flag. The intention is to make it easier for people to try it out and start getting real word feedback from outside of Facebook and 1stdibs before finalizing the spec. Maybe it makes sense to get this merged once the related code is in GraphQL-js (graphql/graphql-js#2319)?

@robrichard robrichard force-pushed the spec-defer branch 3 times, most recently from 56df551 to 3d745e1 Compare November 6, 2020 22:18
@robrichard
Copy link
Contributor Author

@josephsavona @kassens official experimental branches of graphql-js with support for @defer and @stream are now being published. The working group is aligned on this approach but is waiting on community feedback before finalizing.

Do you think this can be merged so Relay users can easily start testing out @defer and @stream?

Still working on/trying to get help on the rust compiler, I can open a separate PR when that is ready.

@sibelius
Copy link
Contributor

it would be great for the next Relay release

@robrichard robrichard force-pushed the spec-defer branch 2 times, most recently from a5aecaf to 76375df Compare December 21, 2020 14:57
@robrichard
Copy link
Contributor Author

robrichard commented Dec 21, 2020

@josephsavona @kassens I updated this PR to make the same change to the rust compiler. The check failures are also failing on master, locally cargo build and cargo test are working as expected.

It was a little more involved than the ConnectionInterface since the codegen also needs to be passed the configurable DeferStreamInterface in a bunch of places. I'm still a Rust beginner so let me know if anything could be done in a better way.

@chriserickson
Copy link

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.

@chriserickson
Copy link

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.

@sorenhoyer
Copy link

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. :-)

@robrichard robrichard force-pushed the spec-defer branch 2 times, most recently from 1d4dcfb to b828aeb Compare December 16, 2021 23:42
@robrichard
Copy link
Contributor Author

@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.

transform_connections(&program, &project_config.schema_config.connection_interface)
transform_connections(
&program,
&project_config.schema_config.connection_interface,
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

@facebook-github-bot
Copy link
Contributor

@alunyov has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@alunyov
Copy link
Contributor

alunyov commented Dec 20, 2021

@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!

# 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
@Tiedye
Copy link

Tiedye commented May 24, 2022

Any updates on this?

@robrichard
Copy link
Contributor Author

Continued in #4467

@robrichard robrichard closed this Oct 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants