The State of Rust Web Frameworks
- 1. ARE WE WEB YET? THE STATE OF RUST WEB FRAMEWORKS
- 2. BACKGROUND THREE DOMAINS ▸ Microservices: tiny single-purpose services; often linked via HTTP ▸ APIs: backends that typically interact with a database and handle a wide range of requests ▸ Web applications: more complex applications that typically utilize things like cookies, input forms, and a templating engine
- 3. BACKGROUND CHALLENGES ▸ Way too many framework choices ▸ Database libraries still don’t support async that well ▸ Few blog posts etc. talking about real production usage ▸ Lack of adoption means that best practices haven’t really emerged in many areas (DB connection pooling, for example)
- 4. BACKGROUND FRAMEWORK SHORTLIST ▸ Raw hyper ▸ Rocket ▸ Warp ▸ Tower-web ▸ Actix-web
- 5. BACKGROUND FRAMEWORK EVALUATION CRITERIA ▸ State of maintenance ▸ Ease of use ▸ Performance ▸ Feature set
- 6. RAW HYPER: THE GOOD ▸ The foundation of all other good frameworks ▸ Well-maintained ▸ Blazing fast ▸ Futures-based
- 7. RAW HYPER: THE BAD ▸ Not really a framework so expect to write lots of boilerplate ▸ Learning curve ▸ Futures-based
- 8. ROCKET: THE GOOD ▸ Nice website ▸ Fantastic documentation (best in class by a wide margin) ▸ Actively maintained ▸ Almost as easy as using a modern Python framework ▸ Resulting code was extremely concise
- 9. ROCKET: THE BAD ▸ Seems to be largely controlled by a single maintainer who dictates the release cycle ▸ Built on outdated dependencies (most notably hyper) ▸ Performance was anything but rocket-like. Terrible stability under heavy load; save yourself the headache and just use Python
- 10. WARP: THE GOOD ▸ It’s fast ▸ It’s small
- 11. WARP: THE BAD ▸ It was basically designed to explore a single concept: everything is a “filter” ▸ It has a fairly steep learning curve
- 12. TOWER-WEB: THE GOOD ▸ Supports macro-based route definitions like Rocket ▸ Reasonable handling of shared app state ▸ Support for handlebars templating built-in
- 13. TOWER-WEB: THE BAD ▸ Lacks many basic features like query string binding during the request flow ▸ Parsing capabilities it does have are terribly handicapped (example: not supporting floating point values) ▸ Requires some weird macro wrapping stuff around your application struct
- 14. ACTIX-WEB: THE GOOD ▸ Good documentation ▸ Still async, but allows you to bring in sync code easily ▸ Probably as close to raw hyper performance as any framework will come soon ▸ Very close to a 1.0 release ▸ 3-8x faster than carefully written Python for non-trivial tasks
- 15. ACTIX-WEB: THE BAD ▸ Much more verbose than I’d like ▸ Taking a paradigm designed for one language and porting it to another seems odd to me, but they did a great job ▸ Databases seem to be somewhat an afterthought, and the examples don’t really show the proper way to do things
- 16. CONCLUSIONS ▸ Most frameworks are pretty immature and don’t seem to see serious production use ▸ Not enough attention is paid to developer ergonomics ▸ Rust is a viable choice for APIs and microservices where high performance is critical, but be prepared to put in a lot of upfront work for a larger web app ▸ Futures/async will probably be the thing that trips you up the most, but actix makes things tolerable
- 17. CONCLUSIONS ▸ Async database drivers are still immature ▸ Even among the frameworks I disliked, most niceties like input parsing are so fast they’re basically free ▸ If you want high performance, Rust can more than deliver
- 18. OBLIGATORY REQ/SEC BENCHMARK (AVG. OF 3 RUNS ON MY MACBOOK) 1 10 100 1K 10K 100K HELLO POSTGIS 2.18K 79.12K 2.31K 62.8K 2.2K 56.27K 1.21K 10.18K 542549 rocket aiohttp tower warp actix $ cargo run --release $ wrk -t20 -c500 -d30s