I have an existing app, using native threads, and I'd like to add a http server to it. I'd like to create it as a separate thread(s), and be able to shut it down from the other parts of my code.
I'm investigating different Rust web framework, and usually this use-case sucks, because everyone seem to expect the http server is the whole app, and if it is ever to shut down, it should do so from inside of one the handlers.
I just started looking at warp, and it seems I could complete what I need using examples here: https://docs.rs/warp/0.1.10/warp/struct.Server.html#method.bind_with_graceful_shutdown but I'd like to complain that having users to create one-off channels is not a great API. Rust with it's deterministic destruction and ownership semantics is great at representing resources, and web-server is a good example of an actor-like resource.
What I'd like is the Rust-idomatic resource that represents the whole spawned http server (with it's threads), that I can call .stop(), .start() on, and that would eg. automatically gracefully stop and clean-up resources on drop.
The creation of a oneshot channel is simply for the example. The shutdown can be signaled by any kind of Future. The flexibility here is that you can also make use something like tokio-signal to provide a Future that triggers on a certain signal.
It should only be a few lines to have wrap a oneshot with your stop() function. Perhaps I am misunderstanding something?
I understand the rationale of the current API and the lower-level flexibility it provides. My point is ... a http server should be a "resource" - with reasonable auto-stop and cleanup on drop etc. When the users just wants to embed a http server into an app, it should be like a std::fs::File::open(), handling everything essential about it's lifecycle, and not having user figure out future's crate API. Maybe it's a job for a library on top o wrap or something... donno... but I can see it could be greatly improved.
We could try to improve this in warp. Possibly something like a background or detach function on Server, which would start up an additional thread to run in, and return an RAII type.
Is this possible now ?
Starting in 0.2, the Server is now a future that you can await, and you can drop it when you want it to stop. You can also use the graceful shutdown feature. I think that's close enough.
Hmm, wasnt successful in doing so. In a testing environment how would i run both a server and a client that executes requests against the server ?
@IMFIL could the autoreload example related to what are trying to accomplish? (didn't test it)
edit: also the graceful shutdown API
Most helpful comment
We could try to improve this in warp. Possibly something like a
backgroundordetachfunction onServer, which would start up an additional thread to run in, and return an RAII type.