Getting Started with Axum – Rust's Most Popular Web Framework(shuttle.rs)
shuttle.rs
Getting Started with Axum – Rust's Most Popular Web Framework
https://www.shuttle.rs/blog/2023/12/06/using-axum-rust
25 コメント
Agreed, Rust is super easy for deployment.
I wrote a quick blog post in the past describing what the parent comment is talking about.
https://logankeenan.com/posts/deploy-your-rust-project-to-an...
I wrote a quick blog post in the past describing what the parent comment is talking about.
https://logankeenan.com/posts/deploy-your-rust-project-to-an...
As a seasoned python developer deployment of a pure Rust program is much simpler than Python. The only issue that I ever had was figuring out how to cross compile for a raspberry pi, but even that took me less time than the typical python dependency problem that may happen when you e.g. devlope on Ubuntu and deploy on Debian.
When Rust deployment gets hairy, it is typically the fault of non-Rust-dependencies.
When Rust deployment gets hairy, it is typically the fault of non-Rust-dependencies.
Similarly for our Go binaries, I build them as full static binaries outside of Docker then just COPY them in. Works pretty seamlessly.
Is it safe to expose to the internet[0]? I’m still looking for a Rust web framework that supports eg timeouts for idle connections so that it doesn’t crash and burn when it runs out of sockets after a few hours of serving production traffic (let alone being able to survive an intentional slowloris attack) :(
[0] I’m ideally hoping for a framework which ticks the same boxes that Go’s `net/http` was ticking in 2016: https://blog.cloudflare.com/exposing-go-on-the-internet/
[0] I’m ideally hoping for a framework which ticks the same boxes that Go’s `net/http` was ticking in 2016: https://blog.cloudflare.com/exposing-go-on-the-internet/
Throw Nginx in front of it like anything else and you’re probably fine.
Or at least I can say - I’ve not experienced issues doing this in an app serving 100m in a day. YMMV etc.
Or at least I can say - I’ve not experienced issues doing this in an app serving 100m in a day. YMMV etc.
I have tried (specifically nginx, haproxy, varnish, squid, traefik, and a few others) - alas every setup had problems, but “expose my app to the internet, and have a cronjob to kill and restart it every 3 hours” has had the fewest problems ;(
Tooting the Rust horn in predictable ways:
Why would you want to restart a service frequently?
Rust's immutable-by-default semantics makes it harder (but not impossible) to end up where your long-running process'es state is incorrect.
You can still mark everything as `&mut` and litter the code with ref-counts. I've seen a lot of this "removing the safety rails because it's more convenient" among C/C++ developers who were forced into using Rust.
I think a bigger attack vector for anything dynamic, including a type-safe, memory-safe Axum back-end service, is denial-of-service because requests take too long to process. Application development is always vulnerable for being feature-driven: features sure do like resources! A service doesn't need bugs to get killed efficiently. It just needs to get slow over time.
Why would you want to restart a service frequently?
- Flush incorrect state
- Reset memory leaks
- ...others reasons?
Rust's immutable-by-default semantics makes it harder (but not impossible) to end up where your long-running process'es state is incorrect.
You can still mark everything as `&mut` and litter the code with ref-counts. I've seen a lot of this "removing the safety rails because it's more convenient" among C/C++ developers who were forced into using Rust.
I think a bigger attack vector for anything dynamic, including a type-safe, memory-safe Axum back-end service, is denial-of-service because requests take too long to process. Application development is always vulnerable for being feature-driven: features sure do like resources! A service doesn't need bugs to get killed efficiently. It just needs to get slow over time.
> Why would you want to restart a service frequently?
As mentioned in the original comment - I haven’t found a web framework which supports timeouts for idle TCP connections (they all seem to be built on top of Hyper, which doesn’t support them). And so even tweaking kernel parameters to bump up the connection limit to a few hundred thousand (any higher than that and I start hitting a different set of problems), and only having a few thousand actually active connections, my app still runs out of sockets and hangs after a few hours.
As mentioned in the original comment - I haven’t found a web framework which supports timeouts for idle TCP connections (they all seem to be built on top of Hyper, which doesn’t support them). And so even tweaking kernel parameters to bump up the connection limit to a few hundred thousand (any higher than that and I start hitting a different set of problems), and only having a few thousand actually active connections, my app still runs out of sockets and hangs after a few hours.
Close to memory leaks, but not exactly: memory fragmentation. Unlike runtimes with managed memory such as JVM, Rust apps cannot take a pause and defragment the memory heap, which depending on frequency and sizes of allocations sooner or later will lead to your app taking up a huge chunk of memory and not using it efficiently.
Wouldn’t this be a criticism of any long-running program which uses dynamic allocation, not only Rust? It’s the operating system’s job to manage fragmentation in the allocator, right? And it’s straightforward to switch to jemalloc, which often improves on the system allocator.
> And it’s straightforward to switch to jemalloc, which often improves on the system allocator.
It is true that jemalloc is much better than the standard malloc, but it still suffers from memory fragmentation, although typically a program can run for much longer with it.
> It’s the operating system’s job to manage fragmentation in the allocator, right?
No, not really. The operating system does nothing with the memory space of the process, other than providing syscalls for giving the process more pages.
> Wouldn’t this be a criticism of any long-running program which uses dynamic allocation, not only Rust?
What some thicker runtimes such as JVM do is that 1) they track all pointers present in the data used by the program and do not allow programs to cast them to raw integers (or back); 2) they can defragment the heap by moving the memory chunks around to fill in the gaps and at the same time they rewrite all pointers that point to moved chunks so that they still point to the same data.
It is true that jemalloc is much better than the standard malloc, but it still suffers from memory fragmentation, although typically a program can run for much longer with it.
> It’s the operating system’s job to manage fragmentation in the allocator, right?
No, not really. The operating system does nothing with the memory space of the process, other than providing syscalls for giving the process more pages.
> Wouldn’t this be a criticism of any long-running program which uses dynamic allocation, not only Rust?
What some thicker runtimes such as JVM do is that 1) they track all pointers present in the data used by the program and do not allow programs to cast them to raw integers (or back); 2) they can defragment the heap by moving the memory chunks around to fill in the gaps and at the same time they rewrite all pointers that point to moved chunks so that they still point to the same data.
I know what JVM does, I was talking about other “native-allocator” stacks like C and C++, which are used in many very popular long-running services.
This isn't trolling, it's my genuine ignorance- I thought Actix was the goto web framework for Rust? I don't do a whole lot of Rust and when I do it isn't http router type work so I'm out of the loop here.
Looking at stats on crates.io for a few frameworks
- axum: 100k installs/day
- warp: 25k installs/day
- actix: 15k installs/day
- rocket: 7k installs/day
- tide: 1k installs/day
(For comparison, hyper - the HTTP library that most web frameworks use under the hood - is at 200k/day, many of which are using it for client rather than server functions. So unless there is another not-hyper-based framework out there, then I’d be moderately confident guessing that axum has >50% of the server market)
- axum: 100k installs/day
- warp: 25k installs/day
- actix: 15k installs/day
- rocket: 7k installs/day
- tide: 1k installs/day
(For comparison, hyper - the HTTP library that most web frameworks use under the hood - is at 200k/day, many of which are using it for client rather than server functions. So unless there is another not-hyper-based framework out there, then I’d be moderately confident guessing that axum has >50% of the server market)
Actix used to be the fastest (maybe still is? all the frameworks are so fast it doesn't even matter that much anymore) and most popular framework.
Then a bit of drama happened about the hard life of maintaining an OSS project with users criticising you (the usual).
Rocket seemed to gain popularity for a bit but then there was some drama with the maintainer disappearing / not releasing 0.5 for a long time.
Meanwhile, quietly, the guys who did tokio (the most popular async runtime) released axum, which is compatible with tower middlewares. So they had tons of features pretty early.
I switched from actix to axum around 0.4 and updates have been very sensible and kept improving the DX.
Nowadays Axum is at the top for downloads number: https://www.arewewebyet.org/topics/frameworks/
Rocket seemed to gain popularity for a bit but then there was some drama with the maintainer disappearing / not releasing 0.5 for a long time.
Meanwhile, quietly, the guys who did tokio (the most popular async runtime) released axum, which is compatible with tower middlewares. So they had tons of features pretty early.
I switched from actix to axum around 0.4 and updates have been very sensible and kept improving the DX.
Nowadays Axum is at the top for downloads number: https://www.arewewebyet.org/topics/frameworks/
I think you’re a little understating what happened to the developer.
There was like 3 uses of “unsafe” and the developer was being systematically attacked and harassed by the rust community for months.
It wasn’t “a bit”, nor would I call it “the usual”. The rust subreddit and discord literally organized brigading and harassment campaigns against the dude.
There was like 3 uses of “unsafe” and the developer was being systematically attacked and harassed by the rust community for months.
It wasn’t “a bit”, nor would I call it “the usual”. The rust subreddit and discord literally organized brigading and harassment campaigns against the dude.
One year ago it was still the standard and I think most production workload still are using actix (we are). When you dig into actix you feel the pre-async decisions (acceptor threads, worker threads, futures not send).
But for a lot of usecases this model is faster than Axum work stealing. I am not a super huge fan of hyper (on which Axum is based), I salute the work (it is impressive) but it is very clunky to use, the code is hard to read and usage is super opiniated.
But for a lot of usecases this model is faster than Axum work stealing. I am not a super huge fan of hyper (on which Axum is based), I salute the work (it is impressive) but it is very clunky to use, the code is hard to read and usage is super opiniated.
I think Actix used to be the goto web framework at the time is because it was the most complete, it's still a solid choice. What I think made Axum more popular aside from the features added is that it's part of the tokio-rs projects.
I used to use Actix for a web project, but the Websocket story was severely lacking. Actix is non-work-stealing multi-threaded (to achieve "performance", I presume) and thus it has to use a non-async Actor model for inter-Websocket interactions. This meant that I could not use an async DB pool or an async HTTP requests library within my Websocket code.
Alternatively, Axum is built by the same people that made tokio, is work-stealing multi-threaded, and the Websocket code is async be default. It is just overall a better library.
Alternatively, Axum is built by the same people that made tokio, is work-stealing multi-threaded, and the Websocket code is async be default. It is just overall a better library.
When I looked into it while starting a new project about a year ago, Axum seemed like the framework with the most inertia. I think there was some concern a year or two back about whether Actix would continue to be maintained, but it looks healthy now.
They're probably both fine choices, I chose Axum because the middleware architecture was easier to grok and at the time I felt that staying under the tokio umbrella would be safer long term.
They're probably both fine choices, I chose Axum because the middleware architecture was easier to grok and at the time I felt that staying under the tokio umbrella would be safer long term.
I love Axum as well that I also wrote a blog post teaching how to link it up with PostgreSQL and Tokio.
https://spacedimp.com/blog/using-rust-axum-postgresql-and-to...
https://spacedimp.com/blog/using-rust-axum-postgresql-and-to...
I've been using Tide with great success lately. Also - for my own projects I haven't used docker lately and just dump the binary with it's configs to the debian box with a systemd configured and so far it's been painless, ymmv.
Tide is fantastic and has IMO the best ergonomics (and could be improved to be even better), except it's essentially abandonware at this point. I'd love to see it continue and thrive, but there's many PR's that have been ready to land for a long time gathering dust, and plenty of open issues that are at a standstill because there's simply no momentum or direction.
Not blaming anyone - the maintainers don't owe us anything - it just wouldn't be my crate of choice if I was starting today. If any of the maintainers read this, shoot me a message because I'd love to help out and get the ball rolling again on tide.
Not blaming anyone - the maintainers don't owe us anything - it just wouldn't be my crate of choice if I was starting today. If any of the maintainers read this, shoot me a message because I'd love to help out and get the ball rolling again on tide.
I think there’s the bigger question of “what’s the deal with async-rs?”.
I know of more than a few projects that have looked into just dropping support for it entirely.
I know of more than a few projects that have looked into just dropping support for it entirely.
Actually, in my experience, Rust is one of the best languages for ease of deployment (for much the same reason as Go). Rust/Cargo produces self-contained statically linked binaries. Rust/Cargo also has a real nice cross-compiling story. Often my deployment will be to build the binary and then basically scp the binary and supporting files (such as html/config) to the target. You don't really need Docker.