Throughput ve şema-tabanlı JSON serileştirme
Fastify'ın resmi benchmark sayfası (fastify.dev/benchmarks, 2 Eylül 2026), tek instance Node.js ölçümünde Fastify'ı 97.595 istek/saniye ile Express 5.2.1'in 59.651'ine karşı yaklaşık 1,6 kat önde gösteriyor; gecikmede de Fastify 9,73 ms ile Express'in 16,25 ms'sine karşı 1,7 kat düşük. Farkın büyük kısmı fast-json-stringify denen şema-derlenmiş serileştirme motorundan geliyor: şemanı önceden tanımlarsan Fastify, genel JSON.stringify yerine o şemaya özel derlenmiş bir fonksiyon kullanıyor.
Ama bu rakamları mutlak gerçek gibi sunmak yanlış — sayfanın kendisi "illustrative, real-world results depend on your hardware" diyor. Bağımsız, üçüncü taraf güncel bir kamuya açık benchmark da yok. Pratik sonuç: yüksek RPS hedefleyen JSON-ağırlıklı API'de bu gerçek bir avantaj, ama çoğu CRUD servisinde darboğaz DB sorgusu oluyor.
Şema doğrulama ve OpenAPI üretimi
Fastify'ın doğrulama felsefesi baştan şema-merkezli: resmi dokümantasyon "Fastify uses a schema-based approach, we recommend using JSON Schema" diyor ve bu şemayı Ajv v8 ile performanslı bir fonksiyona derliyor. Doğrulama yalnız content-type: application/json istekleri için tetikleniyor. Üstüne, resmi @fastify/swagger paketi route şemalarından otomatik OpenAPI v2/v3 dokümantasyonu üretiyor — API sözleşmeni elle yazmana gerek kalmıyor.
Express tarafında bu işlev framework'ün kendi sorumluluğunda değil. expressjs.com dokümantasyonunda resmi bir şema doğrulama ya da OpenAPI üretim bölümü yok; bu iş express-validator ya da express-openapi-validator gibi üçüncü parti paketlere bırakılmış. Bu senin için sorun olmayabilir — paket ekosistemi geniş — ama "framework içinden gelen tutarlı bir sözleşme" arıyorsan bunu kendin kurman gerekiyor.
Sonuç olarak: API-first çalışan, otomatik dokümantasyon isteyen ekipler için Fastify'ın yerleşik şema-OpenAPI zinciri gerçek bir zaman kazancı. Express'te aynı sonucu almak mümkün ama paket seçimi ve entegrasyon sorumluluğu sana kalıyor.
Plugin/middleware modeli ve kapsülleme (encapsulation)
Fastify'ın mimari çekirdeği "encapsulation context". Resmi dokümana göre bu, hangi decorator, hook ve plugin'in hangi route'a erişebileceğini yönetiyor: her alt-context kök seviyesindeki plugin'lere erişebiliyor, ama bir alt-context kendi grandchild'ında kayıtlı plugin'lere erişemiyor — izolasyon tek yönlü ve öngörülebilir. Büyük bir uygulamada bir route grubuna özel middleware'in başka gruba sızmasını mimari düzeyde engelliyor.
Express'te böyle bir kavram yok. Resmi glossary'ye göre middleware, routing katmanı tarafından final handler'dan önce çağrılan bir fonksiyon ve app.use(mw) ile global işleme yığınına ekleniyor — varsayılan davranış global, route bazlı izolasyonu sen kurmak zorundasın.
Küçük bir API'de bu fark hissedilmez; çok-ekipli büyük bir API'de Fastify'ın encapsulation'ı "hangi middleware nereye sızdı" hatalarını yapısal olarak azaltıyor.
Async hata yönetimi ve unhandled rejection davranışı
Express 5'in en somut kazanımı burada. Resmi dokümana göre bir handler Promise döndürüyorsa ve reject olursa ya da throw ederse, Express otomatik next(value) çağırıyor — async fonksiyonlar zaten Promise döndürdüğü için hataları ekstra iş yapmadan Express'e ulaşıyor. Express 4'e göre büyük iyileşme: eskiden her async route'u manuel try/catch ile sarmak gerekiyordu.
Tuzak hâlâ duruyor: handler Promise'i return etmezse, Express bunun varlığından haberdar olmuyor ve rejection unhandled kalıp process çökme riski taşıyor. Callback-tabanlı Node API'lerinin (örn. fs) hataları da otomatik yakalanmıyor — elle next(err)'e geçirmen gerek.
Fastify tarafında ayrı bir "unhandled rejection" dokümanı yok; hata yönetimi setErrorHandler ve hook'lar üzerinden merkezi toplanıyor. Çıkarım: Express 5 async hataları çok daha iyi yakalıyor ama "return unutma" tuzağı canlı bir hata kaynağı.
TypeScript desteği kalitesi
İki taraf da dürüst itiraflarda bulunuyor, ama pozisyonları farklı. Fastify'ın resmi dokümanı: "framework vanilla JavaScript ile yazıldı, tip tanımlarını sürdürmek kolay değil; sürüm 2'den beri bakımcılar büyük çaba harcadı" — ve ekliyor: "API'nin bazı kısımları tiplenmemiş ya da yanlış tiplenmiş olabilir". Tip sistemi sürüm 3'te değişti, generic constraining eklendi. Paket metadata'sında ([email protected]) types: fastify.d.ts gömülü geliyor.
Express'in npm paket metadata'sında bir types alanı yok. Resmi paket TypeScript tanımı içermiyor; topluluk bakımlı @types/express ayrı bir paket — Express'in kendi kaynağı değil, gecikme riski framework'ün kontrolünde değil.
Sonuç: Fastify "resmi ama itiraf edilmiş eksik" tipler sunuyor, Express "topluluk bakımlı, ayrı paket" tipler sunuyor — ikisi de mükemmel değil.
Logging ve gözlemlenebilirlik varsayılanları
Fastify'da logging varsayılan kapalı; { logger: true } ile açıyorsun ve framework performans odaklı olduğu için varsayılan logger pino, açılınca varsayılan seviye "info". Her request kendi scope'unda request.log.info(...) gibi yapılandırılmış bir logger'a erişiyor — request-scoped structured logging ayrı kurulum gerektirmiyor.
Express'in çekirdeğinde logger yok, ama resmi "Production best practices" sayfası bu boşluğu adıyla dolduruyor: uygulama etkinliğini kaydederken "use a logging library like Pino, which is the fastest and most efficient option available" diyor, debug amaçlı çıktı içinse console.log yerine debug modülünü öneriyor. Yani fark "öneri var, varsayılan yok" ekseninde: Express sana aynı logger'ı tavsiye ediyor ama kurulumu sana bırakıyor; Fastify tam olarak o logger'ı kutudan çıkar halde veriyor. morgan ve winston bu boşlukta yaygın alternatifler, resmi tavsiye değil.
Bu, hız ile esneklik arasındaki klasik takas: Fastify'da structured logging hazır ama pino'ya bağımlısın; Express'te varsayılan yok ama logging çözümünü özgürce seçiyorsun.
Öğrenme kaynağı, işe alım havuzu ve göç maliyeti
Ham popülerlikte Express açık ara önde: GitHub'da 69.478 yıldız ve 25.065 fork'a karşı Fastify'ın 37.195 yıldız ve 3.036 fork'u (api.github.com, 25 Eylül 2026). Bu fark yalnız prestij değil — daha fazla Stack Overflow cevabı, tutorial, geniş bir işe alım havuzu demek. Yeni bir geliştiriciyi Express'e alıştırmak kaynak bolluğu yüzünden istatistiksel olarak daha kolay.
Göç tarafında ayrım net: Express'in kendi 4→5 geçişi için resmi codemod var (npx codemod@latest @expressjs/v5-migration-recipe). Ama Express'ten Fastify'a resmi bir migration guide yok — route imzası (req,res)'ten (request,reply)'e, middleware plugin/hook yapısına dönüşüyor. Üstüne Fastify v5 yalnız Node.js v20+ destekliyor.
Kısacası: net bir performans darboğazı kanıtlamadan göçün maliyeti genelde getirisinden fazla; sıfırdan başlıyorsan bu maliyet hiç yok.