NestJS Mimarisi: Headers ve Query Parametreleri Okuma (9. Bölüm)


HTTP İsteği Sadece Body’den İbaret Değil API’ye gelen her istek 3 temel veri kaynağı taşır: Body -> İçerik, payload Query -> Filtre, arama, sayfalama gibi şeyler Headers -> Kimlik, token, dil bilgisi, içerik türü Ve bunların her biri farklı ihtiyaçlara hizmet eder. NestJS bu üçüne de ayrı dekoratörler sunar. Bu bölümde @Query() ve @Headers() üzerinde duracağız. @Query() - Sorgu Parametrelerini Okumak Örnek URL: GET /products?page=2&limit=10&sort=price Bu URL’deki page, limit ve sort kısmı query parametresidir.…
Read more ⟶

NestJS Mimarisi: Route Wildcard ve Prefixler (10. Bölüm)


Rota Yönetiminde Bir Seviye Yukarı: Wildcard ve Prefix Kullanımı Normalde rotaları şöyle tanımlarız: @Controller('users') export class UserController { @Get() getAll() { ... } @Get(':id') getById(@Param('id') id: string) { ... } } Ama bazı durumlarda daha esnek tanımlamalar gerekebilir: Tüm istekleri karşılayan bir “catch-all” route Belirli bir grup route’a ön ek tanımlama Statik dosyalar, client-side SPA fallback gibi durumlar İşte burada wildcard ve prefix kavramları devreye giriyor. 1. Route Prefix Nedir? Prefix, bir grup route’un başına otomatik olarak eklenen ortak path’tir.…
Read more ⟶

NestJS Mimarisi: Provider Nedir? Ne Sağlar? (11. Bölüm)


NestJS’te Her Şey Bir Provider’dır NestJS’te controller, service, guard, pipe, hatta resolver… Bunların hepsi özünde birer provider’dır. Provider = Nest container’ına tanıtılan ve başka yerlerden inject edilebilen bir “şey”dir. Sen bir service yazarsın, onu @Injectable() yaparsın - bu, Nest’e şunu demektir: “Bunu bir yerde kullanmak isteyeceğim, lütfen enjekte edilebilir hale getir.” En Temel Kullanım: Servis Olarak Provider @Injectable() export class UserService { findAll() { return ['Ali', 'Ayşe']; } } Bu sınıf bir provider olur.…
Read more ⟶

NestJS Mimarisi: Service Oluşturma ve Kullanma (12. Bölüm)


Controller İş Yapar, Service İşletir NestJS mimarisinde Controller, dış dünyayla konuşan yerdir. Ama işin mantığı, hesaplama, veri işleme gibi şeyler Service içinde olmalıdır. Controller = sekreter. Çağrıyı alır, ilgili departmana yönlendirir. Service = departman. Gerçek işi yapar. Eğer her şeyi controller içinde yaparsan: Test yazmak zorlaşır Kod tekrar eder Modülerlik kaybolur API karmaşıklaşır Service Tanımlamak: En Temel Hali @Injectable() export class UserService { private users = ['Ayşe', 'Fatma', 'Hayriye']; findAll() { return this.…
Read more ⟶

NestJS Mimarisi: Business Logic Katmanı Olarak Servisler (13. Bölüm)


“Business Logic” Ne Demek? Kodda her şey teknik olmak zorunda değil. Bir de işin iş tarafı (business) var. Kullanıcı kayıt olurken e-posta eşsiz olmalı Bir ürün stoğu sıfırsa sepete eklenememeli Hafta sonu sipariş geçersiz sayılmalı Bunlar framework’le değil, iş modeliyle ilgili kurallardır. Ve işte bunlara business logic denir. Peki Bu Kurallar Nereye Yazılır? Controller’a yazarsan: Kodun şişer. Test yazmak eziyet olur. Entity’ye yazarsan: Veritabanına fazla sorumluluk yüklersin. Pipe’a yazarsan: Genellikle sadece doğrulama yapılır.…
Read more ⟶

NestJS Mimarisi: Value, Class ve Factory Providers (14. Bölüm)


Provider Ne Demekti? NestJS’de bir class veya değer, “provider” olarak tanımlanırsa constructor() içinde @Inject() ile enjekte edilebilir. Yani dependency injection sistemine kayıtlı olur. Ama bu provider illa bir class olmak zorunda değil. İşte tam burada 3 farklı yol devreye giriyor: Tür Ne Sağlar? Ne Zaman Kullanılır? Value Provider Sabit bir değer (obj, string, sayı) Config, sabit ayarlar, env verileri Class Provider Alternatif class tanımı Mock servis, farklı implementasyonlar Factory Provider Fonksiyonla üretilen provider Dinamik yapı, config’e bağlı servis üretimi 1.…
Read more ⟶

NestJS Mimarisi: Provider Scope (15. Bölüm)


Bir Servis, Herkes İçin Aynı mıdır? NestJS’te @Injectable() bir sınıf tanımladığında, varsayılan olarak bu servis singleton olur: Tüm uygulama boyunca sadece 1 kez oluşturulur ve herkes aynı örneği kullanır. Ama bu her zaman ideal değildir. Bazı durumlarda: Her HTTP isteği için yeni bir örnek gerekebilir (örneğin kullanıcıya özel veri taşımak) Her dependency injection noktası farklı bir örnek almalıdır İşte burada scope kavramı devreye girer. 3 Temel Scope Türü Scope Yaşam Süresi Kullanım Senaryosu SINGLETON Tüm uygulama boyunca 1 örnek Varsayılan, çoğu servis bu olur REQUEST Her HTTP isteği için yeni Kullanıcıya özel veri tutan servisler TRANSIENT Her kullanımda yeni örnek Paylaşılmaması gereken servisler (stateless) 1.…
Read more ⟶