The city of Axum in Ethiopia was the seat of the powerful Axumite Empire for nearly a thousand years.
If I had to guess, the software is named after the Empire of Axum, which served as an important middle player on the trade routes between Europe and Asia, by analogy to the software being the middle layer between user and backend.
(Today, the Church of Our Lady Mary of Zion in Axum claims to have the Ark of the Covenant, brought to Ethiopia by Menelik, son of Makeda, the Biblical Queen of Sheba. No one is allowed into the church to see it, though, sadly.)
Sebastian Major has a great episode of Our Fake History on the history and different myths around the Ark in Ethiopia! I’d super recommend it.
He also mentions another podcast, the History of Africa Podcast. There’s an entire season on the history of Ethopia up through the end of the Axumite empire, and it’s a fascinating listen, I’d also highly recommend.
So what’s the killer feature here / why would I want to reach for this rather than hyper? (Which also uses tokio)
hyper is really just an http implementation. This is a framework to combine routing, middlewares (using tower) and content (with the provided Html and Json builders). That being said, the amount of tools, frameworks and available layers in web implementation has gotten me seriously confused and frustrated.
I acknowledge that rust/web is a young field and we’ll hopefully see stabilization, convergence and mergers eventually.. but there’s a long way to go and I just can’t wait. :)
It’s the boilerplate you’d have to write to make a server on top of hyper.
Source: I didn’t want to use a framework on top of hyper and have reinvented one three times already.
Or, what’s the killer feature that justifies adding yet another Rust web framework? IMO it would be better to pick an existing framework and help it cross the threshold into maturity and popularity, so Rust can have its Rails or Django – a full-featured web framework that’s the clear winner for its language.
“It’s Rails” is, I think most would agree, is Rocket. Already very popular and the most “frameworky”.
I would disagree. Rocket is good, and I like both Rocket and Rust. But it’s no Rails or Django. It’s more like a FastAPI right now.
There’s lots of stuff that’s there in django or rails that just isn’t present in Rocket, but IMO the largest gap is the ORM. Diesel is not (and doesn’t, AFAICT, try too hard to be) very close to feature parity with Django’s ORM or ActiveRecord.
My understanding was that this framework is more of a lightweight approach to making the ecosystem of Tower more ergonomic to use in web servers (with routing, request extraction traits, etc)
In that way, the underlying fundamentals of Axum have already been around for awhile. This is just an easier way to start working with all the pieces in a similar way as Rocket or warp
I’d welcome something “official” from tokio that’s not tacked on. If you want to compare it, you’d have to do that with actix-web (which abstracts over tokio but doesn’t use hyper internally). Or warp. And if you’d tell me I could replace my actix-web stack with something even better in terms of features or ease of use, I’d happily switch.
What I want to know is, where is the Rust equivalent of the Caddy web server (written in Go)? Axum isn’t it, right? If no such thing exists, why not? Did Caddy do it well enough that it killed the category, and it’s not worth writing something similar in Rust?
I just want a simple binary that will host my websites for me and automatically sort out TLS certs, that “just works”.
Caddy 2 well and truly killed the category for me. I even use it to reverse proxy the little things I’ve written in rust with rocket.
I can literally think of almost nothing that I’d add to Caddy. Maybe WSGI/ASGI? But I haven’t missed that just running gunicorn or uvicorn behind Caddy.
Do you have example configs for your rocket apps? Curious to see how it works up close. Thanks for an awesome comment.
I wrote up how I host things in my basement behind a reverse proxy on a DO droplet, connected over wireguard.
For rocket things, I skip the docker stuff and run rocket in my basement on an Ubuntu VM. The “Connect to VPN/Reverse Proxy” section on is the same. And the caddy configuration file is easy to write but (at least when I wrote all that down) was a little hard to google/ddg.
output file /var/log/caddy/stock-toolkit.tuxpup.com.caddy_access.log
In that example, stock-toolkit.tuxpup.com was the public hostname for the app I was demonstrating. 10.20.30.3 was a FastAPI or Rocket server on a VM in my basement.
That plus making my DNS point at that system running caddy is enough for caddy to set up a valid cert using LetsEncrypt, listen on 443, and proxy any connections coming in for that hostname to the backend. I have it logging each service to its own file because I use that to host several different things.
This is really terrific! Thanks for the detail.
I think all the necessary pieces exist as Cargo crates, but nobody has glued them together in a nice package yet. Paradoxically this may be the reason: it’s easy enough to DIY 80% of Caddy features yourself.
Sounds like nginx with some additions, alternatively haproxy - dunno why I’d even want a rust version of that, you don’t RIIR something like that if you don’t have to. Think about how many issues nginx or apache2 will have to handle if they introduce rust and some people start being angry about unsupported platforms. And why would you do that if you don’t have to. There are nicer things to write in rust than to RIIR enterprise grade “middleware” and maintain that..