C6 · Java ↔ Express Karşılaştırma: Aynı `/api/v1/bugs` restoranını iki farklı ekiple kurmak gibiydi: Spring Boot ekibi **hazır bir brigade sistemiyle** geldi (her aşçının rolü an
Aynı `/api/v1/bugs` restoranını iki farklı ekiple kurmak gibiydi: Spring Boot ekibi **hazır bir brigade sistemiyle** geldi (her aşçının rolü annotation ile önceden atanmış — starter, `@Valid`, `@RestControllerAdvice`); Express ekibi ise **serbest çalışan bir şef** gibiydi — hiçbir kural dayatılmadı, her adımı (middleware sırası, validation kütüphanesi, hata yakalayıcı) sen elle kurdun. Peki bu "özgürlük" gerçekten bir avantaj mı? Küçük, hızlı prototipler için EVET — az kod, az karar; ama C3-C5'te gördüğün gibi (middleware sırası, validation sonucu okuma, hata yakalayıcı konumu) her "elle kurulan" adım aynı zamanda bir "elle unutulabilecek" adımdır — Spring'de framework SENİN yerine hatırlar, Express'te SEN hatırlarsın. Bu, "hangisi daha iyi" sorusu değil, **"hangi hatanın senin sorumluluğunda olduğu"** sorusudur — ve bir tester için bu, "bu framework'te hangi sessiz hata SIK görülür" sorusuna dönüşür: Spring'de eksik annotation/dependency, Express'te yanlış SIRA.
Üç Framework, Aynı Sözleşme
🎬 Üç Mutfak, Aynı Menü
Spring: @Valid otomatik
Express: elle sıralı zincir
Nest: decorator + pipe
Aynı JSON sözleşmesi
Aynı `POST /api/v1/bugs { "title": "" }` request'i üç farklı sunucuya gönderiliyor.
Spring: `@Valid` framework tarafından otomatik tetiklenir, 400 döner — geliştirici ekstra kod yazmaz.
Nest: `ValidationPipe` global olarak KAYITLIYSA DTO decorator'ları otomatik çalışır — kayıtlı değilse decorator'lar süstür.
Ders — Üçü de AYNI sözleşmeyi (400 + hata mesajı) hedefler, ama "otomatik mi, elle mi" ekseni farklıdır. Tester her framework'te "bu güvenlik gerçekten TETİKLENİYOR mu?" diye sorar.