Skip to content

Implementation for juniper_actix #603

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

Merged
merged 3 commits into from
Apr 21, 2020

Conversation

engylemure
Copy link
Contributor

This PR implements the integration with actix-web 2.0 and has a initial study on the implementation of the GraphQL subscriptions int othe actix as well, i made some small addition in the juniper_subscriptions as well a submodule for storing the message types sent between the client and server, added a trait as well for handling some lifecycle events in the subscription such as on_connection and some other ones, since right now the implementation depends on a unsafe operation for sending messages this is just a alpha implementation and would like to receive some reviews on it.
I made some tests and examples as well for handling all things that were implemented.

PR Checklist

Before submitting a PR, you should follow these steps to prevent redundant churn or CI failures:

  • Ensure proper formatting
  • Run all tests
  • Update the CHANGELOG

Error in CI

for some reason my CI is not working and it is being caused by the juniper_rocket crate requiring the nightly build, the tests in the nightly are running just fine in the stable they are just breaking...

@engylemure engylemure force-pushed the juniper_actix_subscriptions branch 7 times, most recently from 58f6249 to 35c0bc2 Compare April 6, 2020 21:29
Copy link
Member

@LegNeato LegNeato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To fix CI you need to add juniper_actix to

@@ -135,6 +135,94 @@ where
}
}

/// Subscriptions Protocol Message Types
/// to know more access https://github.com/apollographql/subscriptions-transport-ws/blob/master/PROTOCOL.md
pub mod message_types {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally this is an enum.

// in the moment im considering that this value is
// the first text message sent by the Client with the
// type GQL_CONNECTION_INIT
connection_params: &str,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to not have it there if it is not defined. If there are specific params, we should do an enum with an ::Other(String).

/// Empty SubscriptionLifeCycleHandler
pub struct EmptySubscriptionLifecycleHandler {}

impl EmptySubscriptionLifecycleHandler {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be deleted and just derive Default.

// type GQL_CONNECTION_INIT
connection_params: &str,
context: &mut Context,
) -> Result<(), String>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be an error enum rather than a string.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What kind of values this enum should have?


/// Trait based on the SubscriptionServer
/// https://www.apollographql.com/docs/graphql-subscriptions/lifecycle-events/
pub trait SubscriptionLifecycleHandler<Context>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this should be a state machine? Also on_ functions don't feel idiomatic...not sure what the best way to handle it tough.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made some changes but since I doesn't have much experience into how this state machine should be implemented a example should be of great help to me.

@engylemure engylemure force-pushed the juniper_actix_subscriptions branch from 711874c to 0a821a2 Compare April 10, 2020 05:58
@@ -135,6 +136,108 @@ where
}
}

/// Enum of Subscription Protocol Message Types
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmm, it looks like this is a non-standard extension right? The only standard I see is http://spec.graphql.org/draft/#sec-Subscription

Copy link
Contributor Author

@engylemure engylemure Apr 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it makes sense, it is specific to the implementation of subscriptions over WS.

@LegNeato
Copy link
Member

Would it be too much trouble to pull actix-web stuff out of this and into another PR so we can look at the subscription changes on their own?

@engylemure
Copy link
Contributor Author

Would it be too much trouble to pull actix-web stuff out of this and into another PR so we can look at the subscription changes on their own?

No, i made another PR with only these changes #617 and merged this PR into it.

@LegNeato
Copy link
Member

It looks like the ws stuff is still in this PR. Can we just include the actix integration so I can merge it and then iterate on the websocket stuff in #617?

@engylemure engylemure force-pushed the juniper_actix_subscriptions branch from 4979397 to 10dadd7 Compare April 20, 2020 13:16
@engylemure
Copy link
Contributor Author

It looks like the ws stuff is still in this PR. Can we just include the actix integration so I can merge it and then iterate on the websocket stuff in #617?

Sure

@engylemure engylemure changed the title Implementation for juniper_actix and a initial study on subscriptions Implementation for juniper_actix Apr 20, 2020
@LegNeato LegNeato merged commit a47d1c5 into graphql-rust:master Apr 21, 2020
@LegNeato
Copy link
Member

Thank you again, this looks great. The community has really wanted this!

Also, appreciate you making so many changes to the PR 🍻.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants