Backend Yığını Seçimi: NestJS, Express ve .NET Ne Zaman?

Backend framework seçimi çoğu ekipte teknik bir tercih gibi tartışılır. Pratikte bir ekip kararıdır: altı ay sonra projeye katılan mühendisin ne kadar sürede üretken olacağını belirler.

Bu yazı bizim kullandığımız yığını ve nedenini anlatıyor: çoğu projede NestJS, pnpm ve Turborepo; kurumsal projelerde .NET. Express ile karşılaştırmasını da dürüstçe yapıyor.

Express'in gerçek maliyeti

Express kötü bir araç değil. Minimal, hızlı ve öğrenmesi bir saat sürüyor. Tek başına çalışan bir geliştirici için ya da tek iş yapan küçük bir servis için doğru seçim olabilir.

Sorun ölçekte başlıyor. Express size bir yapı dayatmadığı için her proje kendi yapısını icat ediyor. Üç farklı projede üç farklı klasör düzeni, üç farklı hata yönetimi yaklaşımı, üç farklı doğrulama yöntemi çıkıyor.

Bunun faturası iki yerde ödeniyor:

Ekibe katılım süresi. Yeni gelen mühendis her projede yeniden öğreniyor. "Bu projede servis katmanı var mı, hata nerede yakalanıyor, girdi nerede doğrulanıyor?" sorularının cevabı her seferinde farklı.

Devir maliyeti. Projeyi başka bir ekibe teslim ederken ya da yıllar sonra geri dönerken, kendi kurduğunuz düzeni hatırlamak zorundasınız. Dokümantasyon eskimişse kod tek kaynak oluyor.

Bu, tek projede görünmeyen ama on projede ağırlaşan bir maliyet.

NestJS neyi çözüyor

NestJS'in asıl değeri özellik listesi değil, kararları önceden vermiş olması.

Modül yapısı, bağımlılık enjeksiyonu, katman ayrımı, doğrulama hatları ve test kurulumu çerçevenin içinde geliyor. Bir NestJS projesine bakan mühendis, daha önce hiç görmemiş olsa bile denetleyicinin nerede, servisin nerede, doğrulamanın nasıl yapıldığını biliyor.

Sportez projesinde bunun karşılığını gördük: sekiz haftada mobil uygulama, backend ve yönetim paneli teslim edildi. Bu hız, mimariyi her seferinde yeniden tartışmamaktan geliyor.

Bağımlılık enjeksiyonu ayrıca test edilebilirliği ciddi kolaylaştırıyor. Servisi test ederken bağımlılıkları sahte nesnelerle değiştirmek doğal bir işlem haline geliyor, sonradan eklenen bir numara olmuyor.

Bedeli de var. Öğrenme eğrisi Express'ten dik. Dekoratörler, modüller ve sağlayıcılar ilk başta fazla soyut gelebiliyor. Küçük ve tek işlevli bir servis için gereksiz ağır kalabiliyor. Soğuk başlatma süresinin kritik olduğu sunucusuz senaryolarda başlangıç yükü hissedilir.

pnpm ve Turborepo: görünmeyen kazanç

Bu ikisi çerçeve tartışmasının gölgesinde kalıyor ama günlük işte farkı büyük.

pnpm paketleri disk üzerinde tek kopya tutup bağlantıyla paylaşıyor. Birden fazla projeyi aynı makinede çalıştıran bir ekipte bu, ciddi disk ve kurulum süresi tasarrufu demek.

Aslında daha önemli olan yan etkisi şu: pnpm'in katı bağımlılık ağacı, tanımlamadığınız bir paketi kazara kullanmanızı engelliyor. npm'de çalışan ama başka makinede kırılan "hayalet bağımlılık" sorunu ortadan kalkıyor.

Turborepo ise görevleri önbelleğe alıyor. Değişmeyen paketi yeniden derlemiyor. İçinde birkaç uygulama ve paylaşılan kütüphaneler bulunan bir depoda derleme süresi dakikalardan saniyelere iniyor.

Bu ikisi tek başına kimseyi etkilemez ama haftada onlarca kez çalışan komutlarda birikimli etkisi büyük.

Kurumsal projelerde neden .NET

Bazı projelerde Node.js tarafına hiç gitmiyoruz. Kurumsal müşterilerde çoğunlukla .NET kullanıyoruz ve sebebi teknik üstünlük iddiası değil.

Müşterinin ekosistemi. Orta ve büyük ölçekli şirketlerin bilişim altyapısı genellikle Microsoft merkezli. Active Directory ile kimlik doğrulama, mevcut SQL Server kurulumları, Azure üzerinde çalışan diğer sistemler. .NET bu ortama doğal oturuyor.

İç ekibin devralabilmesi. Müşterinin kendi bilişim ekibi zaten .NET biliyorsa, teslim sonrası sistemi sürdürmek kolay oluyor. Bize bağımlı kalmalarını istemiyoruz.

Uzun dönem destek. Kurumsal projelerin ömrü uzun. .NET'in sürüm politikası ve geriye dönük uyumluluğu, beş yıl sonra sistemi güncellemeyi öngörülebilir kılıyor.

Denetim ve uyum. Regülasyona tabi sektörlerde olgun araç zinciri ve kurumsal destek seçenekleri bir avantaj.

Bu bir dil savaşı değil. Aynı işi iki yığınla da yapabiliriz; seçimi müşterinin beş yıl sonra nerede duracağı belirliyor.

Nasıl karar veriyoruz

Pratikte şu üç soru yeterli oluyor.

Müşterinin iç ekibi hangi yığını biliyor? Teslimden sonra sistemi sürdürecek ekip Microsoft tarafındaysa .NET. Yoksa Node.js tarafı daha hızlı ilerliyor.

Proje kaç servisten oluşacak? Tek bir servis ve küçük kapsamsa Express yeterli olabilir. Birden fazla uygulama, paylaşılan kütüphaneler ve uzun ömür varsa NestJS ve monorepo.

Ekip kaç kişi ve ne kadar değişecek? Ekip büyüdükçe ve değiştikçe, çerçevenin dayattığı yapının değeri artıyor. Tek kişi çalışacaksa esneklik daha değerli olabilir.

Express'i ne zaman seçeriz

Dürüst olmak gerekirse henüz büyük bir projede seçmedik, ama geçerli olduğu durumlar var: tek uç noktalı bir webhook alıcısı, kısa ömürlü bir prototip, ya da mevcut bir Express projesine yapılan küçük bir ekleme. Bu durumlarda NestJS'in yapısı kazançtan çok yük olur.

Kritik ayrım şu: projenin ömrü. Üç ay yaşayacak bir şey için yapı kurmak israf; üç yıl yaşayacak bir şey için yapı kurmamak daha pahalı.

Yığının tamamı

Bugün tipik bir projede kullandıklarımız: backend için NestJS, paket yönetimi için pnpm, monorepo için Turborepo, veri katmanı için MongoDB, arayüz için Next.js. Kurumsal projelerde backend tarafı .NET oluyor.

Bu seçimlerin ortak noktası tek bir ilke: başka bir ekip devraldığında çalışmaya devam etsin. Teslim ettiğimiz kod tabanı müşterinin oluyor ve sadece bizim anlayabileceğimiz bir sistem bırakmak istemiyoruz.

Kendi projenizde bu kararları konuşmak isterseniz, mevcut yığınınızı ve sizi en çok yavaşlatan noktayı getirin.