Replacing FastAPI with Rust: Part 3 - Trying Actix

[dbanty]

A discussions thread for "Replacing FastAPI with Rust: Part 3 - Trying Actix".

[mosheduminer]

I recently had the problem of passing a struct that did not have the Send trait, and it seems all spawned tasks in tokio need that trait, since tokio is (by default) multithreaded, and may execute the spawned task on another thread. Anyway, I figured out that the solution was to use channels. This tutorial was pretty helpful for me to figure out what was going on.

Looking forward to the next post!

[swilcox3]

I'm pretty interested in what you're doing myself, although it looks like what you're looking for is a bit different than me. If I understand correctly, all you want is the request routing part of a webserver. All the scheduling, thread pool, long-running service stuff is handled by the Lambda runtime. So really you don't want something like actix at all, because what actix is all about is that thread pool stuff. That's why it's so fast. apart from the natural Rust benefits of static typing and zero-cost abstractions. That's why I use actix, because I want a rock-solid service that's going to be blazing fast and run forever, in a statically compiled executable with no dependencies I can plonk wherever I want.
It honestly might be easier to write the request routing yourself rather than try to shoehorn actix into Lambda. I don't know about warp, I haven't used that one, but maybe you should look into the source code and see if the request routing portion is extractable.
One of the downsides/upsides of Rust is that you only pay for what you use. The std library is pretty small. Unfortunately that means that there's no standard way of doing HTTP, and there's no standard way of doing async runtimes. Efforts are being made in that direction, but Rust is still pretty young. Whenever I get frustrated with the kind of compiler errors you inevitably run into when you get off the async happy path, I think about the absolute nightmare debugging this stuff in C++ is. I've spent weeks trying to trace down memory leaks, corruptions, and seemingly random crashes. There is no free lunch. When you want this kind of performance, you either pay for it with Rust compiler errors or C/C++ instability.
Good luck, and thanks for publishing your journey!

[dbanty]

The main reason I'm trying to get existing web frameworks to work (rather than writing or finding a routing-only solution) is because I want to find something that already has OpenAPI tooling. Actix was my first attempt at this (which clearly didn't go well). It seems like warp (and therefore rweb, which will star in my next post) may be easier to use in this way. I'm fairly certain I've seen Rocket used in this way so I might poke around in that direction eventually. I was also pointed in the direction of dropshot which seems to be pretty lightweight and may be easy to adapt for this purpose.

In a perfect world, there will be a project which separated their app definition logic from the web server bits so I can just not include the web server bits (via feature flags maybe). I haven't found such a project in Rust though I'm still hopeful that something like that might exist.

[gavrie]

@dbanty I'm curious if you have looked at https://docs.rs/dropshot/. It's relatively new, but looks very promising.

[dbanty]

I have! Someone else actually recommended it to me a few days ago. I'm including a paragraph about it in the next post (hopefully coming out later today). The TL;DR is it seems very interesting but is too tightly coupled to the http server to be useful in serverless without some hi-jinx.

[gavrie]

Cool, thanks!