At our company we've been using Rust for one of our backend service for a year and I love it. The general experience of working with Rust as a language for the backend has been amazing. Would never go with anything else at this point for a service that only needs to interact with the world using a HTTP API.

For our stack we went with tide and sqlx.

Looked at actix, rocket, warp as tide alternatives. actix and rocket looked good, but felt like they required too much boilerplate for everything and I've never been too fond of big frameworks. The choice between tide and warp was much closer, but in the end tide just felt a bit more natural for me.

On the database side I went with sqlx since I felt like the extra ORM features diesel provided weren't worth the extra complexity it added. Writing manual SQL queries and keeping models up to date with it isn't that hard. And sqlx have good migration support for updating the database schemas, which I feel is the most important thing together with compile time query validation.

Parsing input from external services, and then conversion to the data models required for the business logic and then converting it again to JSON for output is easy and secure with serde. Never felt as confident in the data parsing and usage in any other language.

Only issue I've had is figuring out how to do error handling. Tried a couple of different options over the last year, and currently using anyhow and an ErrorKind enum attached to application errors to keep track of the various errors. That works nicely for now. The errors keep track of their kind and their source, so I can give good error responses to the queries with suitable HTTP codes and error messages.

Compile times could be better, but debug builds are fast enough to not be too much of an issue.

All-in-all I've found Rust to be a great language for writing a backend service.

At Oxide we are doing backend development in Rust, with our own framework: https://github.com/oxidecomputer/dropshot/#dropshot

I read comments from people two years ago that said "Rust isn't good for backend development, It wasn't built for that".

That really surprises me. Do you have a link?

Even two years ago there were success stories about porting a service to rust and getting lower latencies.

[deleted]

I've been writing APIs (RESTful JSON and gRPC) with Rust for the past two years and generally liked the experience. It was a small, basically-one-man-show for a bit which gave me lots of flexibility, so we could absorb things like the async intro and a couple of breaking changes between actix-web versions without too much trouble. I also shy away from a Rails/Django-y approach these days, as most of what I'm working on is well outside the standard CRUD + web templates setup that those frameworks excel at.

Outside of the language itself, the frameworks I've used have been actix, rocket, and tonic. I wouldn't choose actix again, I don't think... when I used it, it was in a bit of a strange place between "batteries included" and "implement this complex trait yourself, good luck". Hopefully that has improved, but I'd probably reach for something like warp or tide or even hyper + a router for a smaller web framework that would tend towards a lower level (and hopefully do so with a bit more simplicity along the way).

rocket would be easiest by far for someone coming from e.g. Django, and I really like the direction and management of the project. Just be aware that it's pretty macro-heavy, which means that you have to do a bit more learning beyond Rust-the-language into Rocket-the-collection-of-macros. But those macros are definitely pretty! And rocket has a great middleware and auth layer (in a way that actix-web didn't when I last worked with it). But you're giving up some sharpness in your tool along the way between the macros and the general bent towards full-stack-ness (in the spirit of e.g. Rails instead of e.g. Sinatra).

By far my favorite backend web API framework has been tonic, although that's for gRPC specifically. If you're not wed to REST, I'd encourage you to give that a try.

I've deployed several production backend services with Rust. I've used tokio + actix, tokio + warp, but my favorite so far has been async_std + tide. Async_std + tide isn't nearly as performant as the Tokio and actix (these two libraries are designed for SPEED). I would prototype with tide and if your service starts taking a real beating, then you can easily migrate to actix for a 30% perf bump.

Async_std + tide is very simple to get up and running - the minimum app is 3-4 lines and it has all the things you'd want from a web framework. The docs aren't as great, but the interfaces are really straightforward compared to Actix/Warp. It's really simple to use (dummy proof) and gives just the right amount of control without being too difficult to play with.

I've really enjoyed the experience of sqlx + typed-query for DB stuff. serde_json is super handy and the built-in error handling is way better than Go/Ts. My frontends are still react, but I'm working on changing that ;).

Overall, 10/10 experience for the basic CRUD app.

We built our backend in Rust and it works great!

I think you'll be fine. async is still a bit tricky, but totally do-able.

If you can afford the performance penalty of GC langage, and you are OK to have less "correctness" than a program written in Rust, I suggest JavaScript (or TypeScript if you want the "type-safe" version), with Node.js as runtime.

It's a common high-level langage, with lot of developers, a solid community, lot of packages, it will make your product cheaper and faster to dev at start.

Rust is a low level langage, it require a more fundamental understanding of how computer work.

I started Rust without a solid mental model of CPU and RAM, without any C/C++ knowledge, from scratch, and it take me years to get the "Eureka !".

JavaScript have garbage collection, developer don't need to understand and deal with stack/heap/ownership/borrowing/lifetime, because everything is managed by the JavaScript runtime (V8). You have the option to opt-in "type safe" with TypeScript, and add a linter (EsLint) on top of that (it's like Clippy for Rust).

In JavaScript, I can run 2 Promise (aka Future) in parallel that share state in less than 10 seconds of keyboard typing. 0 dependency, everything is in standard library, because the JavaScript runtime do the scheduling itself. But there's a caveat ; no correctness, I can introduce many subtle bugs if I'm a bad developer (race condition, memory leak, unexpected state, runtime errors, ...).

Meanwhile, in Rust, if I want to do a parallel computation that share state, I can create 2 threads with the standard library, but then I need to wrap all my type with Mutex<T> because bad news ... it's not safe to share state in thread ... or I can move my data, but I can't because it's shared in more than 1 thread and thus multiple thread mean multiple owner at same time ... so let's go for Mutex and don't move data, just send reference. But then I need to be sure my reference has 'static lifetime, otherwise my data will be destroyed while thread has a reference to use theses data ... Rust don't allow that, compiler error ... but I can use library-proprietary feature like scoped thread ... or maybe go a step back, I can simply wrap everything in Arc<Mutex<T>> to do reference couting and share state in multiple thread, or I can use library-proprietary async runtime that will do scheduling itself and don't go with threads but with async function. There's to many road, if you don't understand the pro and cons of everything, you are stuck in a giant pile of mess. But if you understand why Rust won't let you do [insert-something], it will make you a better developer in all langages.

Productive Rust dev, aren't legion, especially when real-world application often tackle the trickiest problem of Rust : async I/O, parallelism, self-referential and recursive data-structure, tree/graph, everything like that are NOT easy in Rust and require a good understanding of the machinery and for some problems, you need some sort of "sorcery solution" in Rust (like the Pin API for Future). Meanwhile, Productive JavaScript Dev are legion ... you don't need to understand any concept in JavaScript anymore, just learn OOP or Functional Programming 101 to map/filter/reduce and do natural transform on array, and let's go.

So maybe, for the firsts prototypes, start with a simple langage like JavaScript/Python or whatever, and then go for a more low level / optimized approach if the performance and corectness are important.

There's the Express framework in JavaScript to create web-service (alternative is Koa).

Also, if you want to write a Rest API, don't forget the OpenAPI protocol, a really nice feature to have.

I think it is definitely possible... and the language is very well suited for web and backend development. Things like authentication and similar can be compiler proven if done right. Injections can be avoided using the compiler and so on. There are no garbage collection latencies. So to build a backend to last I'd say it is my favorite language.

It is not fast to do some prototyping though as there is no native "admin-interface". Django or similar are much faster to get something working.

If you want to build it in rust I highly recommend: https://www.lpalmieri.com/posts/2020-05-24-zero-to-production-0-foreword/ and the following chapters... He describes the whole development process including setup, testing, observability, error handling and much more. He does explain everything in such a way that I guess you should read the articles to judge if it is suited for your purpose or not. - Also don't hesitate to buy his book which is basically what he wrote in the blogposts.

I do quite a bit of backend rust for my side projects, and it's a mixed bag. I use rocket personally, I'm not in love with it but it gets the job done. Async is a bit weird currently. I'm on 0.5 rocket to take advantage of async because I want to make async requests from some of my endpoints, but that means docs are lacking and some projects that integrate with rocket, like Juniper, need some manual tweaking, until 0.5 lands and other projects catch up.

You'll have to do a bit more manual work for pretty much everything, compared to like django or something. For example for auth I use jsonwebtoken, which is great but its not integrated with Rocket to the degree auth solutions are integrated into django, express.js, etc, so it requires a bit of glue work.

Database stuff is alright. Diesel is definitely the best solution I've found, but its hard to learn, gives confusing error messages sometimes, and the migration and modeling stuff isn't as integrated as it is with Django/Rails, where you can just change your models and the migrations get generated. Definitely slows down the pace a bit when your models are changing often.

Some libraries just aren't as mature as libraries in other ecosystems. I use Stripe and I have to run with a mix of vanilla reqwest queries, and using the stripe-rs library, because it doesn't cover all the use cases I have.

Compilation times are kind of annoying, I've only got a few thousand lines but compilation time was at like 15 seconds until I did some linker changes, which definitely slowed down the pace of development a bit. After spending some time on it, its down to ~5 seconds, which is very acceptable for me, but it did frustrate me for a while.

All that being said, I'd still choose Rust over any other language, I'm not trying to discourage anyone from using it. But if you're coming from like Django or Rails, you will have to operate at a different level than you're used to, and things that require a one-line import in those frameworks can take an hour or two.

I've tried it about a year ago and didn't like it, and I'm currently prototyping a service again.
So, it works, but it's not as focused on developer happiness and productivity as I'd like. You can do everything, but important helpers that I love in other languages and frameworks are missing. The IDE experience has increased a lot, so I'm loving that now. SQLx is pretty good, but not a full ORM, if that's what you like. There's Diesel, but that's not async.
Then, there's inconveniences. actix-web has been on 4.0-beta with Tokio 1.0 for a while, but libraries like actix-session are still based on actix-web 3, so you don't really get even the most basic session capabilities out of the box. I love Tide, personally, but its community is much smaller.

So, it really depends. Do you need to be quick at prototyping something with all the help of a big framework? That doesn't exist in Rust, yet. Things like Rails, or Django, or even Phoenix are missing. If you want to do more yourself, and want a lower level approach, the Rust experience is pretty good already.

Rust has a larger threshold than other languages, which can be a general issue. I think it's fine!

You will be moving into a new ecosystem you never used, and that will always be painful at times.

I use actix-web and sqlx. I'm really happy with both, but actix-web is in beta and sqlx uses a lot of feature flags that you need to set, so there can be some stumbles on the road when setting up the configuration.

To get started, you can do a minimal amount of error handling with unwrap, then expect, then map_err, then using traits to convert errors.

Same with logging, you can start with print macros, then move to proper logging of the responses, then move to structured logging.

​

I'd recommend buying the book "From zero to production in rust" https://www.zero2prod.com/index.html.

If you are setting up CI/CD, here's an example of how I do it based on feedback here on Reddit: https://github.com/marcusradell/monadium/blob/main/.github/workflows/cd.yml.

​

I think Rust will be my main lang for web backends, but I just want to be transparent that there is a switch-over cost and a generally slower development speed. The slowdown I see comes from the fact that I actually need to handle every damn error, while in in node.js I would have pushed a buggy feature to production faster and go "whoopsie!" when it crashes.

I tried to write our backend at my current co in Rust last year and it was very difficult. I started writing some backend stuff in the last month again and it's vastly improved. You will miss out on specific comforts from other languages, but the pace of improvement is very fast.

arewewebyet

I have recently be transitioning our Node web server to Rust. I cannot recommend it enough.

The way Rust forces you to structure your code is truly a blessing. We personally use GraphQL over REST (if appropriate I'd certainly recommend it for the ease of use and type safety). Compared to JS GraphQL integrations, the use traits and macros feel much less hacky that the various workarounds sometimes required in Node.

Error handling can also be done very well, making it very clear cut what errors are internal and what are shown.

This is a neat writeup https://www.reddit.com/r/rust/comments/cdg5b4/rust_in_the_on_of_the_biggest_music_festival/

I am writing a small backend with Rust now. I am using Routerify and sqlx (postgres) with tokio and postgresql. I am also using reqwest for interacting with Slack APIs. Writing testable code seems to be a bit difficult. For example, if you'd like to have a test harness that automatically rolls back transactions after the tests are done, we need to inject an sqlx executor to my CQRS layer. While it is definitely possible, there aren't many sample code bases or documentation that makes it apparent. I find the project enjoyable. But then again, I found learning rust enjoyable.

Why rust and no Python? What are the technical reasons you need a compiled language?

Note: if you answer “speed” and you did not measured the effective speed up, you gave the wrong answer

We're currently in the process of moving parts of our PHP backend to Rust, and I personally think that's actually one of the strongest sides of Rust. Before that I used it for UI development, where it's a real pain due to the lack of adequate middleware.

We're even doing verification steps like SQL schema validation at compile time, which means that if it compiles there's a very good chance that it's going to work.

[deleted]

I think it's great if you need the performance but others like Go are faster to develop with while still being very performant. I'd probably choose Go for most services even though I love Rust

If you're working on a new business idea, I recommend you use the language you are most proficient in and the best available open source libraries and frameworks available. Adopting Rust will cost you time and effort that can be better spent on business development.

I don't think so. I've had some small backend development experiences before, and found things to be in a pretty good shape. Rocket is really simple but fun to use. tide also seems good, though i haven't actually used it

I'm prototyping a new backend in Rust right now. It was surprisingly simple to get a basic API receiver set up with actix web, using serde with structs to represent the various payloads on their endpoints. I like that I can keep things logically grouped in modules, like a main.rs for bootstrapping the whole thing, api.rs for the API routing/mapping and payload structs, etc. Plus the built-in unit testing of each module is helping me prove out the components too.

It's going to replace a Java backend, and I'm already liking the difference in startup time (naturally). actix made it dead easy to wrap in logging too. Questions to be resolved: debugging, runtime management (we heavily use JMX in our legacy products). But we'll get there. There is certainly enough promise here that we are proceeding. Next up is figuring out if I want to use sqlite directly, or go through something like sqlx.

Try fastApi

We are using Rust for Backend with Graphql on ApiGateway. The bottom line it's great. We rarely ever face codebase related bugs and our fixes are mainly due to external environment.

I love how rust eliminates side effects and the rust compiler errors are the best and most comprehensive I've seen.

I just finished writing a server for my final project at uni. We used Rocket, Rusqlite and React. I didn't intend to use React, it was chosen by the frontend team, but we managed to integrate it quite well. We used JSON to communicate between the frontend and backend, which was super easy because of Serde.

If I had to do it again, I would probably do the same thing. However I think I would just use the latest unstable version of Rocket, and switch to SQLx or Diesel.

All in all I think Rust just makes sense for building servers, especially as crates mature. I think Rocket is really awesome and I'm looking forward to it landing on stable Rust.

Go for it dude Rust back on the back end is about as fast as you can get, it will require boilerplate tho