Rust สำหรับเว็บ: เปรียบเทียบ Actix Web กับ Axum และคำถามสัมภาษณ์ 2026

Rust ได้สร้างตำแหน่งที่มั่นคงในฐานะภาษาโปรแกรมระบบเพียงภาษาเดียวที่รับประกันความปลอดภัยของหน่วยความจำโดยไม่สูญเสียประสิทธิภาพ โมเดล ownership ที่ไม่ต้องการ garbage collector ในขณะรันไทม์สามารถให้ความเร็วเทียบเท่า C++ พร้อมกำจัดข้อผิดพลาด null pointer และ data race ตั้งแต่ขั้นตอนคอมไพล์ ในปี 2026 มีสอง framework ที่ครองระบบนิเวศเว็บของ Rust ได้แก่ Actix Web และ Axum แม้ว่าทั้งสองจะถูกสร้างบนภาษาเดียวกัน แต่มีความแตกต่างอย่างชัดเจนในด้านสถาปัตยกรรมรันไทม์ กลยุทธ์ middleware และการบูรณาการระบบนิเวศ บทความนี้วิเคราะห์ทั้งสอง framework ในเชิงเทคนิคเชิงลึก นำเสนอข้อมูลเบนช์มาร์กล่าสุด และอภิปรายคำถามสัมภาษณ์สำหรับตำแหน่ง Rust backend

แนวทางสถาปัตยกรรม: โมเดล Pinned-Thread และ Work-Stealing

ความแตกต่างพื้นฐานที่สุดระหว่าง Actix Web กับ Axum อยู่ที่โมเดล concurrency Actix Web ใช้สถาปัตยกรรม pinned-thread โดยที่ worker thread แต่ละตัวมี Tokio runtime อิสระของตัวเอง ในการออกแบบนี้ request ที่เริ่มต้นบน thread ใดจะถูกประมวลผลบน thread เดิมตลอดวงจรชีวิตของมัน ผลลัพธ์คือต้นทุนการแบ่งปันข้อมูลระหว่าง thread ถูกลดให้น้อยที่สุดและ cache locality ได้รับการรักษาไว้

Axum ใช้ work-stealing scheduler ของ Tokio โดยตรง task ต่าง ๆ จะถูก thread ที่ว่างรับไปทำแบบไดนามิก แนวทางนี้ช่วยให้การใช้ thread มีประสิทธิภาพในสถานการณ์ที่การกระจายภาระงานไม่สม่ำเสมอ แต่อาจมีต้นทุน scheduler เพิ่มเติมเมื่อมีการสลับ task

ตัวอย่างเซิร์ฟเวอร์ขั้นต่ำสองตัวอย่างต่อไปนี้แสดงให้เห็นความแตกต่างของจุดเริ่มต้นอย่างชัดเจน:

use actix_web::{web, App, HttpServer, HttpResponse};

async fn health() -> HttpResponse {
    HttpResponse::Ok().json(serde_json::json!({ "status": "ok" }))
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/health", web::get().to(health))
    })
    .bind("0.0.0.0:8080")?
    .run()
    .await
}

use axum::{Router, Json, routing::get};
use serde_json::{json, Value};

async fn health() -> Json<Value> {
    Json(json!({ "status": "ok" }))
}

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/health", get(health));

    let listener = tokio::net::TcpListener::bind("0.0.0.0:8080")
        .await
        .unwrap();
    axum::serve(listener, app).await.unwrap();
}

Actix Web จัดการการกำหนดค่ารันไทม์ผ่านมาโคร #[actix_web::main] โดยจำนวน worker, เวลา shutdown และการตั้งค่า TLS จะถูกจัดการในชั้นนี้ Axum ทำงานด้วยการกำหนดค่าเริ่มต้นของ Tokio ผ่านมาโครมาตรฐาน #[tokio::main] การเลือกนี้เป็นรากฐานของการบูรณาการอย่างไร้รอยต่อระหว่าง Axum กับระบบนิเวศ Tokio

ในกลไก routing ก็มีความแตกต่างอย่างชัดเจนเช่นกัน Actix Web รองรับทั้งการกำหนด route ด้วยมาโคร (#[get("/")]) และแบบ programmatic ในขณะที่ Axum ใช้เฉพาะแนวทาง programmatic เท่านั้น การตัดสินใจนี้ให้การควบคุมที่ชัดเจนเหนือการประกอบ router และช่วยให้การสร้าง route tree แบบ programmatic ง่ายขึ้นในโปรเจกต์ขนาดใหญ่

การวัดประสิทธิภาพ: Actix Web 4.13 เทียบกับ Axum 0.8

ผลเบนช์มาร์กแบบสังเคราะห์แสดงความสามารถพื้นฐานของ framework แม้จะไม่สะท้อนประสิทธิภาพของแอปพลิเคชันจริงโดยตรง เมื่อเพิ่มการดำเนินการ I/O, การเข้าถึงฐานข้อมูล และชั้น business logic เข้าไป ความแตกต่างที่มาจาก framework มีแนวโน้มที่จะกลายเป็นสิ่งที่ละเลยได้ อย่างไรก็ตาม ข้อมูลเหล่านี้ยังคงให้ตัวชี้วัดที่มีความหมายเกี่ยวกับประสิทธิภาพของสถาปัตยกรรมพื้นฐาน

ผลลัพธ์ต่อไปนี้ได้จากเซิร์ฟเวอร์ที่ใช้โปรเซสเซอร์ AMD EPYC 7763 (64 คอร์) บน Ubuntu 24.04 โดยใช้เครื่องมือ wrk ที่มี 256 การเชื่อมต่อพร้อมกัน:

| ตัวชี้วัด | Actix Web 4.13 | Axum 0.8.9 | |-----------|---------------|-------------| | JSON serialization (req/s) | ~720,000 | ~640,000 | | Plain text (req/s) | ~980,000 | ~870,000 | | Single DB query (req/s) | ~180,000 | ~170,000 | | Memory usage (hello world) | ~8 MB | ~6 MB | | P99 latency (JSON) | 1.2 ms | 1.4 ms |

Actix Web ให้ข้อได้เปรียบ throughput ประมาณ 10-15 เปอร์เซ็นต์สำหรับการดำเนินการ HTTP ล้วน ๆ ความแตกต่างนี้มาจากข้อได้เปรียบ cache locality ของสถาปัตยกรรม pinned-thread และการปรับแต่งชั้นประมวลผล HTTP ที่เป็นอิสระจากชั้น abstraction ของ Tower อย่างไรก็ตาม ในสถานการณ์ที่เกี่ยวข้องกับการเข้าถึงฐานข้อมูล ข้อได้เปรียบนี้ลดลงเหลือเพียงไม่กี่เปอร์เซ็นต์

ข้อได้เปรียบของ Axum ในเรื่องการใช้หน่วยความจำไม่ควรถูกมองข้าม สถาปัตยกรรมที่กระชับกว่าโดยไม่มีโครงสร้างพื้นฐาน actor ทำให้ memory footprint ของเซิร์ฟเวอร์ขณะว่างอยู่ในระดับต่ำ ในสภาพแวดล้อม Kubernetes หรือ serverless ที่รัน container instance จำนวนมากพร้อมกัน ความแตกต่างนี้สามารถส่งผลกระทบอย่างมีนัยสำคัญต่อต้นทุนทรัพยากรรวม

รูปแบบ Extractor และการประมวลผล Request

ทั้งสอง framework ใช้รูปแบบ Extractor เพื่อดึงข้อมูลแบบ type-safe จาก HTTP request แม้ว่าจะรับใช้วัตถุประสงค์เดียวกันในเชิงแนวคิด แต่มีความแตกต่างในไวยากรณ์และข้อจำกัด

Axum 0.8 ใช้โมเดลเชิงฟังก์ชันที่กำหนด extractor โดยตรงเป็นพารามิเตอร์ของฟังก์ชัน handler:

use axum::{
    extract::{Path, Query, State, Json},
    routing::get,
    Router,
};
use serde::Deserialize;
use std::sync::Arc;

#[derive(Deserialize)]
struct Pagination {
    page: Option<u32>,
    per_page: Option<u32>,
}

struct AppState {
    db_pool: sqlx::PgPool,
}

async fn get_user(
    State(state): State<Arc<AppState>>,
    Path(user_id): Path<i64>,
    Query(pagination): Query<Pagination>,
) -> Json<serde_json::Value> {
    let page = pagination.page.unwrap_or(1);
    Json(serde_json::json!({
        "user_id": user_id,
        "page": page
    }))
}

Actix Web มีกลไกที่คล้ายกันผ่านประเภท wrapper:

use actix_web::{web, HttpResponse};
use serde::Deserialize;

#[derive(Deserialize)]
struct Pagination {
    page: Option<u32>,
    per_page: Option<u32>,
}

struct AppState {
    db_pool: sqlx::PgPool,
}

async fn get_user(
    state: web::Data<AppState>,
    path: web::Path<i64>,
    query: web::Query<Pagination>,
) -> HttpResponse {
    let user_id = path.into_inner();
    let page = query.page.unwrap_or(1);
    HttpResponse::Ok().json(serde_json::json!({
        "user_id": user_id,
        "page": page
    }))
}

มีกฎที่แตกต่างกันที่สำคัญในลำดับ extractor: ใน Axum, extractor ที่ใช้ body ของ request เช่น Json และ Body ต้องวางเป็นพารามิเตอร์สุดท้าย Actix Web ไม่บังคับข้อจำกัดนี้ อย่างไรก็ตาม ทั้งสอง framework ตรวจจับความไม่ตรงกันของประเภทในขณะคอมไพล์ได้ด้วยระบบประเภทที่แข็งแกร่ง จึงป้องกันข้อผิดพลาดขณะรันไทม์ได้

สถาปัตยกรรม Middleware: มาตรฐาน Tower กับระบบเฉพาะของ Actix

ชั้น middleware เป็นหนึ่งในจุดแยกสถาปัตยกรรมที่ชี้ขาดที่สุดระหว่างสอง framework Axum มอบหมายการจัดการ middleware ทั้งหมดให้กับระบบนิเวศ Tower Service trait ของ Tower เป็น framework-agnostic middleware ที่เขียนสำหรับ Tonic (gRPC), Hyper หรือบริการที่เข้ากันได้กับ Tower อื่น ๆ สามารถใช้ใน Axum ได้โดยไม่ต้องแก้ไข

use axum::{
    Router, middleware,
    routing::get,
    extract::Request,
    response::Response,
};
use tower_http::{
    cors::CorsLayer,
    compression::CompressionLayer,
    trace::TraceLayer,
};
use std::time::Instant;

async fn timing_middleware(
    request: Request,
    next: middleware::Next,
) -> Response {
    let start = Instant::now();
    let response = next.run(request).await;
    let duration = start.elapsed();
    tracing::info!("Request took {:?}", duration);
    response
}

fn build_router() -> Router {
    Router::new()
        .route("/api/data", get(|| async { "ok" }))
        .layer(middleware::from_fn(timing_middleware))
        .layer(CompressionLayer::new())
        .layer(CorsLayer::permissive())
        .layer(TraceLayer::new_for_http())
}

ลำดับ layer มีความสำคัญอย่างยิ่ง: middleware ที่เพิ่มเข้ามาล่าสุดจะถูกเรียกใช้ก่อน (LIFO) ในตัวอย่างข้างต้น request จะผ่าน TraceLayer, CorsLayer, CompressionLayer และสุดท้ายคือ timing middleware ตามลำดับ

Actix Web พัฒนาโครงสร้างพื้นฐาน middleware เฉพาะของตัวเองที่อิงบน trait Transform ระบบนี้เปิดโอกาสให้ปรับแต่งได้ลึกกว่าสำหรับกรณีใช้งานเฉพาะ แต่ไม่เข้ากันได้โดยตรงกับระบบนิเวศ Tower การแบ่งปัน middleware ระหว่างบริการที่แตกต่างกันต้องใช้ชั้น adaptor เพิ่มเติม

การบูรณาการฐานข้อมูลด้วย SQLx

SQLx เป็นมาตรฐานโดยพฤตินัยสำหรับการเข้าถึงฐานข้อมูลแบบ asynchronous ในระบบนิเวศ Rust SQLx ตรวจสอบคำสั่ง SQL กับ schema ฐานข้อมูลจริงในขณะคอมไพล์ จึงสามารถจับความไม่ตรงกันของประเภท ข้อผิดพลาดในการพิมพ์ และการอ้างอิงคอลัมน์ที่ขาดหายไปในระหว่างกระบวนการพัฒนา

การบูรณาการ SQLx กับทั้งสอง framework มีโครงสร้างที่เกือบเหมือนกัน เนื่องจาก SQLx ทำงานที่ระดับ connection pool อย่างเป็นอิสระจากชั้น HTTP:

use sqlx::PgPool;

#[derive(sqlx::FromRow, serde::Serialize)]
struct User {
    id: i64,
    email: String,
    created_at: chrono::NaiveDateTime,
}

async fn find_user_by_email(
    pool: &PgPool,
    email: &str,
) -> Result<Option<User>, sqlx::Error> {
    sqlx::query_as!(
        User,
        "SELECT id, email, created_at FROM users WHERE email = $1",
        email
    )
    .fetch_optional(pool)
    .await
}

ความแตกต่างเดียวระหว่าง framework อยู่ที่วิธีส่ง connection pool ไปยังฟังก์ชัน handler: Actix Web ใช้ web::Data<PgPool> ในขณะที่ Axum ใช้ State<Arc<PgPool>> หรือ State<PgPool> โดยตรงสำหรับ pool ที่ implement trait Clone ตรรกะการเข้าถึงฐานข้อมูลสามารถพกพาได้อย่างสมบูรณ์ระหว่างสอง framework

รูปแบบการจัดการข้อผิดพลาด

ใน API ระดับ production การจัดการข้อผิดพลาดที่สม่ำเสมอมีความสำคัญอย่างยิ่ง Axum มีกลไก type-safe ผ่าน trait IntoResponse สำหรับการแปลง error ของแอปพลิเคชันเป็น HTTP response:

use axum::{
    http::StatusCode,
    response::{IntoResponse, Response},
    Json,
};

enum AppError {
    NotFound(String),
    DatabaseError(sqlx::Error),
    ValidationError(String),
}

impl IntoResponse for AppError {
    fn into_response(self) -> Response {
        let (status, message) = match self {
            AppError::NotFound(msg) => (
                StatusCode::NOT_FOUND, msg
            ),
            AppError::DatabaseError(_) => (
                StatusCode::INTERNAL_SERVER_ERROR,
                "Internal server error".to_string(),
            ),
            AppError::ValidationError(msg) => (
                StatusCode::BAD_REQUEST, msg
            ),
        };
        (status, Json(serde_json::json!({ "error": message })))
            .into_response()
    }
}

async fn get_user(
    axum::extract::Path(id): axum::extract::Path<i64>,
) -> Result<Json<serde_json::Value>, AppError> {
    if id <= 0 {
        return Err(AppError::ValidationError(
            "ID must be positive".to_string()
        ));
    }
    Ok(Json(serde_json::json!({ "id": id })))
}

Actix Web ใช้ trait ResponseError ความแตกต่างหลักคือ: Actix Web กำหนดให้ประเภท error ต้อง implement ทั้ง trait std::fmt::Display และ ResponseError ในขณะที่ Axum ต้องการเพียง implement IntoResponse ในทางปฏิบัติ การกำหนดประเภท error ใน Axum ต้องการ boilerplate น้อยกว่าเล็กน้อย

แนวทางการเลือก Framework

เมื่อใดควรเลือก Actix Web

ให้ความสำคัญกับ raw throughput: ในระบบที่ทุกไมโครวินาทีมีความหมาย (การซื้อขายความถี่สูง, เกมเซิร์ฟเวอร์, CDN edge node) ข้อได้เปรียบ throughput 10-15 เปอร์เซ็นต์ของ Actix Web สามารถให้ประโยชน์ที่เป็นรูปธรรมได้

มีการลงทุนในระบบนิเวศ Actix อยู่แล้ว: โปรเจกต์ที่ใช้ actix-rt, actix-codec หรือ actix-web-actors มีความเข้ากันได้ตามธรรมชาติกับ Actix Web

แอปพลิเคชันที่ใช้ WebSocket หนัก: การจัดการการเชื่อมต่อ WebSocket ผ่านโมเดล Actor ด้วย actix-web-actors เสนอสถาปัตยกรรมที่เป็นธรรมชาติและมีประสิทธิภาพสำหรับแอปพลิเคชัน real-time

เมื่อใดควรเลือก Axum

การบูรณาการระบบนิเวศ Tower: ในโปรเจกต์ที่ทำงานร่วมกับ Tonic (gRPC), Hyper หรือบริการที่อิงบน Tower อื่น ๆ ข้อได้เปรียบในการนำ middleware กลับมาใช้ซ้ำมีความสำคัญมาก

สถาปัตยกรรมเรียบง่ายและโปร่งใส: ทีมที่ต้องการมองเห็นและควบคุมกระบวนการประมวลผล HTTP ได้สูงสุดจะพบว่าแนวทางของ Axum ช่วยให้การ debug ง่ายขึ้น

Memory footprint ต่ำ: ในการ deploy แบบ serverless หรือสภาพแวดล้อมที่รันหลาย instance พร้อมกัน การใช้หน่วยความจำพื้นฐานที่ต่ำกว่าของ Axum สามารถส่งผลกระทบเชิงบวกต่อต้นทุนโครงสร้างพื้นฐานรวม

การบูรณาการ Tokio: ในฐานะส่วนประกอบอย่างเป็นทางการของโปรเจกต์ Tokio Axum ปรับตัวเข้ากับเวอร์ชัน Tokio ใหม่ได้อย่างรวดเร็วและปฏิบัติตามหลักการออกแบบของ Tokio อย่างสม่ำเสมอ

คำถามสัมภาษณ์และคำตอบ

คำถามต่อไปนี้ครอบคลุมหัวข้อที่พบบ่อยที่สุดในการสัมภาษณ์เทคนิคสำหรับตำแหน่ง Rust backend ในปี 2026

คำถามที่ 1: ความแตกต่างด้านสถาปัตยกรรมพื้นฐานระหว่าง Actix Web กับ Axum คืออะไร?

Actix Web ใช้โมเดล pinned-thread โดยที่ worker thread แต่ละตัวจัดการ Tokio runtime อิสระและ request จะถูกประมวลผลต่อบน thread ที่เริ่มต้น Axum ใช้ work-stealing scheduler ของ Tokio โดยตรง โดย task จะถูก thread ที่ว่างรับไปทำแบบไดนามิก ความแตกต่างนี้ส่งผลโดยตรงต่อคุณลักษณะด้านประสิทธิภาพและการบูรณาการระบบนิเวศ

คำถามที่ 2: รูปแบบ Extractor ใน Axum ทำงานอย่างไร?

Extractor คือประเภทที่ implement trait FromRequest หรือ FromRequestParts เมื่อกำหนดเป็นพารามิเตอร์ของฟังก์ชัน handler จะดึงข้อมูลจาก HTTP request ที่เข้ามาโดยอัตโนมัติ กฎสำคัญ: extractor ที่ใช้ body ของ request (Json, Body) ต้องวางเป็นพารามิเตอร์สุดท้ายเสมอ

คำถามที่ 3: ทำไม State ใน Axum ถึงต้องห่อด้วย Arc?

โครงสร้าง Router ของ Axum ต้อง implement trait Clone เนื่องจาก State เป็นส่วนหนึ่งของ Router จึงต้องสามารถ clone ได้ Arc<T> ช่วยให้ clone ได้อย่างมีประสิทธิภาพผ่าน reference counting สำหรับประเภทที่ implement Clone อยู่แล้ว (เช่น SQLx pool) ไม่จำเป็นต้องใช้ Arc wrapper

คำถามที่ 4: ความแตกต่างหลักระหว่าง Tower middleware กับ Actix middleware คืออะไร?

Tower middleware implement trait Service แบบ generic และเป็น framework-agnostic สามารถใช้โดยไม่ต้องแก้ไขใน Axum, Tonic และ Hyper Actix middleware เฉพาะสำหรับ Actix Web และไม่เข้ากันได้โดยตรงกับบริการ Tower ในสถาปัตยกรรมที่ต้องการแบ่งปัน middleware ระหว่างบริการต่าง ๆ แนวทาง Tower ให้ข้อได้เปรียบที่ชัดเจน

คำถามที่ 5: การตรวจสอบ query ขณะคอมไพล์ของ SQLx ทำงานอย่างไร?

SQLx เชื่อมต่อกับฐานข้อมูลจริงในระหว่างกระบวนการคอมไพล์ผ่านมาโคร query_as! เพื่อตรวจสอบความถูกต้องของไวยากรณ์ SQL, ความตรงกันของประเภท และการมีอยู่ของคอลัมน์ ชื่อคอลัมน์ที่ผิดหรือความไม่ตรงกันของประเภทจะถูกรายงานเป็น error ขณะคอมไพล์ สำหรับสภาพแวดล้อม CI/CD ไฟล์ metadata ที่สร้างล่วงหน้าด้วยคำสั่ง cargo sqlx prepare ช่วยให้คอมไพล์แบบ offline ได้

คำถามที่ 6: เหตุผลเบื้องหลังการเปลี่ยนแปลงไวยากรณ์ /{id} ใน Axum 0.8 คืออะไร?

Axum 0.8 เปลี่ยนไวยากรณ์พารามิเตอร์เส้นทางจากรูปแบบ Express /:param เป็นรูปแบบ /{param} ที่สอดคล้องกับ RFC 6570 การเปลี่ยนแปลงนี้เพิ่มความสามารถในการทำงานร่วมกับเครื่องมือเอกสาร OpenAPI และสร้างความสม่ำเสมอกับ web framework ในภาษาโปรแกรมอื่น ๆ

คำถามที่ 7: เกณฑ์ใดที่กำหนดการเลือก framework เว็บ Rust สำหรับสภาพแวดล้อม production?

กระบวนการตัดสินใจควรพิจารณาประสบการณ์ของทีม ความต้องการบูรณาการกับระบบนิเวศ Tower ข้อกำหนดการนำ middleware กลับมาใช้ซ้ำ ระดับความอ่อนไหวด้านประสิทธิภาพ ความต้องการ WebSocket หรือ streaming และแผนการบำรุงรักษาระยะยาวของโปรเจกต์ เนื่องจากความแตกต่างด้านประสิทธิภาพ 10-15 เปอร์เซ็นต์ไม่มีนัยสำคัญสำหรับแอปพลิเคชันส่วนใหญ่ การตัดสินใจมักถูกกำหนดโดยความเข้ากันได้ของระบบนิเวศและความสามารถของทีม

สรุป

การเลือกระหว่าง Actix Web กับ Axum เกี่ยวข้องโดยตรงกับความต้องการเทคนิคของโปรเจกต์และความสามารถของทีม จุดแข็งและจุดอ่อนของทั้งสองตัวเลือกสามารถสรุปได้ดังนี้:

• Actix Web 4.13 ให้ raw throughput สูงกว่า 10-15 เปอร์เซ็นต์ในเบนช์มาร์กสังเคราะห์ ระบบนิเวศที่เติบโตเต็มที่ และการสนับสนุนโมเดล Actor แบบบูรณาการ
• Axum 0.8 โดดเด่นด้วยความเข้ากันได้กับ Tower การออกแบบที่เรียบง่าย การบูรณาการ Tokio อย่างแน่นแฟ้น และ memory footprint ที่ต่ำกว่า
• ทั้งสอง framework ได้รับการพิสูจน์แล้วในสภาพแวดล้อม production และถูกใช้งานอย่างต่อเนื่องในระบบขนาดใหญ่
• ในแอปพลิเคชันจริงที่เกี่ยวข้องกับการดำเนินการ I/O ความแตกต่างด้านประสิทธิภาพจาก framework ลดลงสู่ระดับที่ละเลยได้
• SQLx และไลบรารีฐานข้อมูลอื่น ๆ ทำงานเหมือนกันบนทั้งสอง framework ทำให้ชั้นฐานข้อมูลเป็นอิสระจากการเลือก framework
• สำหรับโปรเจกต์ใหม่ที่ยังไม่มีความชอบ Axum เสนอจุดเริ่มต้นที่เป็นรูปธรรมด้วยความเข้ากันได้กับระบบนิเวศ Tower ที่กว้างขวางและการสนับสนุนจากองค์กรของ Tokio
• ทีมที่มีประสบการณ์กับ Actix Web อยู่แล้วไม่มีเหตุผลที่จำเป็นต้องเปลี่ยน ทั้งสองเส้นทางให้รากฐานที่มั่นคงและมีประสิทธิภาพสูงสำหรับการสร้าง web service