NestJS GraphQL Prisma üçlüsü, 2026’da modern SaaS ürünlerinin omurgasını oluşturan en olgun TypeScript yığını haline geldi. Bu kombinasyon, tek bir kod tabanında modüler mimari, type-safe veri katmanı ve schema-driven API’yi birleştirerek MVP’den enterprise ölçeğe kadar pürüzsüz bir geçiş sağlar. Stack Overflow Developer Survey 2024 verilerine göre TypeScript profesyonel geliştiriciler arasında %65 kullanım oranıyla ilk üçte yer alıyor; aynı dönemde NestJS, GitHub’da 70 binin üzerinde yıldıza ve haftalık 4 milyonu aşkın npm indirmesine ulaştı. Prisma ise resmi vendor verilerine göre haftalık 2,5 milyon indirme ile Node.js ekosisteminin en hızlı büyüyen ORM’i konumunda. Bu yazı, NestJS + GraphQL + Prisma üzerine inşa edilen bir SaaS template’inin somut mimarisini, modül sınırlarını, multi-tenant kurgusunu, performans tuning’ini ve maliyet etkilerini sayısal verilerle ele alıyor.
Hızlı cevap: 2026’da TypeScript tabanlı bir SaaS başlatıyorsanız ve schema-first API, compile-time tip güvenliği ve modüler servis yapısı birlikte gerekiyorsa, NestJS (10.x/11.x) + Apollo Server 4 ile GraphQL + Prisma 5.x kombinasyonu, ekibinizin ilk altı haftada üretime çıkma olasılığını ciddi biçimde artırır. Aşağıdaki bölümler, template’in modül haritasını, code-first schema akışını, çoklu kiracı izolasyonunu, observability katmanını ve operasyonel maliyet kalemlerini ayrıntılandırıyor.
2026 İtibarıyla NestJS, GraphQL ve Prisma’nın Olgunluk Durumu
NestJS, Angular-esque dekoratör mimarisini Node.js dünyasına taşıyan bir framework olarak 2017’de yayımlandı; 2026’da artık 11. ana sürümünü kullanıyor ve resmi dokümantasyonu Fastify adaptörüyle Express’ten yaklaşık 2x throughput sunduğunu raporluyor. Apollo Server 4, federation v2 desteğiyle birlikte mikroservis bölünmesi gereken SaaS’lar için olgun bir referans noktası. Prisma 5, query engine’i Rust ile yazılmış, type-safe client’ı her şema değişikliğinde otomatik üretilen bir veri katmanı sağlar; resmi changelog’a göre v5 ile sorgu planlama latency’si v4’e göre yaklaşık %20 azaldı.
Bu üçlünün birlikte tercih edilme nedeni, üç temel acı noktasını aynı anda çözmesi: kontrolörden veri katmanına kadar tek dilde (TypeScript) çalışabilme, GraphQL şemasını ya kod-öncelikli ya da SDL-öncelikli oluşturabilme, ve veri tabanı erişiminde N+1 sorunlarını DataLoader entegrasyonuyla yönetebilme. NestJS resmi GraphQL dokümantasyonu ve Prisma resmi dokümantasyonu bu entegrasyonu birinci sınıf vatandaş olarak konumlandırıyor.
| Bileşen | Sürüm (2026) | Lisans | GitHub Stars | Haftalık İndirme |
|---|---|---|---|---|
| NestJS | 11.x | MIT | ~70K | ~4M |
| Apollo Server | 4.x | MIT | ~14K | ~3M |
| Prisma ORM | 5.x | Apache 2.0 | ~40K | ~2,5M |
| TypeScript | 5.4+ | Apache 2.0 | ~100K | ~60M |
| graphql-js | 16.x | MIT | ~20K | ~30M |
Tablo, ekosistemin sağlığını gösterir. Karşılaştırmalı olarak, alternatif TypeScript backend yığınları için Bun Deno Node.js 22 karşılaştırmamızı okumak, runtime seçimi için tamamlayıcıdır.
Modül Haritası: SaaS Template’in Sınırları ve Sorumlulukları
Bir SaaS template’inin değeri, hangi modülleri içerdiği kadar bu modüllerin nasıl izole edildiğindedir. NestJS’in @Module dekoratörü, bağımlılık enjeksiyonunu modül sınırıyla kapsüller; imports alanı public yüzeyi, providers ise iç implementasyonu tanımlar. Olgun bir template, en az 10-12 ana modülü açık bir biçimde ayırır ve bunların her birine kendi GraphQL resolver’ı, servis katmanı ve Prisma sorgu yardımcısı atanır.
- AuthModule: JWT (RS256) + refresh token rotation, passwordless magic link, opsiyonel WebAuthn (Passkey). FIDO Alliance 2024 raporuna göre passkey adopsiyonu Fortune 500’de %75 büyüdü.
- TenantModule: Multi-tenant izolasyon, row-level security (RLS) veya schema-per-tenant kararı.
- UserModule: Profil, davet, rol, RBAC matrisi (CASL veya custom guard).
- BillingModule: Stripe / Iyzico entegrasyonu, plan upgrade webhook’ları, prorate hesaplama.
- NotificationModule: E-mail (Postmark/SES), in-app feed, webhook outbound.
- AuditModule: Append-only log, kullanıcı eylemleri, GDPR/KVKK uyum kaydı.
- FileModule: S3 presigned URL, antivirus tarama hook’u, EXIF temizleme.
- SearchModule: PostgreSQL tsvector ya da Meilisearch/OpenSearch entegrasyonu.
- HealthModule:
/healthz,/readyz, Prisma ping + Redis ping. - ConfigModule: Zod ile env validasyon, 12-factor uyum, secret rotation desteği.
Modüller arası iletişimde doğrudan service-to-service import yerine event-driven yaklaşım (NestJS EventEmitter2 veya BullMQ kuyruğu) tercih edilirse, modüller arası coupling minimumda kalır. Bu pratik, ilerde mikroservis bölünmesi gerektiğinde refactor maliyetini yaklaşık %40 düşürür. Konuyla ilgili yapısal yaklaşımı derinleştirmek için yazılım tasarım desenleri pratik rehberini ve SOLID prensipleri uygulama yazımızı öneririm.
GraphQL Schema Stratejisi: Code-First mi SDL-First mi?
NestJS, GraphQL şemasını iki yolla üretir: code-first (TypeScript sınıfları + dekoratörler → otomatik .gql) ve schema-first (önce SDL, sonra resolver). SaaS template’lerinde code-first yaklaşım, tipleri tek kaynaktan üretmesi (DRY) nedeniyle daha sık tercih edilir. Apollo Studio 2024 raporuna göre, mevcut Apollo Server 4 üretim kullanıcılarının yaklaşık %62’si NestJS ya da Type-GraphQL ile code-first çalışıyor.
| Kriter | Code-First | SDL-First |
|---|---|---|
| Tek Kaynak (DRY) | Evet, TypeScript class | Hayır, SDL + DTO ayrı |
| Tip Güvenliği | Compile-time tam | Codegen ile elde edilir |
| Frontend Ekibiyle Paylaşım | SDL otomatik üretilir | SDL elle kontrol edilir |
| Federation v2 Uyumu | Olgun (NestJS adapter) | Olgun (Apollo Rover) |
| Öğrenme Eğrisi | NestJS bilen için düşük | GraphQL bilen için düşük |
| Schema Lint | graphql-eslint ile sınırlı | graphql-eslint ile tam |
Code-first yaklaşımda @ObjectType(), @Field(), @InputType(), @Args() dekoratörleri ile resolver imzaları TypeScript tarafından doğrulanır. SDL üretimi autoSchemaFile ayarıyla otomatik yapılır; CI pipeline’ında graphql-inspector diff komutu ile schema breaking change’ler engellenir. Bu süreç, statik tip kontrolünü tamamlayan bir kalite kapısı oluşturur; konuyu tip ipuçları yazımızla karşılaştırmalı okumak, dil ötesi pratikleri netleştirir.
Prisma ile Veri Katmanı: Şema, Migration ve Performans
Prisma 5’in schema.prisma dosyası, hem veri tabanı şemasını hem de TypeScript client’ını tek deklaratif kaynak halinde tutar. prisma migrate dev ile geliştirme migration’ları, prisma migrate deploy ile prod migration’ları çalıştırılır; CI/CD’de bu adımın idempotent olması kritik. Prisma’nın resmi performans benchmark’ları, basit findUnique sorgularında PostgreSQL üzerinde p99 ~5-10 ms gecikme bildiriyor; bu rakam, eşdeğer raw SQL’in yaklaşık 1,3 katı, ancak tip güvenliği avantajı düşünüldüğünde kabul edilebilir.
| Operasyon | Prisma p50 | Prisma p99 | Raw SQL p50 | Raw SQL p99 |
|---|---|---|---|---|
| findUnique (PK) | ~1,5 ms | ~8 ms | ~1,1 ms | ~6 ms |
| findMany (1K row) | ~12 ms | ~35 ms | ~9 ms | ~28 ms |
| create | ~3 ms | ~14 ms | ~2,5 ms | ~11 ms |
| nested include (3 level) | ~18 ms | ~55 ms | ~13 ms | ~42 ms |
| transaction (4 op) | ~22 ms | ~70 ms | ~18 ms | ~58 ms |
Yukarıdaki rakamlar, Prisma resmi blog yazıları ve community benchmark’larından derlenen yaklaşık değerlerdir; gerçek ortamda PostgreSQL sürümü, connection pool, hardware ve indeks stratejisine göre farklılaşır. N+1 problemini önlemek için @graphql/dataloader ile resolver başına batch loader tanımlanmalı; Prisma’nın native batching özelliği DataLoader’a entegre edilebilir. Apollo Server data-fetching dokümantasyonu bu konuda referans niteliğindedir.
Multi-Tenant Stratejisi: İzolasyon, Performans ve Maliyet Dengesi
SaaS template’i ister tek-müşteri ister binlerce müşteri ile çalışsın, multi-tenant izolasyon stratejisi mimari karar olarak en kritik konulardan biridir. AWS SaaS Factory beyaz kağıdına göre, üç ana izolasyon modeli sahada kullanılıyor: silo (her tenant için ayrı veri tabanı), bridge (paylaşılan veri tabanı, şema-per-tenant) ve pool (paylaşılan veri tabanı, satır seviyesi izolasyon). Her birinin maliyet ve operasyonel sonuçları farklıdır.
| Model | İzolasyon | Aylık Maliyet (100 tenant) | Operasyonel Yük | Compliance |
|---|---|---|---|---|
| Silo (DB-per-tenant) | Çok Yüksek | ~3.000-6.000 USD | Yüksek | Tam (HIPAA, KVKK) |
| Bridge (Schema-per-tenant) | Yüksek | ~600-1.200 USD | Orta | Çoğu standarda uyumlu |
| Pool (Row-level) | Orta | ~150-400 USD | Düşük | RLS ile sağlanabilir |
| Hibrit (Enterprise → Silo) | Yüksek/Orta | ~800-2.500 USD | Orta-Yüksek | Esnek |
Olgun bir template, başlangıçta pool modelinde başlar; enterprise plana geçen müşteriler için silo‘ya promote eder. Prisma’da pool modeli için her sorguya where: { tenantId } filtresi otomatik enjekte edilmeli (Prisma middleware veya $extends). PostgreSQL Row-Level Security politikası ek savunma hattı olarak SET app.tenant_id ile birlikte kullanılır. PostgreSQL RLS resmi dokümantasyonu bu konuda kanonik kaynaktır.
- Avantaj (Pool): Tek migration, tek bağlantı havuzu, çok düşük operasyonel maliyet.
- Dezavantaj (Pool): Yanlış filtre = veri sızıntısı, gürültülü komşu sorunu.
- Ne zaman seç (Pool): 100-10.000 tenant, hepsi benzer payload, regülasyon “data residency” gerektirmiyor.
- Avantaj (Silo): Tam izolasyon, “noisy neighbor” yok, kolay backup-restore.
- Dezavantaj (Silo): Migration N kez, bağlantı havuzu N katı, sabit maliyet.
- Ne zaman seç (Silo): Enterprise tier, healthcare/finance, ülke bazlı veri yerelleştirme.
Performans: Apollo Cache, DataLoader ve Query Complexity
GraphQL’in en sık eleştirilen yönü, kötü tasarlanmış sorguların veri tabanını çökertebilmesidir. Olgun bir SaaS template’i, üç katmanlı bir koruma uygular: persisted queries (yalnız beyaz listedeki hash’li sorgular geçer), query complexity limit (graphql-query-complexity ile maks 1000 puan), ve depth limit (graphql-depth-limit ile maks 7 derinlik). Bu üç önlem, denial-of-wallet saldırılarını engelleyen temel hattı oluşturur.
| Önlem | Etki | Latency Maliyeti | Önerilen Eşik |
|---|---|---|---|
| Persisted Queries | Beyaz liste dışı sorgu reddedilir | +0,2 ms (hash lookup) | Tüm production trafiği |
| Query Complexity | Pahalı sorgular reddedilir | +0,5 ms (AST analizi) | ~1000 puan |
| Query Depth Limit | Sonsuz nested sorgu yok | +0,1 ms | 7 seviye |
| Rate Limiting (per IP) | Burst koruması | +0,3 ms (Redis token bucket) | 60 RPM / 600 RPH |
| DataLoader (N+1) | 1 query → batched | -15 ila -80 ms | Tüm relation alanları |
| Apollo Response Cache | Aynı sorgu için cache hit | -95% latency | Public/read-only alanlar |
Apollo Server 4’ün @apollo/server-plugin-response-cache eklentisi, alan-seviyesi cache hint’leriyle çalışır; her @ObjectType() üzerine @CacheControl({ maxAge: 60 }) yerleştirildiğinde, Apollo response’u Redis’te saklar. CDN düzeyinde de aynı header’lar geçerlidir; Cloudflare Workers ya da Fastly üzerinde GraphQL cache koymak, p99’u %60-90 aralığında düşürebilir. Performans yaklaşımını dil bazında karşılaştırmak için Go yüksek performanslı backend yazısını ve Java 21 virtual threads yazısını okumak faydalıdır.
Authentication, Authorization ve RBAC: Production-Grade Yapı
Modern SaaS’ta auth katmanı üç problemi aynı anda çözmeli: kim olduğunu kanıtla (authn), ne yapabileceğini belirle (authz), ve bunu denetlenebilir tut (audit). NestJS template’i için önerilen pattern, Passport.js ile JWT strateji + refresh token rotation, CASL ile policy-based authorization, ve nestjs-pino ile structured logging birleşimidir. JWT’lerin RS256 (asimetrik) imzalanması, dış mikroservislerin sadece public key ile doğrulama yapmasına izin verir.
- Magic Link / Passkey: Şifresiz girişle “credential stuffing” saldırı yüzeyi neredeyse sıfıra iner; ENISA Threat Landscape 2024 raporu, parola tabanlı saldırıların hâlâ ihlal vektörlerinin %35-40’ını oluşturduğunu söylüyor.
- Refresh Token Rotation: Her refresh işleminde yeni token üretilir, eski token “reuse detection” ile blacklist’e gider.
- Short-lived Access Token: 15 dakika TTL, refresh 30 gün; kayıp token penceresi 15 dakika ile sınırlanır.
- RBAC + ABAC karması: Rol (admin/member/viewer) + attribute (resource.ownerId == user.id) kombine değerlendirilir.
- Step-up Auth: Hassas işlemler (faturalama, kullanıcı silme) için MFA prompt zorunlu.
- Audit Log: Append-only, hash chain ile tamper-evidence (NIST SP 800-92 öneriler).
CASL’ın policy fonksiyonları, GraphQL resolver guard’larında @UseGuards(PoliciesGuard) ile bağlanır; bu kalıbın faydası, izin kurallarını dağıtık if bloklarından merkezi bir politika dosyasına taşımasıdır. Ekibin bu yapıyı sürdürülebilir kılması için TDD pratiği yazımız politika testlerini güvence altına almak için faydalıdır.
Observability: OpenTelemetry, Loglama ve SLO Metrikleri
2026’da observability, opsiyonel bir lüks değil baseline gereksinimdir. NestJS template’i, OpenTelemetry SDK ile HttpInstrumentation, GraphQLInstrumentation, ve PrismaInstrumentation‘u açar; trace verisi OTLP üzerinden Grafana Tempo, Jaeger ya da managed bir backend’e (Honeycomb, Datadog, New Relic) gönderilir. Logging için nestjs-pino JSON structured log üretir; her log satırında traceId, spanId, tenantId, userId alanları zorunludur.
| Metrik | SLO Hedefi | Ölçüm Aracı | Alert Eşiği |
|---|---|---|---|
| GraphQL p99 latency | < 400 ms | OpenTelemetry histogram | > 800 ms 5 dk |
| Error rate (5xx) | < %0,1 | Prometheus counter | > %1 burst |
| Availability | %99,9 aylık | External synthetic check | 3 ardışık fail |
| DB connection pool | < %80 kullanım | Prisma metrics | > %90 5 dk |
| Cache hit ratio | > %70 (Apollo response) | Redis INFO | < %50 30 dk |
| Queue depth (BullMQ) | < 1000 job | BullMQ metrics | > 5000 5 dk |
OpenTelemetry resmi JavaScript dokümantasyonu NestJS entegrasyonunu adım adım anlatır. SRE ekibinin “error budget” politikasını uygulayabilmesi için bu metriklerin alarm yapısı PagerDuty/Opsgenie ile entegre edilmelidir. Maliyet tarafında, telemetry pipeline’ı için aylık 100-300 USD bütçe ayırmak, küçük-orta ölçekli bir SaaS için makul bir başlangıç noktasıdır.
Deployment, CI/CD ve Maliyet: Kubernetes mi Serverless mi?
Template’in deployment hedef alanı, ekibin operasyonel olgunluğuna bağlıdır. İki yaygın yol vardır: Kubernetes (EKS/GKE/AKS) + Helm chart ya da serverless (AWS Lambda + API Gateway, Cloud Run, Vercel Functions). NestJS, her iki dağıtım modeline de uyumludur; NestFactory.createApplicationContext ile cold-start optimizasyonu yapılabilir. Prisma’nın serverless ortamlarda data proxy ya da yeni Accelerate ürünüyle kullanılması, connection pooling sorununu çözer.
| Strateji | Aylık Min. Maliyet | Cold Start | Operasyonel Yük | Önerilen Aşama |
|---|---|---|---|---|
| Cloud Run / Fly.io | ~50-150 USD | ~200-800 ms | Çok düşük | MVP ve seed |
| AWS Lambda + API GW | ~30-200 USD | ~300-1200 ms | Düşük | Burst trafik, B2C |
| ECS Fargate | ~200-500 USD | Yok (always-on) | Orta | Series A |
| Kubernetes (EKS/GKE) | ~400-1.500 USD | Yok | Yüksek | Series B+ veya 10K+ kullanıcı |
| Self-managed VM | ~30-100 USD | Yok | Yüksek (manuel) | Bootstrapped, küçük ekip |
CI/CD pipeline’ı için tipik adımlar: lint → test (Jest + Supertest) → build (Docker multi-stage) → image scan (Trivy) → schema diff (graphql-inspector) → Prisma migrate dry-run → canary deploy → smoke test → tam dağıtım. GitHub Actions resmi dokümantasyonu bu pipeline’ı YAML olarak tanımlamak için en yaygın platform; alternatifi GitLab CI ya da Buildkite. MVP’den production’a geçiş hızlandırma stratejileri için MVP geliştirme rehberini okumanızı öneririm.
SSS: NestJS + GraphQL + Prisma SaaS Template Hakkında
NestJS + GraphQL + Prisma stack’i hangi ölçekte iyi çalışır?
Bu kombinasyon, MVP’den orta ölçekli SaaS’a (örneğin 100.000 aylık aktif kullanıcı, 10-50 milyon GraphQL isteği) kadar son derece üretkendir. Daha büyük ölçekte (100M+ istek) GraphQL Federation v2 ile servis bölünmesi ya da kritik path’lerin gRPC ile yeniden yazılması düşünülmelidir; Prisma çoğu durumda yetersiz değil, ekip operasyonel olgunluğu darboğaz olur.
Prisma kullanmak vendor lock-in oluşturur mu?
Prisma açık kaynak (Apache 2.0) ve şema standart bir DSL. Ancak $queryRaw dışı tüm sorgular Prisma client API’sine bağlıdır. Migration dosyaları standart SQL olduğundan, Prisma’dan ayrılmak istediğinizde şema kayıp olmaz; ancak uygulama kodundaki binlerce satır client çağrısı refactor gerektirir. Bu yüzden veri erişim katmanını bir repository arkasında soyutlamak akıllıca olur.
GraphQL yerine tRPC daha mı uygundur?
tRPC, frontend ve backend’in aynı monorepo’da olduğu, public/third-party tüketici olmayan TypeScript-only ekipler için harika bir alternatiftir. Ancak GraphQL, çoklu istemci (web + iOS + Android + partner API), federation, ve şema versiyonlama gibi gereksinimlerde belirgin biçimde önde. SaaS ürünü dış geliştiricilere API açacaksa GraphQL daha güvenli bir seçimdir.
Multi-tenant izolasyonda RLS yeterli mi yoksa schema-per-tenant şart mı?
Çoğu B2B SaaS için PostgreSQL row-level security + uygulama seviyesinde tenant filtresi yeterli savunma katmanı sağlar; yanlış yazılmış bir kuyruktan veri sızması bile RLS politikasıyla engellenir. Sağlık, finans, savunma gibi regülasyonlu sektörlerde ya da müşteri kontrat olarak izolasyon talep ediyorsa schema-per-tenant ya da silo modeline geçmek gerekir.
Bu stack ile ilk üretim dağıtımı kaç haftada gerçekçi?
İyi yapılandırılmış bir template ile, 2-3 kişilik bir ekibin temel auth, billing, multi-tenant ve admin paneliyle birlikte üretime çıkması 4-6 hafta arasındadır. Stack’i sıfırdan toparlamak yerine kanıtlanmış bir template kullanmak, 200-400 saatlik repetitive iskelet işini ortadan kaldırır; bu da yaklaşık 8.000-16.000 USD geliştirici saatine karşılık gelir.
Sonuç: 2026’da NestJS + GraphQL + Prisma Yığını Kime, Ne Zaman Önerilir?
NestJS + GraphQL + Prisma kombinasyonu, 2026’da TypeScript ekosistemindeki en olgun “batteries-included” SaaS template’i konumundadır. Bu yığını seçmek için kritik üç koşul vardır: ekibin TypeScript’i ana dil olarak benimsemiş olması, ürünün GraphQL’i hak edecek kadar çoklu istemciye veya esnek query gereksinimine sahip olması, ve veri katmanında tip güvenliğinin (raw SQL hızından önemli) öncelik olması. Bu üç koşul karşılanıyorsa, alternatif yığınlara kıyasla 6-12 aylık geliştirme süresinde %25-40 verimlilik kazanımı görmek olağandır.
Karar çerçevesi olarak: MVP aşaması ve TypeScript-only ekip için bu template ideal; çok büyük ölçek ve düşük latency zorunluluğu olan durumda Go veya Rust tabanlı bir servis bölünmesi düşünmek gerekir; backend’i tek dilde tutmak istemeyen ekipler için ise Python tabanlı bir alternatife Python Backend (FastAPI vs Django) yazımız üzerinden bakılabilir. Stack seçimi kadar template’in iç tutarlılığı, lint kuralları, test kapsamı ve dokümantasyonu da uzun vadeli sürdürülebilirliği belirler; bu konular için kod kalitesi metrikleri rehberini kaynak olarak öneririm.
Ekibinizin elinde uygulamayı taşıyan bir legacy backend varsa ve modern bir SaaS template’ine geçişi planlıyorsanız, hem mimari adımları hem de geçiş riskini birlikte değerlendiren bir danışmanlık süreci hızlandırıcı olabilir. Bu konuda doğrudan deneyim paylaşımı veya proje değerlendirmesi için iletişim sayfası üzerinden bana (Ömer Önal) ulaşabilirsiniz; ihtiyaca göre yığın seçimi, template kurgusu ve operasyonel maliyet modellemesi konusunda yapılandırılmış bir oturum planlayabiliriz.
Ömer ÖNAL
Mayıs 16, 2026Yazılım geliştirme projelerinde sıkça gözlemlediğim: kod kalitesi metrikleri (cyclomatic complexity, test coverage) baseline’ı belirlenmeden refactoring kararı veriliyor. Bu yaklaşım %40’ı aşan rework oranıyla sonuçlanıyor. Static analysis araçlarını CI pipeline’a entegre etmek ilk adım. Yorumlarınız?