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 ve Axum. Bu iki framework ayni dil uzerinde insa edilmis olmakla birlikte, calisma zamani mimarisi, middleware stratejisi ve ekosistem entegrasyonu acisindan birbirinden keskin cizgilerle ayrismaktadir. Bu makalede her iki framework teknik detaylariyla incelenmekte, guncel benchmark verileri paylasismakta ve Rust backend pozisyonlarina yonelik mulakat sorulari ele alinmaktadir.

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 ayrım 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.13 ve Axum 0.8

Sentetik benchmark sonuclari, framework'lerin ham kapasitesini gostermekle birlikte, gercek dunya uygulamalarindaki performansi dogrudan yansitmaz. I/O operasyonlari, veritabani erisimi ve is mantigi katmanlari eklendikce framework kaynakli farklar ihmal edilebilir duzeye geriler. Yine de bu veriler, temel mimari verimlilik hakkinda anlamli gostergeler sunmaktadir.

Asagidaki sonuclar, AMD EPYC 7763 islemcili (64 cekirdek) bir sunucuda Ubuntu 24.04 uzerinde wrk araci ve 256 esanli baglanti kullanilarak elde edilmistir:

| Metrik | Actix Web 4.13 | Axum 0.8.9 | |--------|---------------|-------------| | JSON serilestirme (req/s) | ~720.000 | ~640.000 | | Duz metin (req/s) | ~980.000 | ~870.000 | | Tekli DB sorgusu (req/s) | ~180.000 | ~170.000 | | Bellek kullanimi (hello world) | ~8 MB | ~6 MB | | P99 gecikme (JSON) | 1,2 ms | 1,4 ms |

Actix Web, saf HTTP islemleri acisindan yaklasik yuzde 10-15 oraninda throughput avantaji sunmaktadir. Bu fark, sabitlenmis thread mimarisinin cache yerelseligi avantajindan ve HTTP isleme katmaninin Tower soyutlama katmanindan bagimsiz olarak optimize edilmesinden kaynaklanmaktadir. Ancak veritabani erisimi iceren senaryolarda avantaj birkac yuzde puanina kadar gerilemektedir.

Axum'un bellek tuketimi konusunda dikkat cekici bir avantaja sahip olmasi goz ardi edilmemelidir. Aktor altyapisi tasimayan daha yalin mimari, bosta bekleyen sunucularin bellek ayak izini dusuk tutmaktadir. Cok sayida container instance'inin esanli calistirildigi Kubernetes veya serverless ortamlarda bu fark, toplam kaynak maliyetini anlamli olcude etkileyebilir.

Extractor Desenleri ve Istek Isleme

Her iki framework de HTTP isteklerinden tip guvenli veri cikarmak icin Extractor desenini benimsemistir. Kavramsil olarak ayni amaca hizmet etmelerine karsin, sozdizimi ve kisitlamalari birbirinden farklidir.

Axum 0.8, extractor'lari dogrudan handler fonksiyon parametreleri olarak tanimlayan fonksiyonel bir model kullanmaktadir:

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 ise sarmalayici (wrapper) tipler uzerinden benzer bir mekanizma sunmaktadir:

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 siralamasinda onemli bir kural farkliligi bulunmaktadir: Axum'da istek govdesini tuketen Json ve Body gibi extractor'lar mutlaka son parametre olarak konumlandirilmalidir. Actix Web bu kisitlamayi uygulamamaktadir. Ancak her iki framework de guclu tip sistemi sayesinde yanlis tip eslesmelerini derleme zamaninda tespit etmekte ve runtime hatalarini engellemektedir.

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;

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 sirasi belirleyici oneme sahiptir: son eklenen middleware ilk calistirilir (LIFO). Yukaridaki ornekte bir istek sirasiyla TraceLayer, CorsLayer, CompressionLayer ve en son timing middleware katmanindan gecmektedir.

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. Ornegin Tonic gRPC servisi ile Actix Web HTTP servisi arasinda ayni CORS middleware'ini paylasma gibi bir senaryo, her iki framework icin ayri implementasyonlar gerektirir.

SQLx ile Veritabani Entegrasyonu

SQLx, Rust ekosisteminde asenkron veritabani erisimi icin fiili standart konumundadir. Derleme zamaninda SQL sorgularini gercek bir veritabani semasina karsi dogrulayarak tip uyumsuzluklarini, yazim hatalarini ve eksik sutun referanslarini gelistirme surecinde yakalama olanagi sunmaktadir.

Her iki framework ile SQLx entegrasyonu neredeyse ozdes bir yapidadir. Bunun nedeni SQLx'in HTTP katmanindan bagimsiz olarak baglanti havuzu (connection pool) seviyesinde calisiyor olmasidir:

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'ler arasindaki tek fark, baglanti havuzunun handler fonksiyonlarina aktarilma bicimindedir: Actix Web web::Data<PgPool> yapisini kullanirken, Axum State<Arc<PgPool>> veya Clone trait'i uygulamis havuzlarda dogrudan State<PgPool> yapisini tercih eder. Veritabani erisim mantigi iki framework arasinda tamamen tasinabilirdir.

Derleme zamani sorgu dogrulamasi icin DATABASE_URL ortam degiskeninin tanimli olmasi ya da .env dosyasinda baglanti dizesinin bulunmasi gerekmektedir. CI/CD ortamlarinda cargo sqlx prepare komutuyla onceden olusturulan metadata dosyalari, cevrimdisi derlemeyi mumkun kilmaktadir.

Hata Yonetimi Desenleri

Uretim kalitesinde API'lerde tutarli hata yonetimi kritik oneme sahiptir. Axum, IntoResponse trait'i araciligiyla uygulama hatalarinin HTTP yanitlarina donusturulmesi icin tip guvenli bir mekanizma sunmaktadir:

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 ise ResponseError trait'ini kullanmaktadir. Temel fark su noktada ortaya cikmaktadir: Actix Web, hata tiplerinin hem std::fmt::Display hem de ResponseError trait'lerini uygulamasini zorunlu kilarken, Axum yalnizca IntoResponse implementasyonu ile yetinmektedir. Pratik sonuc olarak Axum'da hata tipi tanimlamak bir nebze daha az seremoniye ihtiyac duymaktadir.

Her iki framework de thiserror (derive makrosu ile hata tipi tanimlama) ve anyhow (genel amacli hata yonetimi) crate'leriyle uyumlu calismaktadir. Tip guvenli hatalarin HTTP yanitlarina otomatik donusumu, ic hata ayrintilarinin istemcilere yanlislikla sizdirilmasini onleyen onemli bir guvenlik katmani olusturmaktadir.

Framework Secim Rehberi

Actix Web Hangi Senaryolarda Tercih Edilmeli

Ham throughput onceligi: Her mikrodalganin kritik oldugu sistemlerde (yuksek frekansl trading, oyun sunuculari, CDN edge node'lari) Actix Web'in yuzde 10-15 throughput avantaji somut fayda saglayabilmektedir.

Mevcut Actix ekosistemi yatirimi: actix-rt, actix-codec veya actix-web-actors kullanan projelerde Actix Web ile dogal uyum mevcuttur.

WebSocket yogun uygulamalar: actix-web-actors araciligiyla WebSocket baglantilarinin Actor modeli ile yonetilmesi, gercek zamanli uygulamalar icin dogal ve etkili bir mimari sunmaktadir.

Axum Hangi Senaryolarda Tercih Edilmeli

Tower ekosistemi entegrasyonu: Tonic (gRPC), Hyper veya diger Tower tabanli servislerle calisilan projelerde middleware yeniden kullaniminin sagladigi avantaj belirgindir.

Minimalist ve seffaf mimari: HTTP isleme sureci uzerinde maksimum gorunurluk ve kontrol arayan ekipler icin Axum'un yaklasimi hata ayiklamayi kolaylastirmaktadir.

Dusuk bellek ayak izi: Serverless dagitimlar veya cok sayida instance'in esanli calistirildigi ortamlarda Axum'un daha dusuk taban bellek kullanimi toplam altyapi maliyetini olumlu yonde etkileyebilmektedir.

Tokio entegrasyonu: Tokio projesinin resmi bileseni olan Axum, Tokio'nun yeni surumleriyle hizli uyum saglamakta ve Tokio tasarim ilkelerini tutarli bicimde takip etmektedir.

Mulakat Sorulari ve Yanitlari

Asagidaki sorular, 2026 yilinda Rust backend pozisyonlarina yonelik teknik mulakatlarda en sik karsilasilan konulari kapsamaktadir.

Soru 1: Actix Web ve Axum arasindaki temel mimari fark nedir?

Actix Web, sabitlenmis thread modelini benimsemistir; her worker thread kendi bagimsiz Tokio runtime'ini yonetir ve istekler baslatildiklari thread uzerinde islenmeye devam eder. Axum ise Tokio'nun work-stealing zamanlayicisini dogrudan kullanir; gorevler bosta kalan thread'ler tarafindan dinamik olarak sahiplenilir. Bu fark, performans karakteristigini ve ekosistem entegrasyonunu dogrudan etkilemektedir.

Soru 2: Axum'daki Extractor deseni nasil calismaktadir?

Extractor'lar, FromRequest veya FromRequestParts trait'ini uygulayan tiplerdir. Handler fonksiyon parametreleri olarak tanimlandiklarinda, gelen HTTP isteginden otomatik olarak veri cikarirlar. Kritik kural: istek govdesini tuketen extractor'lar (Json, Body) mutlaka son parametre olarak yer almalidir.

Soru 3: Axum'da State neden Arc ile sarmalanmaktadir?

Axum'un Router yapisi Clone trait'ini uygulamak zorundadir. State, Router'in parcasi oldugundan klonlanabilir olmalidir. Arc<T>, paylasilan durumu referans sayaci uzerinden verimli bicimde klonlama olanagi tanir. Hali hazirda Clone uygulayan tipler (ornegin SQLx havuzlari) icin Arc sarmalayicisi zorunlu degildir.

Soru 4: Tower middleware ile Actix middleware arasindaki temel fark nedir?

Tower middleware, jenerik Service trait'ini uygular ve framework'ten bagimsizdir; Axum, Tonic ve Hyper gibi farkli servislerle degisiklik yapilmadan kullanilabilir. Actix middleware ise Actix Web'e ozgudur ve Tower servisleriyle dogrudan uyumlu degildir. Farkli servisler arasinda middleware paylasimi gerektiren mimarilerde Tower yaklasimi belirgin avantaj saglamaktadir.

Soru 5: SQLx'in derleme zamani sorgu dogrulamasi nasil calismaktadir?

SQLx, query_as! makrosu araciligiyla derleme surecinde canli bir veritabanina baglanarak SQL sorgularinin sozdizimi dogrulugunu, tip uyumunu ve sutun varligini kontrol eder. Hatali sutun adlari veya tip uyumsuzluklari derleme hatasi olarak raporlanir. CI/CD ortamlari icin cargo sqlx prepare komutuyla onceden olusturulan metadata dosyalari, cevrimdisi derlemeyi mumkun kilar.

Soru 6: Axum 0.8'deki /{id} sozdizimi degisikliginin gerekcesi nedir?

Axum 0.8, yol parametresi sozdizimini Express tarzindaki /:param notasyonundan RFC 6570 uyumlu /{param} notasyonuna gecirmistir. Bu degisiklik, OpenAPI dokumantasyon araclariyla daha iyi birlikte calisabilirlik saglamakta ve diger programlama dillerindeki web framework'leriyle tutarlilik olusturmaktadir.

Soru 7: Production ortami icin Rust web framework seciminde hangi kriterler belirleyicidir?

Karar alma surecinde ekip deneyimi, Tower ekosistemiyle entegrasyon ihtiyaci, middleware yeniden kullanilabilirlik gereksinimleri, performans hassasiyetinin duzeyi, WebSocket veya streaming gereksinimleri ve projenin uzun vadeli bakim plani degerlendirilmelidir. Yuzde 10-15'lik performans farki cogu uygulama icin ihmal edilebilir duzeyde oldugundan, karar genellikle ekosistem uyumu ve ekip yetkinlikleri dogrultusunda sekillenmektedir.

Sonuc

Actix Web ve Axum arasindaki tercih, projenin teknik gereksinimleri ve ekibin mevcut yetkinlikleriyle dogrudan iliskilidir. Her iki secenegin guclu ve zayif yonleri su sekilde ozetlenebilir:

• Actix Web 4.13, sentetik benchmark'larda yuzde 10-15 daha yuksek ham throughput, olgun bir ekosistem ve entegre Actor model destegi sunmaktadir
• Axum 0.8, Tower uyumlulugu, minimalist tasarimi, siKi Tokio entegrasyonu ve daha dusuk bellek ayak izi ile one cikmaktadir
• Her iki framework de production ortaminda kanitlanmis olup buyuk olcekli sistemlerde aktif kullanilmaktadir
• I/O operasyonlari iceren gercek dunya uygulamalarinda framework kaynakli performans farklari ihmal edilebilir duzeye inmektedir
• SQLx ve diger veritabani kutuphaneleri her iki framework ile ayni sekilde calismakta olup veritabani katmani framework seciminden bagimsiz kalmaktadir
• Mevcut bir tercih bulunmayan yeni projelerde Axum, genis Tower ekosistemi uyumlulugu ve Tokio'nun kurumsal destegi sayesinde pragmatik bir baslangic noktasi olusturmaktadir
• Actix Web deneyimine sahip ekiplerin gecis yapmasi icin zorlayici bir neden bulunmamaktadir; her iki yol da guvenilir ve yuksek performansli web servisleri insa etmek icin saglam bir temel sunmaktadir