Rust ile Web Gelistirme: Actix Web ve Axum Karsilastirmasi ile Mulakat Sorulari 2026

Rust, bellek guvenligi garantilerini performanstan odun vermeden saglayan tek sistem programlama dili olarak backend gelistirme alaninda kendine saglam bir yer edinmistir. Calisma zamaninda garbage collector gerektirmeyen sahiplik (ownership) modeli, C++ seviyesinde hiz sunarken null pointer ve data race gibi hatalari derleme asamasinda elimine etmektedir. 2026 yilinda Rust web ekosisteminde iki framework on plana cikmaktadir: Actix Web 4.14 ve Axum 0.8. Bu iki framework ayni dil uzerinde insa edilmis olmakla birlikte, calisma zamani mimarisi, middleware stratejisi ve ekosistem entegrasyonu acisindan birbirinden keskin cizgilerle ayrismaktadir.

Mimari Yaklasim: Sabitlenmis Thread ve Work-Stealing Modeli

Actix Web ve Axum arasindaki en kokenlu fark, eslesmezlik (concurrency) modelinde yatmaktadir. Actix Web, her bir worker thread'inin kendi bagimsiz Tokio runtime'ina sahip oldugu sabitlenmis thread (pinned-thread) mimarisini benimsemistir. Bu tasarimda bir istek hangi thread uzerinde baslatildiysa, yasam dongusu boyunca ayni thread uzerinde islenmeye devam eder. Sonuc olarak thread'ler arasi veri paylasim maliyeti minimuma indirilmis olur ve cache yerelseligi (cache locality) korunur.

Axum ise Tokio'nun work-stealing zamanlayicisini dogrudan kullanmaktadir. Gorevler (tasks), bosta kalan thread'ler tarafindan dinamik olarak sahiplenilir. Bu yaklasim, dengesiz is yuku dagilimi olan senaryolarda thread'lerin verimli kullanilmasini saglar; ancak gorev gecisleri sirasinda ek zamanlayici maliyeti olusturabilir.

Asagidaki iki minimal sunucu ornegi, farkli giris noktalarini acikca ortaya koymaktadir:

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, runtime yapilandirmasini #[actix_web::main] makrosu araciligiyla kendi buyesinde yurutmektedir; worker sayisi, kapatma zamanlari ve TLS ayarlari bu katmanda yonetilir. Axum ise standart #[tokio::main] makrosuyla Tokio'nun varsayilan yapilandirmasi uzerinden calisir. Bu tercih, Axum'un Tokio ekosistemiyle sifir surtuneyle butunlesmesinin temelini olusturmaktadir.

Routing mekanizmalarinda da belirgin bir ayrim mevcuttur. Actix Web hem makro tabanli (#[get("/")]) hem de programatik route tanimlama destegi sunarken, Axum yalnizca programatik yaklasimi benimsemistir. Axum'un bu karari, router kompozisyonu uzerinde acik kontrol saglamakta ve buyuk projelerde route agacinin programatik olarak olusturulmasini kolaylastirmaktadir.

Performans Olcumleri: Actix Web 4.14 ve Axum 0.8

TechEmpower Round 23 (Ocak 2026) verileri en guvenilir karsilastirmayi sunmaktadir. Her iki framework de tum kategorilerde ust siralarda yer almaktadir.

Actix Web tum kategorilerde yuzde 10-15 throughput avantaji saglamaktadir. Axum, paylasimli Tokio runtime nedeniyle biraz daha az bellek kullanmaktadir. Karsilastirma acisindan, her iki framework de Go'nun standart kutuphane HTTP sunucusunu 2-3 kat, Node.js'i ise 5-8 kat geride birakmaktadir.

Performans farki, reklam sunumu, gercek zamanli analitik potoki ve yuksek frekansl islem gecitleri gibi senaryolarda onem tasimaktadir. Saniyede 10.000 istek isleyen tipik bir REST API icin her iki framework de darbogazin cok otesindedir; darbogaz veritabani veya dis servis cagrilari olacaktir.

Extractor Desenleri ve Istek Isleme

Extractor'lar, framework'lerin gelen istekleri nasil pars ettigini tanimlar. Axum 0.8, #[async_trait] makrosunu kaldirarak natif async trait'ler lehine ve daha iyi Option<T> islemesi icin OptionalFromRequestParts ekleyerek bu alanda onemli iyilestirmeler yapmistir.

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

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

// Handler'lar arasinda paylasilan state
struct AppState {
    db_pool: sqlx::PgPool,
}

// Axum 0.8: /{id} sozdizimi (/:id'nin yerini aldi)
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);
    // state.db_pool kullanarak veritabani sorgusu
    Json(serde_json::json!({
        "user_id": user_id,
        "page": page
    }))
}

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
    }))
}

Axum'un extractor'lari fonksiyon parametrelerinde dogrudan tuple destructuring kullanmaktadir. Actix Web her seyi web::Path, web::Query vb. ile sarmalamakta ve .into_inner() cagrilari gerektirmektedir. Her iki yaklasim da derleme zamaninda tip guvenlidir, ancak Axum'un sozdizimi daha dogal okunmaktadir.

Middleware Mimarisi: Tower Standardi ve Actix Ozgun Yapisi

Middleware katmani, iki framework arasindaki en belirleyici mimari ayrisma noktalarindan birini teskil etmektedir. Axum, middleware yonetimini tamamen Tower ekosistemine devretmistir. Tower'in Service trait'i framework bagimsizdır; Tonic (gRPC), Hyper veya baska bir Tower uyumlu servis icin yazilmis bir middleware, hicbir degisiklik yapilmadan Axum'da da kullanilabilmektedir.

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

// Duz bir async fonksiyon olarak ozel middleware
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())
}

Actix Web ise Transform trait'ine dayanan kendine ozgu bir middleware altyapisi gelistirmistir. Bu sistem, belirli kullanim durumlarinda daha derin ozellestirme olanagi tanirken, Tower ekosistemine dogrudan uyumlu degildir. Farkli servisler arasinda middleware paylasimi ek adaptor katmanlari gerektirmektedir.

Actix Web 4.14, middleware sarmalamadan sonra handler eklenmesi durumunda panic veren rota middleware dogrulamasi getirmistir; bu, yapilandirma hatalarini runtime yerine baslatma sirasinda yakalamaktadir.

SQLx ile Veritabani Entegrasyonu

SQLx, derleme zamaninda sorgulari dogrulayan async-first SQL aracidir. Her iki framework ile entegrasyon neredeyse ozdes bir yapidadir:

use sqlx::PgPool;

// Bu struct Actix Web ve Axum ile ayni sekilde calisir
#[derive(sqlx::FromRow, serde::Serialize)]
struct User {
    id: i64,
    email: String,
    created_at: chrono::NaiveDateTime,
}

// sqlx::query_as! derleme zamaninda canli bir DB'ye karsi dogrular
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
}

Veritabani katmani framework seciminizden bagimsiz olarak ayni kalmaktadir. SQLx'in query_as! makrosu derleme zamaninda canli bir veritabanina baglanarak sutun adlarini, turlerini ve tablo varligini dogrular. Bir sutun adindaki yazim hatasi, runtime cokusune degil derleme hatasina neden olur.

Hata Yonetimi Desenleri

Hata islemesi farkli tasarim felsefelerini ortaya koymaktadir. Actix Web ResponseError trait implementasyonlarini kullanmaktadir. Axum, Result tipiyle birlikte IntoResponse'a dayanmaktadir.

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

// Uygulama duzeyinde hatalari tanimla
enum AppError {
    NotFound(String),
    DatabaseError(sqlx::Error),
    ValidationError(String),
}

// Hatalari HTTP yanitlarina donustur
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()
    }
}

// Handler'lar Result<T, AppError> doner
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 })))
}

Axum'un yaklasimi Rust'in ? operatoru ve Result tipiyle dogal bir sekilde birarada calismaktadir. Actix Web, hem Display hem de ResponseError trait'lerinin uygulanmasini gerektiren ResponseError araciligiyla ayni sonuca ulasmaktadir. Her ikisi de calismakta, ancak Axum'un deseni From trait'i ve hata yayilimina aliskin Rust gelisitirceleri icin daha deyimsel hissettirmektedir.

Framework Secim Rehberi

Actix Web Hangi Senaryolarda Tercih Edilmeli

• Maksimum throughput gereksinimleri: Reklam degisimi, gercek zamanli teklif verme, analitik yutma potoki, yuzde 10-15 daha fazla req/s'nin odunu hakli kilacagi durumlar.
• WebSocket yogun uygulamalar: Actix Web'in WebSocket destegi daha fazla production dagitiminda sinanmistir. Axum'un WebSocket destegi (axum::extract::ws araciligiyla) iyi calismaktadir ancak daha kisa bir production gecmisine sahiptir.
• Mevcut Actix Web kod tabanlari: Actix Web 3.x'ten 4.x'e gecis sorunsuzdur. Stabil servislerin Axum'a yeniden yazilmasi azalan getiriler saglamaktadir.
• Takim asinaligi: Takim zaten Actix Web'i biliyorsa, ergonomik kazanimlar icin framework degistirmek nadiren kisa vadede karsiligini vermektedir.

Axum Hangi Senaryolarda Tercih Edilmeli

• 2026'da yeni projeler: Tokio ekosistemi (Tonic, Hyper, Tower) hizalamasi entegrasyon surtunesini azaltmaktadir.
• Karisik gRPC ve HTTP servisleri: Tower middleware adaptasyon katmanlari olmadan her iki protokolde de calismaktadir.
• Rust'a yeni takimlar: Axum'un tip odakli extractor'lari ve derleme zamani hata mesajlari daha yumusak bir ogrenme egrisi saglamaktadir. /{id} yol sozdizimi (OpenAPI ile hizali) hemen taninir niteliktedir.
• Mikroservis mimarileri: Tower'in Service trait'i servisler arasinda middleware yeniden kullanimini mumkun kilarak kazan kodunu azaltmaktadir.

Mulakat Sorulari ve Yanitlari

Backend Rust mulakat sorulari giderek artan bir sekilde web framework bilgisini kapsamaktadir. Bu sorular senior backend ve sistem muhendisligi mulakatlarinda ortaya cikmaktadir.

S: Actix Web'in ve Axum'un runtime modelleri arasindaki mimari farki aciklayin.

Actix Web her CPU cekirdegi icin bir tek-thread'li Tokio runtime olusturur. Gorevler thread'lere sabitlenmistir ve work-stealing overhead'ini ortadan kaldirarak goc etmez. Axum, work-stealing ile paylasimli bir cok-thread'li Tokio runtime uzerinde calisir. Actix Web'in modeli yogun yuk altinda cache-line catismasini azaltarak daha yuksek throughput uretir. Axum'un modeli paylasilan durum yonetimini basitlestir cunku tum gorevler bir runtime'i paylasmaktadir.

S: Axum 0.8'in #[async_trait] kaldirmasi ozel extractor'lari nasil etkiler?

Axum 0.8, Rust'in natif return-position impl Trait in traits ozelligini kullanir (2023 sonu stabilize edilmistir). FromRequestParts veya FromRequest uygulayan ozel extractor'lar artik #[async_trait] ozeligi olmadan dogrudan async metodlar tanimlamaktadir. Bu, Box<dyn Future>'dan heap tahsislerini ortadan kaldirmakta ve derleme surelerini iyilestirmektedir. Mevcut extractor'larin makroyu kaldirmasi ve trait implementasyonlarini uyarlamasi gerekmektedir.

S: Tower middleware'in Actix Web middleware'inden farkini tanimlayin.

Tower, protokolden bagimsiz genel bir Service<Request> trait'i tanimlar. Bir Tower timeout katmani HTTP (Axum), gRPC (Tonic) ve herhangi bir ozel protokolle calismaktadir. Actix Web'in middleware'i framework'e ozgu Transform ve Service trait'lerini kullanmaktadir. Pratik etki: Axum middleware'i Tower ekosisteminde yeniden kullanilabilirdir; Actix Web middleware'i framework'e ozgudur.

S: SQLx derleme zamani sorgu dogrulamasi nasil calisir ve odunleri nelerdir?

SQLx'in query_as! makrosu derleme sirasinda canli bir PostgreSQL veritabanina baglanir. SQL sozdizimi, sutun adlari, turler ve tablo varligini dogrular. Odun: build veritabani erisimi gerektirir, bu da CI pipeline'larini karistirmaktadir. SQLx, cevrimdisi sorgu metadatasi olusturmak icin sqlx prepare saglamakta ve dogrulama sonuclarini surum kontrolune commit edilen bir .sqlx dizininde onbellegemektedir.

S: Actix Web'i Axum yerine secmek ne zaman teknik olarak dogru karar olur?

Actix Web, surekli throughput birincil kisitlama oldugunda dogrudur: reklam sunumu, gercek zamanli analitik yutma veya yuksek frekansl islem gecitleri. Sabitlenmis thread runtime modeli work-stealing overhead'ini ortadan kaldirarak yuk altinda yuzde 10-15 daha fazla req/s uretmektedir. Axum, Tokio ekosistemi ile birlestirilebilirlik marjinal throughput kazanimlarindan daha onemli oldugunda, ozellikle hem HTTP hem de gRPC kullanan mikroservis mimarilerinde dogrudur.

Kaynaklar

• TechEmpower Framework Benchmarks Round 23 (Ocak 2026): JSON, plaintext ve veritabani testleri icin benchmark verileri
• Axum 0.8.9 Release Notes: WebSocket subprotokol secimi, minimum Rust surumu 1.80
• Actix Web 4.14.0 Release (Haziran 2026): rota middleware dogrulamasi, IPv6 dual-stack destegi, h1_write_buffer_size

2026'da Rust Web Gelistirme Icin Temel Cikarimlar

• Actix Web 4.14, sabitlenmis thread runtime modeli sayesinde yuzde 10-15 daha yuksek throughput saglamakta ve bu da onu gecikme hassasiyeti yuksek, yuksek throughput servisleri icin dogru secim haline getirmektedir
• Axum 0.8, natif async trait'ler, /{id} yol sozdizimi ve HTTP ve gRPC genelinde tam Tower middleware uyumlulugu ile daha iyi ergonomi saglamaktadir
• Her iki framework de ayni veritabani katmanini (derleme zamani dogrulamali SQLx) kullanmaktadir, bu nedenle secim veri erisim desenlerini etkilememektedir
• Asiri throughput gereksinimleri olmayan 2026'daki yeni Rust web projeleri icin Axum'un Tokio, Tonic ve Tower ile ekosistem hizalamasi uzun vadeli bakim maliyetini azaltmaktadir
• Bu konudaki mulakat sorulari, framework tercihini degil, runtime modellerinin, middleware mimarisinin ve odun muhakemesinin anlasilmasini test etmektedir
• Rust mulakatlarına hazirlık, yalnizca API sozdizimini degil, her iki framework'un mimari kararlarini anlamayi gerektirmektedir