-
Notifications
You must be signed in to change notification settings - Fork 440
Add integration crate for the warp framework #216
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
Conversation
cbc7241
to
b7cdb76
Compare
juniper_warp/src/lib.rs
Outdated
) -> BoxedFilter<(impl warp::Reply,)> | ||
where | ||
Context: Send + Sync + 'static, | ||
// CtxRef: AsRef<Context> + Send + 'static, |
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.
this should be deleted
Context: Send + Sync + 'static, | ||
// CtxRef: AsRef<Context> + Send + 'static, | ||
Query: juniper::GraphQLType<Context = Context, TypeInfo = ()> + Send + Sync + 'static, | ||
Mutation: juniper::GraphQLType<Context = Context, TypeInfo = ()> + Send + Sync + 'static, |
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 played with the design quite a bit, maybe not all of these bounds are needed anymore
This is looking great! I'm just coming up to speed, but if you are not aware we have an integration test harness you likely want to leverage. Here's Rocket using it: https://github.com/graphql-rust/juniper/blob/master/juniper_rocket/src/lib.rs#L453 |
I wasn't aware of that, thanks for the pointer! |
.and(juniper_warp::graphiql_handler("/graphql")) | ||
.or(homepage), | ||
).or(warp::path("graphql").and(graphql_filter)) | ||
.with(log), |
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.
with a few more days of warp experience, this doesn't look like the right way to do it, I'll have to improve this. Should this be a single file example by the way? I haven't worked with those but this one is meant to be run and used in a browser
Just a heads up: I am in vacations for the next 10 days so I will probably not work on this, but I intend to finish it after. |
Small update on this: I spent some time setting up the framework integration harness, and GET query parameters handling is a bit weird when testing a filter directly, I may have to change the tests to spawn a whole server to test against instead. edit: this is solved, now other tests are failing |
40c9281
to
d80c1b8
Compare
Ok now all tests are passing locally (I haven't seen on CI yet). There is the small matter of error handling - I introduced |
@LegNeato I think this is ready for review. There is an issue with rust 1.21 and 1.22 in CI - some warp dependencies don't seem to compile with these versions. If latest stable is the oldest supported compiler for warp, we should probably have the same requirement for juniper-warp. I haven't looked into how that could be implemented yet. What do you think? I'll squash before merging. |
juniper_warp/src/lib.rs
Outdated
/// let graphql_filter = make_graphql_filter(schema, context_extractor); | ||
/// | ||
/// let graphql_endpoint = warp::path("graphql") | ||
/// .and(warp::post(graphql_filter)); |
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.
this style of method filter is going to be deprecated, I'll change this next time I touch the code
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.
👍
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.
Looks great! A couple of small things. I am not really qualified to review to warp
portions so I will defer to you on those!
Cargo.toml
Outdated
"juniper_iron", | ||
"juniper_rocket", | ||
"juniper_warp", | ||
"juniper_warp/examples/warp_server", |
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 necessary? I don't believe we needed it for the other integrations.
juniper_warp/src/lib.rs
Outdated
/// let graphql_filter = make_graphql_filter(schema, context_extractor); | ||
/// | ||
/// let graphql_endpoint = warp::path("graphql") | ||
/// .and(warp::post(graphql_filter)); |
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.
👍
juniper_warp/src/lib.rs
Outdated
|
||
// if url.len() > 200 { | ||
// panic!("{:?}", url); | ||
// } |
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.
Delete.
impl HTTPIntegration for TestWarpIntegration { | ||
fn get(&self, url: &str) -> TestResponse { | ||
use percent_encoding::{percent_encode, DEFAULT_ENCODE_SET}; | ||
let url: String = percent_encode(url.replace("/?", "").as_bytes(), DEFAULT_ENCODE_SET) |
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.
This is fine for now, but I think we'll have the harness send valid encoded URLs so all these integrations don't have to deal with it themselves.
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'll check if it's possible to remove them, I remember I had to do the url encoding to make it work, but it could be a bug in warp (the framework is very young) - I'll try to open an issue on their side if that's the 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.
Oh, I wasn't clear...I was just musing out loud! I don't think there is a bug in warp or you changes here, but it is actually an issue with the integration test harness. See #230 (comment) for the same thing with Hyper, and I had to fix it hackily in the iron integration a bit ago in #208.
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.
Oh alright, sorry for the misunderstanding :)
No need to squash before merging, I can do that. As for rust version, I'm not sure. We could not include I'm happy to poke at the build stuff if you don't want to...just let me know! |
Agreed, the higher minimum version should only apply to juniper_warp. I'll try to make the CI setup adjustments and come back here if I run into trouble. |
you can take a look at the juniper rocket makefile.toml as an example |
I'll try to get this done some time this weekend. Just a note so we don't forget: we need some kind of thread pool, or document that this needs to be done by the user, since warp is async but juniper is not (yet). |
tokio currently has its own threadpool implementation that they claim is much faster than futures-cpupool. But mainly it is going to merge with the thread pool that will be built-in in the next major version of futures. This is probably what we will want to use eventually, but it's probably easier to use an external crate that does not depend on a particular version of futures (other than 0.1.*) or tokio at first (so futures-cpupool). What do you think of making the thread pool implicit in edit: to make it more explicit, there would be two functions: |
Codecov Report
@@ Coverage Diff @@
## master #216 +/- ##
==========================================
+ Coverage 86.98% 87.57% +0.58%
==========================================
Files 96 98 +2
Lines 14196 16680 +2484
==========================================
+ Hits 12349 14607 +2258
- Misses 1847 2073 +226
Continue to review full report at Codecov.
|
FYI, we ended up dropping support for rust 1.21 to move our dep on |
I'll push my latest changes (small improvements and some cargo make things that may not be necessary anymore) and see if I can make the Makefile.toml simpler, or even remove it. When depending on juniper through a |
b395304
to
8c1aa7f
Compare
Just found time to work on this a bit - the new http integration tests are passing now :) |
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!!! I think we are ready pending deleting the extra file.
@@ -0,0 +1,9 @@ | |||
# Exits successfully if the Rust version that is running is compatible with juniper_warp. |
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.
We don't need this file anymore, right?
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.
Oh definitely, my bad. I'll also try to see if we can revert to using cargo make with the new feature.
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.
We can do that in a follow-up, just delete this file for now.
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.
done
🎉🎉🎉🍻 🎉 🍻 I am publishing a new juniper + all the integration crates next week...I'll publish |
I think this still needs more testing but coming up with this integration was very smooth and it feels like idiomatic warp (I've only been programming with warp since its first public release, so yesterday :)).
I'll keep working on polishing this over the weekend (docs, tests) but feedback would still be appreciated.
This notably does not have support for batch requests. Should it be implemented in this PR or can it be done separately?