Wanted: Rust sync web framework

[diziet]

tl;dr: Please recommend me a high-level Rust server-side web framework which is sync and does not plan to move to an async api.

Why

Async Rust gives somewhat higher performance. But it is considerably less convenient and ergonomic than using threads for concurrency. Much work is ongoing to improve matters, but I doubt async Rust will ever be as easy to write as sync Rust.

"Even" sync multithreaded Rust is very fast (and light on memory use) compared to many things people write web apps in. The vast majority of web applications do not need the additional performance (which is typically a percentage, not a factor).

So it is rather disappointing to find that all the review articles I read, and all the web framework authors, seem to have assumed that async is the inevitable future. There should be room for both sync and async. Please let universal use of async not be the inevitable future!

What

I would like a web framework that provides a sync API (something like Rocket 0.4's API would be ideal) and will remain sync. It should probably use (async) hyper underneath.

So far I have not found one single web framework on crates.io that neither is already async nor suggests that its authors intend to move to an async API. Some review articles I found even excluded sync frameworks entirely!

Answers in the comments please :-).

Comments

[(Anonymous)]

Yeah reqwest comes with a gorilla holding the banana, and the whole jungle. I have used some curl bindings which are a bit closer to being just the banana I wanted; there is also https://github.com/algesten/ureq which says it will not become async. (I have not tried ureq myself.)

Iron

[roguelazer]

I've used iron for a few projects. It's not particularly maintained any more, but I'm not aware of any big outstanding issues with it.

Re: Iron

[(Anonymous)]

Iron has a nice design, but it definitely is unmaintained. Some of the dependencies have known RUSTSEC advisories.

[(Anonymous)]

It seems like all the io-related ecosystem ecosystem is moving toward async, so having a sync framework wouldn't probably be enough. E.g. there's no sync sqlx or tracing.

Rocket

[(Anonymous)]

You can use Rocket (even 0.5) with sync handlers. No need to go async.

Re: Rocket

[diziet]

I had assumed that if you wrote sync handlers, and those sync handlers blocked, you would block a worker thread in the Tokio thread pool. So you shouldn't do that. Does Tokio 0.5 maintain a separate (presumably much larger) thread pool for sync requests then?

[(Anonymous)]

rouille (https://github.com/tomaka/rouille) is a nice micro-framework that I've enjoyed using at work. Simple, sync, and no plans for async. We've similarly been wanting a framework for the reasons you outlined above.

Rouille has been unmaintained for a while and had some RustSec issues last time I checked, but there has recently been new activity/releases on the repo . Fingers crossed for long term support.