Rust for a production SaaS web application?

Hi there! I am not a professional rust developer, but I can write a CLI tool in Rust when required without much effort. Last year, after my initial learning of Rust, I fell in love with Rust, and now I want to use it for all my work. So, these days, I am learning Rust properly.

I want to build a small SaaS web application as a secondary income method. I initially thought to use TS, but now I am thinking of using Rust for both the backend and the frontend. I am mainly planning to use axum, dioxus, and diesel. I am planning to use GCP for my Kubernetes. For the app, I would use Swift (IOS only).

So, here is the problem: is using Rust for an entire production web application (as far as I can go) a bad idea as of 2024?

For your backend and emphatic no, pretty good idea to write it in Rust. In the context of RESTful API services, the type system has done most of the work for me so far and I can't recall a single bug in my backend stemming from my source code[1]. Also no problem to host a Rust web server in k8s.

Unfortunately I haven't had much of an opportunity to build frontend stuff in Rust yet. Played around with Tauri and I like answering yew-related questions here on URLO, but that's about it. Dioxus looks quite promising though and according to documentation supports building for mobile platforms, including iOS (in case you'd prefer not to develop your iOS app natively with SwiftUI[2]).


  1. I recall one or two logic bugs related to 3rd party integrations, but that's not the fault of me using Rust and they were fixed rather rapidly, something that'd have been more difficult in languages that are less strictly typed and don't make control flow as obvious as Rust forces you to do. ↩︎

  2. Might be a bit harder to convince the App Store to let you upload your app though, don't know how wry and tao stack up against the rather rigid requirements Apple puts on your apps. ↩︎

1 Like

Before you commit to this stack, try out these libraries to make sure you can deal with async Rust, and some type system acrobatics that these libraries do.

Rust works fine on the back-end, but for CRUD applications that mainly move data from DB to JSON or HTML, most other languages will be fine too.


If your front-end is HTML, or a native mobile UI, then Rust will not be useful there.

In browsers only JavaScript is allowed to interact with the browser, which makes WASM, and therefore Rust, just an overcomplicated way of calling JavaScript.

Native UI toolkits tend to require specific programming languages like Java or Swift/ObjC. This also makes Rust just an awkward way of calling functions in a foreign language.

If your front-end doesn't have a lot of computation or logic unrelated to the UI, it may be better to implement front-ends in their preferred languages.

3 Likes

For four years now our little company has been doing everything server side in Rust. We use Rocket for the web server although there are many others that sound equally suitable. We have the usual websockets, database connections, along with a bunch of hard core processing services all tied together with the NATS pub/sub messaging system. Everything has gone together relatively painlessly, given that it took learning Rust on the fly which is still an ongoing process. Most importantly it has all proved to be very reliable, no calls in the night about mysterious failures, and performs very well. As such I think Rust is eminently suitable for what you describe.

However, so far we have not done anything client side in Rust, JavaScript still rules there. Although it is on my todo list to find time to investigate how far/well Rust has progressed into that realm.

1 Like