Stabilize HTTP library about rocket HOT 68 CLOSED

@dvic In 0.5, we'll explore migrating to the latest version of hyper as well as futures (the ones compatible with async/await). I suspect that we'll need to modify hyper to fit Rocket's needs, but these modifications should be upstream-able and would benefit the community as a whole. With futures, my hope is that Rocket users will only need to deal with futures when they're doing something that's "interestingly" asynchronous. Otherwise, Rocket should handle everything asynchronously under the hood, free of ergonomic or performance charges.

from rocket.

I propose using https://github.com/actix/actix-web as the HTTP layer. It has the following features

• Extremely fast
• Asynchronous
• HTTP/2 support
• TLS support
• Middleware for CSRF, CORS, and others already included
• High-level, which means that Rocket will in many cases be able to pass data directly to actix-web.
• Very actively developed.

from rocket.

@SergioBenitez The Tokio team is working toward a 0.1 release of the Tokio stack, after which HTTP is likely to be more of a focus. We should try to work together in exploring the space. Let's be in touch!

from rocket.

As I said in my previous comment: Rocket will be fully asynchronous in the future. This issue will not be resolved until the HTTP server backend is stabilized, and this issue is currently set to be resolved before 1.0. I consider asynchronous I/O to be a requirement for stability.

from rocket.

FYI: hyper v0.11 just released :)

from rocket.

Tokio has reached version 0.1, not 1.0!

@yazaddaruvala To directly answer your question, there's no point to having the Rocket API know about any kind of asynchronous I/O as Rocket doesn't perform async. I/O. Having some notions of async. I/O that don't, in reality, perform the I/O asynchronously would be rather confusing.

I don't have a design I'm willing to commit to at this point. The Rust asynchronous I/O space is in heavy flux. The Tokio 0.1 release today is a milestone in reaching stability, but there's still a long road ahead. Rocket will be fully asynchronous in the future, but the approach must be made with care. Usability is of utmost importance, and performing and handling async. I/O with Rocket cannot be an exception.

from rocket.

BTW: Hyper just merged the tokio branch: hyperium/hyper@2d2d557

from rocket.

Futures Await now work on nightly: https://github.com/alexcrichton/futures-await

from rocket.

Litigating the useful-ness of asynchronous programming is extremely off-topic for this issue, IMHO. Could we maybe not do this here?

from rocket.

tokio 0.1 and futures 0.1 are intentionally excluded from the public API in my async branch by using the 0.1/0.3 compat layer in a few strategic places. Therefore, moving from hyper 0.12 to 0.13 is not much of a code change and it should only affect internal functions and maybe a few public header re-exports, unlike 0.10 to 0.12 which requires most of Rocket's public API to become async-aware. I would like that transition to happen before any betas or RCs for rocket 0.5, but the master branches of hyper and tokio are not quite ready yet the last time I tried.

I will be elaborating more on these and other async-related progress and problems in a tracking issue in the next several days if nothing critical comes up.

from rocket.

@SergioBenitez if the plan is to move to an async back end, why does the current API not use Futures? Or is the plan to change the API to a Futures based interface before 1.0? Or do you plan to keep the sync API interface but have an async backend?

from rocket.

Please can we stop this back-and-forth? It is not productive.
@SergioBenitez will research and choose whichever is best/most aesthetic for Rocket.
Most likely, as is now, whatever is chosen will be abstracted away from users.

from rocket.

Hi! I'm currently investigating all rust frameworks as an api service. Unfortunately all are in a bad state, as all want to jump on the async train. @SergioBenitez what about database access? What about easyness of coding? Async code is harder to implement and has nearly no speed improvement. A web framework is not a web server. Will rocket for sure switch to async in the near future?

from rocket.

A port to Hyper 0.12 seems to be in progress here: #1008 in case anyone else is interested.

from rocket.

I'd be very interested in hearing about your issues here. Also, have you used the tokio branch at all?

from rocket.

@lnicola Thanks. But hmm, I don’t like how actix-web is a web framework built on top if low-level HTTP stuff. No proper HTTP library. Gotham looks the best-engineered right now, I guess.

from rocket.

using synchronous handlers backed by futures-cpupool & hyper down to async connections
ergonomically the same as currently but not really beneficial since you cannot use async handlers

My two cents from the peanut gallery is that this is a reasonable way to start:

• you know you want to use async hyper eventually, and this is a nice small step toward doing so that can be tested independently of rocket interface changes. If it's not actually harmful, I think it's worth doing for that reason alone.
• it seems valuable for keepalive connections to not be consuming threads.
• my (untested) impression is that there have been other performance improvements in hyper 0.10.x -> hyper 0.11.x.
• there will be further improvements to hyper, such as HTTP 2 support in hyper 0.12.x, that are worth picking up.

from rocket.

@thedrow Hyper plans on doing HTTP2 support before hitting 1.0
hyperium/hyper#304

from rocket.

@mersinvald it would require updating hyper to 0.11 at the least in order to have async. However with the tokio reform moving to 0.2 soon and hyper 0.12 to follow not long afterwards it might be some time. Really though @SergioBenitez already said why he hasn't moved to async above early on in the thread:

I don't have a design I'm willing to commit to at this point. The Rust asynchronous I/O space is in heavy flux. The Tokio 0.1 release today is a milestone in reaching stability, but there's still a long road ahead. Rocket will be fully asynchronous in the future, but the approach must be made with care. Usability is of utmost importance, and performing and handling async. I/O with Rocket cannot be an exception.

from rocket.

Is there any update on this yet?

Also, I must say, I find the approach of actix rather odd... a) it ignores the community standard HTTP library that is hyper b) it chooses its own actor-based concurrency model rather than the community standard that is tokio (an event-loop-based model).

from rocket.

@alexreg I think you are wrong, actix-web base on tokio, future, async, stable. more steady than other library. additionally some companies use it in production。
please look at it closer first before say it "such an experimental library"

from rocket.

Right. No need to be rude about it though.

Anyway, there is still my point a. And regarding b, I find it odd that actix would build itself on top of tokio and yet change the entire paradigm. Maybe someone could kindly clarify.

from rocket.

Also what's with the thumbs down reactions in this thread? We're all here to make constructive conversation about the pros and cons of various approaches to solve a problem, no need to be pushy or rude?

from rocket.

Just as a note: actix-web is going to need a lot of TLC and a step change in its approach to the use of unsafe code before it can be called production ready. I'm not saying it's a "bad library" or anything like that, but right now, it has pieces of code that are completely UB and could really bite.

https://www.reddit.com/r/rust/comments/8s7gei/unsafe_rust_in_actixweb_other_libraries/

from rocket.

@apiraino Sorry for the acronym soup
TLC: Tender Loving Care
UB: Undefined Behavior
But really, I would do several double takes before using that in anything moderately valuable* to me. The code I read undermined the memory safety of everything that it touches. It's a very serious issue. If it isn't memory safe, why not use some other language (like Go or C++) and call it a day? This isn't trying to throw shade, but just acknowledging the situation.

*not using the 'in production" trope because these days if it doesn't come off of stone tablets written in lightning, someone will complain about it not being "production ready"

from rocket.

@alexreg There's some discussion of that here: https://www.reddit.com/r/rust/comments/8ni53t/the_state_of_gotham/dzvwftx/

But I see actix-web as more of a competitor to Rocket, not hyper.

from rocket.

@krircc Up-voting your own comments? And serial down-voting rather than replying? Wow, looks like someone is passive-agressive. 😂 Get a grip, man.

from rocket.

See my above comment:

Please can we stop this back-and-forth? It is not productive.
@SergioBenitez will research and choose whichever is best/most aesthetic for Rocket.
Most likely, as is now, whatever is chosen will be abstracted away from users.

We're not gaining anything by rehashing this.

from rocket.

@SergioBenitez Do I get this right, you don't have any plans to add futures as return values for handlers?

If so I think that icould be troublesome, because you may query a database in a handler which results mostly in IO. Returning a future would allow nice chaining.

from rocket.

This comment just sounds as out of place here, maybe ask them about the issue? AFAIK there's not even serious conversation about adoption of that or any other lib in Rocket, so will this thread be about opinions on every web framework?

Regarding actix, from what I can see they're serious on removing unsafe, and it was born just like yesterday, why the rush?!

from rocket.

@jebrosen @schrieveslaach thoughts on taking this Hyper upgrade effort/opportunity and go all the way up to Hyper 0.13 instead? Which supports async/await syntax.
Hyper is currently mostly ported towards std::future and async/await. I am pointing that because moving from 0.12 to 0.13 in the future would require another big refactor out of the .and_then().map().map_err() world.

I acknowledge that is mostly covered by @jebrosen's last comment on #1008

I know I am saying that as an outsider and both of you have put a lot of efforts and work into making this upgrade possible. Huge congrats on that btw!

from rocket.

@JonasZ95 I certainly didn't say that.

from rocket.

Rocket looks so nice, but its synchronous nature is still a showstopper for services requiring to access external APIs while handling requests.

Any progress on bringing async into rocket like an optional feature for writing handlers?
Maybe something like a custom Responder with a futures-cpupool as a back-end threadpool?
This would allow using async and sync API at the same time, as far as I understand.

How complex would it be to implement an initial support for futures-backed Rocket?
I could dive into it, but I definitely would like to hear a team vision on the topic.

from rocket.

@JMurph2015 it's a work in progress https://twitter.com/mitsuhiko/status/1010093896230146048. That it's also at the hands of the author of Flask turns it promising.

from rocket.

I'm also curious about what @yazaddaruvala said. It would seem to me that Futures would be returned as a a way of future-proofing for async. Then again, maybe it's possible to accommodate handlers that return Futures and those that don't? Perhaps even using codegen/procedural macros.

I ask in light of tokio reaching 1.0, hopefully increasing the pace at which async infrastructure is developed.

from rocket.

You're right! Clearly misread on my part.

from rocket.

@SergioBenitez I can appreciate that it might be too early to make implementation decisions. However, its not clear from your comment or the rest of this thread, and I'm curious about your vision.

Does sync IO, fit with your current vision of what Rocket will be? Asked a different way: Is there a possibility that, a future 1.0 release of Rocket could use synchronous IO or can you guarantee that the 1.0 release of Rocket (whenever that comes out) will be based on some implementation of async IO?

from rocket.

Do you guys think that HTTP 2 support is a separate issue? I don't think hyper supports it but the https://github.com/mlalic/solicit crate provides some degree of support.

from rocket.

hyperium/hyper#304 (comment)

from rocket.

Is this currently a development priority? If so, is someone working on it? I don't see a branch for this, so my guess is no.

I may be interested in helping port to hyper 0.11 (async), but I'm a bit unclear with the Rocket codebase (just started using it for a project) so I don't feel like I have a good intuition as to what a good API would look like.

from rocket.

@beatgammit Maybe look at tokio-minihttp.

Right now Rocket handlers can return anything implementing Responder. As a straw man user-facing API, we might want to allow handlers that look like:

#[get("/")]
// is this the proper syntax?
fn hello() -> impl Future<String, io::Error> {
    future::ok(String::from("hello"))
}

from rocket.

Repost the question #559 here.

Does anyone have experience with actix-web. It seems that it support HTTP, HTTP2, async concurrency and websocket which are needed to implement a morden web server.
Currently the Rocket use hyper as then web backend which limits HTTP2 and websocekt features. Shall we use actix-web to replace hyper to get all those features?
If we decide not to change our backend, shall we split our rocket sugar syntax code into a separate project, so that we can reuse it's code to add the nice syntax for other web framework?

from rocket.

@mersinvald
I experimented with something like that previously in 2 stages in this branch:

• using synchronous handlers backed by futures-cpupool & hyper down to async connections
  ergonomically the same as currently but not really beneficial since you cannot use async handlers
• introducing asynchronous handlers
  required enormous BC breaking changes and ergonomically much worse to use than synchronous handlers (This was before futures-await).

from rocket.

I see that #491 and #209 form a chain of references pointing here. I've just run into the first issue (where address = "localhost" and Rocket binds to just IPv6 and not IPv4, causing the client to be unable to connect) and want to make sure it doesn't get forgotten about. :)

from rocket.

[...] it chooses its own actor-based concurrency model rather than the community standard that is tokio (an event-loop-based model).

I'm sorry you're just wrong as you can see here the dependency is declared directly:

tokio = "0.1"

from rocket.

Right. No need to be rude about it though.

I'm sorry, I didn't want to be rude.

Anyway, there is still my point a.

Yes but wouldn't say "it ignores the community standard HTTP library that is hyper" but it's a great showcase for Rust and a different approach. That doesn't mean it's good or bad as a layer for Rocket.

And regarding b, I find it odd that actix would build itself on top of tokio and yet change the entire paradigm. Maybe someone could kindly clarify.

Again, I think all projects can profit from learning from different paradigms. We should discuss the pro & cons of a paradigm within a concrete context instead of just talking about "odd" libraries.

from rocket.

@flosse No worries. Anyway, I agree experimenting with different paradigms is a good thing, but Rocket is one of the most established web frameworks out there, so maybe not the best case for using such an experimental library. Anyway, I'm sure the devs of actix have a reason for not using hyper, but I'd certainly be curious to know what it is!

from rocket.

@krircc Using lots of features doesn't mean it's well-engineered. But that's your opinion. I wouldn't trust it with corner cases, personally. I know hyper handles those well. But then maybe I need to look at it closer...

from rocket.

The new benchmarks looks actix-web exicting https://www.techempower.com/benchmarks/#section=data-r16&hw=cl&test=json

from rocket.

This little dispute is over now, as far as I'm concerned. 😊Clearly some people are big fans of actix and others are not. It's personal preference at the end of the day. But I concur with @hayd, this is a decision for Sergio now. I'm sure he'll make a considered choice, whatever it is. He's produced a great framework in Rocket, and I am just looking forward to async support coming to it whatever the form. (People are always free to choose between Rocket, Gotham, actix-web, or another framework, and this isn't the place for debate such merits.)

from rocket.

@JMurph2015 just trying to disentagle the acronyms TLC (Testing Life Cycle) and UB (Undefined Behaviour); am I correct?

TY - thank you ;-)

from rocket.

@oblitum At some point Rocket may want to use another HTTP library so that it can support async operation asap. This thread was discussing options in that direction, and when I read it, I noticed that the safety angle of Actix had yet to be considered, and since it was still "in the running" so to speak, it was a relavent comment.

There isn't really a rush within Rocket to do this, but at the same time the ecosystem will jump on async operation as soon as support for it is ironed out, which is fast approaching.

from rocket.

Just seems to be getting increasingly toxic.

from rocket.

@SergioBenitez I was curious, have you figured out in what direction you want to move with the http layer?

from rocket.

@geromueller I don't know how much you know about the upcoming async stuff in Rust so I'm gonna give you the benefit of the doubt here. async in Rust that's coming up will let you write synchronous looking code, but have it all be async. All you have to do is slap async before a fn declaration. So I'm not sure how it's going to be harder. In fact it's better than what we currently have which is just the Futures 0.2 crate and idk if you've used it but the errors have been not fun. So as to your assertion that it's harder to implement? Yeah maybe for other languages, but for where Rust is going this should be a very ergonomic easy to use thing that a lot of work has been done on. It only gets hard if you build your own executor loop which most people won't need too. Tokio shall suffice for many.

As for database access again, shouldn't be a problem for the reasons I mentioned before, same goes for ease of coding. Hyper is has moved to async and newer versions will use async/await syntax. Assuming Rocket upgrades it's hyper dep it'll have to move over to it.

Async code is harder to implement and has nearly no speed improvement

Gonna need a use case or a citation for that one. Not saying it's wrong, but it sounds like that's the case for a specific use case

from rocket.

Gonna need a use case or a citation for that one. Not saying it's wrong, but it sounds like that's the case for a specific use case

Maybe see http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/. Anyway, most web apps don't need async, and for database access a thread pool is usually more than enough.

from rocket.

Thanks for the detailed reply @mgattozzi ! I had the results from the link @lnicola posted in mind as well as the discussion in diesel-rs/diesel#399 and the state of many async drivers in Java. I'd really like to write my service in Rust, but currently all franeworks are waiting for async stuff to happen and ready up for a complete rewrite. Tried actix-web and pushing database stuff into different threads and managing messages is far from easy convenient. I wrote a dispatcher in Python Twisted with the defer.inlineCallbacks which sounds like the async feature you are talking about. Yes, it makes it easier, but far from easyconvenient. Don't get me wrong, i'd like to see a fully async web framework as well, but it is still a very long way until all libraries are ready as well. And i just would like to see one or two frameworks to make an honest evaluation if they require async or not.

Edit:
In the last post I wrote "bad state" out of frustration. What i meant was volatile state, as big breaking changes might come to support async i/o. And i believe it will be big, since the whole idea is quite different. We used python gevent monkey patching in another project, and it worked for many things, but others broke badly.

from rocket.

I'd really like to write my service in Rust, but currently all franeworks are waiting for async stuff to happen and ready up for a complete rewrite.

tower-web and warp are async-first and are already usable, depending on what you expect from a web framework. I'm not a web dev, so I was fine with e.g. implementing sessions from scratch.

Tried actix-web and pushing database stuff into different threads and managing messages is far from easy convenient.

I have a tiny adapter that transforms any sync code into a Future that works with the blocking support in tokio. It's not that much of an inconvenience. Alternatively, any thread pool could do the same thing.

from rocket.

• They both are lacking database examples, for a good reason ;-)
• I read about that blocking feature in the diesel discussion as well. I did not find any example and how it is supported by the frameworks. You need some control over the amount / spawning of threads after all.

from rocket.

They both are lacking database examples, for a good reason ;-)

Maybe try making an example app and publishing it somewhere? I guarantee it's possible. If you start something and run into issues, you can ping me.

I did not find any example and how it is supported by the frameworks.

Right. As I said, I'm not a web dev, so I've no idea why a web framework should care about database access.

You need some control over the amount / spawning of threads after all.

Sure, with a thread pool you get that. With blocking, there's a (pretty large) number of threads that are made available by the runtime.

from rocket.

To summarize my concern: You can not just switch from sync to async without big changes in the user code. And for a new project API stability is an issue.
Edit: see here for problems popping up when you go async nodejs/node-v0.x-archive#7543

from rocket.

@viniciusd, I checked crates.io for Hyper 0.13 but I could not find the next minor release. Do you know that the next minor version is coming soon? If so and if @jebrosen agrees on it, I could try to upgrade his async branch to Hyper 0.13.

from rocket.

For the benefit of those following this issue, let's keep in mind that Hyper 0.13 will be far from being a minor release without breaking changes, this is the tracking issue.

They're moving from [email protected] to stable std::future::Future (released just one month ago). As much as I'd like Rocket to be async, I wouldn't stay too close to their bleeding edge.

from rocket.

As @apiraino pointed out, 0.13 hasn't yet been released. Hyper's master branch is going to be tagged as 0.13 at some point in the near future.

I would say we are already going for a breaking change moving from 0.10 to 0.12. Upgrading to 0.13 afterward would take just as much efforts if it isn't done at once

from rocket.

Hyper's master branch is going to be tagged as 0.13 at some point in the near future

genuine question, what indicates that it will be a near future? My limited understanding is that the path to [email protected] doesn't look straight, they're actively working on it.

My comment was more along the line of "I wouldnt hold my breath to have [email protected] soon, therefore I wouldnt push Rocket to rely on hyper@master. Happy to hear a more informed opinion!

from rocket.

I would expect hyper and tokio to get released after await hits stable, if not a bit earlier (as pre-release versions).

But I'm not affiliated with the projects, so I may be wrong.

from rocket.

If anyone wants to read about hyper v0.13: https://seanmonstar.com/post/189594157852/hyper-v013

from rocket.

Rocket 0.5 now exposes almost none of hyper, which means we don't need to consider the underlying HTTP library as a breaking dependency and can close this issue. We should, however, seek to implement now-missing functionality, such as #1067.

from rocket.