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

Stabilize HTTP library #17

Open
SergioBenitez opened this Issue Oct 1, 2016 · 59 comments

Comments

@SergioBenitez
Owner

SergioBenitez commented Oct 1, 2016

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.

@SergioBenitez SergioBenitez added this to the 1.0 milestone Oct 4, 2016

@steveklabnik

This comment has been minimized.

steveklabnik commented Dec 23, 2016

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

@aturon

This comment has been minimized.

aturon commented Dec 23, 2016

@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

This comment has been minimized.

yazaddaruvala commented Dec 24, 2016

@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

This comment has been minimized.

blaenk commented Jan 11, 2017

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

This comment has been minimized.

Owner

SergioBenitez commented Jan 11, 2017

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

This comment has been minimized.

blaenk commented Jan 11, 2017

You're right! Clearly misread on my part.

@yazaddaruvala

This comment has been minimized.

yazaddaruvala commented Jan 12, 2017

@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

This comment has been minimized.

Owner

SergioBenitez commented Jan 12, 2017

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

This comment has been minimized.

flosse commented Jan 18, 2017

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

@thedrow

This comment has been minimized.

thedrow commented Jan 23, 2017

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

This comment has been minimized.

mgattozzi commented Jan 23, 2017

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

@JonasZ95

This comment has been minimized.

JonasZ95 commented Feb 22, 2017

@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

This comment has been minimized.

Owner

SergioBenitez commented Mar 9, 2017

@JonasZ95 I certainly didn't say that.

@webbrandon

This comment has been minimized.

webbrandon commented Jun 10, 2017

@flosse

This comment has been minimized.

flosse commented Jun 13, 2017

FYI: hyper v0.11 just released :)

@beatgammit

This comment has been minimized.

beatgammit commented Jul 25, 2017

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

This comment has been minimized.

Contributor

lnicola commented Jul 25, 2017

@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

This comment has been minimized.

lilianmoraru commented Sep 4, 2017

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

@harryfei

This comment has been minimized.

harryfei commented Feb 12, 2018

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

This comment has been minimized.

mersinvald commented Feb 14, 2018

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

This comment has been minimized.

alexreg commented Jun 7, 2018

@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

This comment has been minimized.

alexreg commented Jun 7, 2018

@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

This comment has been minimized.

krircc commented Jun 7, 2018

@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

This comment has been minimized.

xvny commented Jun 7, 2018

@hayd

This comment has been minimized.

hayd commented Jun 7, 2018

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 comment has been minimized.

alexreg commented Jun 7, 2018

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

This comment has been minimized.

JMurph2015 commented Jun 24, 2018

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

This comment has been minimized.

oblitum commented Jun 24, 2018

@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

This comment has been minimized.

apiraino commented Jun 24, 2018

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

TY - thank you ;-)

@JMurph2015

This comment has been minimized.

JMurph2015 commented Jun 25, 2018

@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 has been minimized.

oblitum commented Jun 25, 2018

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

This comment has been minimized.

JMurph2015 commented Jun 25, 2018

@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

This comment has been minimized.

JMurph2015 commented Jun 25, 2018

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

This comment has been minimized.

oblitum commented Jun 25, 2018

Just seems to be getting increasingly toxic.

@hayd

This comment has been minimized.

hayd commented Jun 25, 2018

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

This comment has been minimized.

dvic commented Aug 22, 2018

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

@SergioBenitez

This comment has been minimized.

Owner

SergioBenitez commented Aug 23, 2018

@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

This comment has been minimized.

geromueller commented Oct 13, 2018

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

This comment has been minimized.

mgattozzi commented Oct 15, 2018

@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

This comment has been minimized.

Contributor

lnicola commented Oct 15, 2018

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

This comment has been minimized.

geromueller commented Oct 15, 2018

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

This comment has been minimized.

Contributor

lnicola commented Oct 15, 2018

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

This comment has been minimized.

geromueller commented Oct 15, 2018

  • 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

This comment has been minimized.

Contributor

lnicola commented Oct 15, 2018

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

This comment has been minimized.

steveklabnik commented Oct 15, 2018

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

@geromueller

This comment has been minimized.

geromueller commented Oct 15, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment