Stabilize HTTP library

[SergioBenitez]

At present, Rocket reexports Hyper types under http:hyper. Hyper causes a lot of issues, particularly when trying to optimize performance. A decision needs to be made on whether to stabilize these Hyper types, move away from Hyper (likely), or do something else all-together.

[steveklabnik]

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

[aturon]

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

[yazaddaruvala]

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

[blaenk]

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.

[SergioBenitez]

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.

[blaenk]

You're right! Clearly misread on my part.

[yazaddaruvala]

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

[SergioBenitez]

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.

[flosse]

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

[thedrow]

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.

[mgattozzi]

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

[JonasZ95]

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

[SergioBenitez]

@JonasZ95 I certainly didn't say that.

[webbrandon]

hyperium/hyper#304 (comment)

[flosse]

FYI: hyper v0.11 just released :)

[beatgammit]

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.

[lnicola]

@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"))
}

[lilianmoraru]

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

[harryfei]

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?

[mersinvald]

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.

[alexreg]

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

[alexreg]

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

[krircc]

@alexreg sorry I am no interesting about you words, I say the trues . you should know more actix/actix-web first, even if Rocket not use it.

[xvny]

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

[hayd]

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.

[alexreg]

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

[JMurph2015]

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/

[oblitum]

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

[apiraino]

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

TY - thank you ;-)

[JMurph2015]

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

[oblitum]

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

[JMurph2015]

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

[JMurph2015]

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?

[oblitum]

Just seems to be getting increasingly toxic.

[hayd]

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.

[dvic]

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

[SergioBenitez]

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

[geromueller]

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?

[mgattozzi]

@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

[lnicola]

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.

[geromueller]

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.

[lnicola]

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.

[geromueller]

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

[lnicola]

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.

[steveklabnik]

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

[geromueller]

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