| I have been using Actix Web as an excuse to learn Rust recently. I like the fact Actix Web is lightweight and fast. You can deploy it on cheap $5 VPS's and get single-digit millisecond response times and memory usage. For API type work, it takes little to get going. The one thing I've taken away is it's still very early days for web frameworks in Rust and Rust in general, so you need to be committed to putting in extra work building libraries/integrations yourself. I.E. non of the cloud platforms have officially supported SDK's. AWS have a beta SDK they are working on with big bold letters in the readme saying "Do not use this SDK for production workloads" , Azure has an unofficial SDK it looks like staff are work on in their spare time. Google doesn't look to have anything. Things like live reloading for templates isn't there. I found myself setting up a Webpack build to iterate templates and the frontend quickly with live reloading. I take the Webpack HTML template I produced + CSS assets and move/link to them into my Actix project. I really like the MAUD template engine for compile-time HTML so I find myself rewriting HTML I produce in Webpack to MAUD and just linking to the css / js asset bundle paths from the Webpack build. If I used something like Mustache templates in Webpack that admittedly would make things easier as I can reuse them as is. The Actix middleware layer isn't well documented, so I looked at existing middleware to figure out how to use it. There's some useful middleware for CORS + logging, but the user auth stuff didn't work for what I needed, so I found myself rewriting my own auth middleware. The latest stable version of Actix Web is 3.3.2, which uses the old version of the Tokio framework. This will cause issues if using some libraries that rely on a new version of Tokio i.e. the beta AWS SDK's. This means you need to update to Actix Web 4 beta, which then breaks some Actix integrations which do not support Actix Web 4. All the issues stem from the Rust ecosystem being young. You need to invest extra effort for functionality that exists and is quite mature in other languages/tools. In my current personal project, I could have written it 10x faster using a different stack just because in Rust/Actix I've had to build a lot of basic functionality other web frameworks provide already. It's a pet project, and I choose Rust/Actix for learning purposes, so that's ok. If I had something I really needed to deliver and it wasn't just a REST API I'd probably not use Rust/Actix right now unless I was on a team/company who where willing to spend the extra time for the performance / hosting cost savings. |