Skip to content
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

Return a Future from app.serve #163

Closed
yoshuawuyts opened this issue Apr 11, 2019 · 6 comments
Closed

Return a Future from app.serve #163

yoshuawuyts opened this issue Apr 11, 2019 · 6 comments

Comments

@yoshuawuyts
Copy link
Member

Feature Request

Detailed Description

Instead of creating a runtime inside app.serve, I propose we return a future instead that allows people to run the app on whichever runtime they choose.

Context

From the API it currently isn't clear that Tide operates asynchronously. Also things like starting a database in parallel to Tide feels a bit awkward because async control flow primitives such as try_join and select don't work.

I propose we move from this:

#![feature(async_await)]

fn main() -> Result<(), failure::Error> {
    let mut app = tide::App::new(());
    app.at("/").get(async move |_| "Hello, world!");
    app.serve("127.0.0.1:8000")?;
}

To this:

#![feature(async_await)]

fn main() -> Result<(), failure::Error> {
    my_runtime::run(async {
        let mut app = tide::App::new(());
        app.at("/").get(async move |_| "Hello, world!");
        await!(app.serve("127.0.0.1:8000")?);
    })
}

We then shift the problem to making my_runtime::run nicer to use, but that's something that's worth solving for the whole async ecosystem, and not just Tide.

Possible Implementation

We would need to patch this line: https://github.com/rustasync/http-service/blob/master/http-service-hyper/src/lib.rs#L94, and propagate it through to Tide.

@secretfader
Copy link

Within the bounds of this proposal, is it possible to still provide a "batteries-included" runtime experience for new users?

@LucioFranco
Copy link

@secretfader you could have it return a custom future, that then as a function on it call say sync that will block and start the server. Under the hood it would consume itself, pass itself to a runtime.

@Texlo-Dev
Copy link

I agree with this proposal. Currently, it is a challenge to set up an asynchronous database pool with Tide, as you can't use the same runtime as Tide.

@yoshuawuyts
Copy link
Member Author

yoshuawuyts commented Apr 20, 2019

With Runtime we'll be able to also get rid of most of the boilerplate this change would introduce 😊 :

#![feature(async_await)]

#[runtime::main(runtime_tokio::Tokio)]
async fn main() -> Result<(), failure::Error> {
    let mut app = tide::App::new(());
    app.at("/").get(async move |_| "Hello, world!");
    await!(app.serve("127.0.0.1:8000"))?;
}

@tirr-c
Copy link
Collaborator

tirr-c commented Apr 21, 2019

I'm working on this, the update on http-service-hyper is here: http-rs/http-service#21

@fairingrey
Copy link
Contributor

Closed via #203

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

No branches or pull requests

6 participants