Rust, Axum and the base of complex software: tracing, logging and error handling

I just started a new Blog and personal homepage and was thinking about publishing a series of blog posts regarding a topic that I am curently focused on obsessed with: learning Rust.

The question why should be a no-brainer. You can write any software with it you please – servers, web clients, desktop apps, games, firmware, … I mean, literally anything expessable in code.

Since I rooted in web development, I tend to pick a new web framework whenever I intend to learn a new language that’s remotely suitable for web development. Not to actually build websites with the language, but because it’s easier to learn something based on another thing you already know well. The web development mindset is a powerful catalyst for learning new languages and frameworks, because it always follows the same principles.

I know a few client side web frameworks like React, Svelte and SolidJS, but I still find client-side Rust web frameworks like Leptos, Yew and Sycamore interesting, because I think the idea of building a server- and client-side Rust web/desktop app experience is fascinating on its own, but I kept focusing on server-side frameworks first, because the server offers more possibilities with a systems programming language like Rust.

The one I am building an API in and which I am still experimenting with so far ist Axum¹, which was recently bumped to v0.7.

Of course there are Rocket, ActixWeb and others, so why did I chose the Axum server web framework:

• it’s very convenient and pretty easy to learn
• offers very powerful and fine-grained routing
• does not restrict you or enforce opinionated conventions
• leverages proven crates like Tokio, Hyper and Tower-HTTP
• I liked the simplicity of extractors and impl IntoResponse

One thing that I struggled with – probaly more than I should have – when I started learning Rust was how to handle errors properly. Results and Options are very useful concepts and the foundation of error handling in Rust. However, APIs and UIs have their own needs when it comes to handling errors. Of course you could always wrap your errors in a basic error or return just HTTP error codes, but that becomes unwieldy and dangerous quickly.

Ideally, I’d like to have a dynamic error type, that gives me all the information I need on the server level, then filter out sensitive errors and give the user only the information they need to know why something might have gone wrong. Of course a error that could happen when deadling with a database needs to be logged and users will have to be notified, but they don’t need to see SQL, sensitive information, password, tokens, etc., so it would be best to return errors with certain error codes and decide on a middleware level which ones to turn into responses with as least sensible information contained as possible.

This is what I am going to be exploring in future posts here, so if you’re interested, stay tuned.