GraphQL Facebook’un 2015’te açık kaynak yaptığı query language. Son 10 yıldır “modern API’lerin geleceği” diye pazarlanıyor. Çoğu developer’ın portfolio’sunda “GraphQL experience” var. Ama gerçek production’da çoğu API hâlâ REST.
Benim kullanım dağılımım: 20+ API projesi arasında sadece 2’si GraphQL’de kurguladım. 18’inde REST optimal oldu. Bu yazıda hangi durumda GraphQL’in gerçekten kazandığını anlatacağım.
GraphQL gerçekten kazandığı senaryolar
1. Client’ın ihtiyaçları değişken ve önceden bilinmiyorsa.
Mobile app’in farklı ekranları var. Profil ekranında user name, avatar. Listing ekranında user name, avatar, post count. Detail ekranında hepsi + last 5 post.
REST ile her ekran için ayrı endpoint yazıyorsun. Veya over-fetching yapıyorsun (her ekrana tüm user data dönüyorsun, client ihtiyaç olanı seçiyor).
GraphQL ile client istediği field’ları seçiyor, tek endpoint. Bir yeni ekran ekleyince backend değişmeden client başka field’ları da isteyebilir.
Gerçek örnek: Facebook’un news feed’i. Binlerce view varyantı, her biri farklı data kombinasyonu istiyor. REST ile deaths-by-endpoint olur.
2. Multiple data source’tan aggregation.
Backend’de 3 farklı servis var: user service, post service, comment service. Client bir post için author info + son 5 comment istiyor. REST ile 3 round trip.
GraphQL ile tek query:
query {
post(id: 123) {
content
author { name avatar }
comments(last: 5) { text author { name } }
}
}GraphQL server 3 servisi aggregate ediyor, client’a tek response dönüyor.
3. Rapid prototyping / iterative development.
Startup aşamasında ürün değişiyor. Her sprint yeni data requirement’ları. REST’te her yeni endpoint için backend change + deploy. GraphQL’de schema’ya field ekle, çalışıyor.
Bu early stage’de hız kazandırıyor. Ürün stabilize oldukça REST ile performans optimize edilebilir.
4. Complex nested data.
5-6 seviye nested data’n varsa (user → posts → comments → replies → reactions), REST’te bunu serve etmek N+1 query cehennemi. GraphQL DataLoader pattern’iyle bunu çözüyor.
GraphQL’in işe yaramadığı 6 senaryo
1. Basit CRUD API’leri.
Bir admin panel, bir blog, bir dashboard. Data structure stable, query’ler tekrar eden. REST yeterli ve daha basit.
2. File upload / streaming.
GraphQL’de file upload multipart extension ile yapılıyor ama standart değil. File download streaming için REST daha doğal. Media-heavy API’lerde REST.
3. Caching critical.
REST GET endpoint’leri HTTP-level caching (ETag, Cache-Control) kullanıyor. CDN’e koyabiliyorsun, browser cache çalışıyor. GraphQL genelde POST kullandığı için bu mekanizma yok. Cache ayrı bir layer (Apollo Cache, Relay Cache) olarak kurulmak zorunda.
4. Microservice internal iletişim.
Servisler arası iletişim için gRPC veya REST daha iyi. GraphQL extra overhead ekliyor (schema definition, resolver). Internal API’da bunlar değer katmıyor.
5. Public API / third-party consumer’lar.
Stripe, Twilio gibi public API’ler REST. Sebep: öğrenme eğrisi düşük, tool ecosystem geniş, OpenAPI/Swagger documentation mature. GraphQL public API’si developer’lara daha yüksek entry bar’ı.
6. Küçük ekip, sınırlı kaynak.
GraphQL stack (Apollo Server, Relay, tooling) öğrenmek zaman alıyor. 2-3 kişilik ekip için REST’in öğrenme ve bakım maliyeti çok daha düşük.
Production karmaşıklığı: authorization
GraphQL’in sessizce zor olan kısmı: authorization.
REST’te bir endpoint’in authorization kuralı net: “POST /api/admin/delete kullanıcıya admin rolü gerektirir”. Middleware’de bir check, tamamlandı.
GraphQL’de bir query şunu isteyebilir:
query {
user(id: 123) {
name # herkes görebilir
email # sadece kendin görebilirsin
internalNotes # sadece admin görebilir
}
}Her field için ayrı authorization kuralı. Resolver-level authorization gerekiyor. Bu kolay error-prone. Bir field’ı unuturursan security hole.
Fix: schema-aware authorization library’ler (Apollo’nun @auth directive’i, vs). Ama bu ek complexity.
N+1 query problemi
GraphQL’in meşhur performance trap’i. Nested query’de her item için ayrı DB call.
query {
posts { # 1 query (10 post döner)
title
author { name } # her post için 1 query = 10 query
}
}Toplam 11 query. Post sayısı artınca database patlıyor.
Çözüm: DataLoader pattern. Author resolver batch’leniyor, tek bir “WHERE id IN (…)” query yapılıyor.
Apollo DataLoader framework’ü bunu otomatize ediyor ama kodun disiplinli yazılması gerekiyor. REST’te N+1 problemini yaşamazsın çünkü ekibe tek endpoint’i optimize etmek yeterli.
Rate limiting karmaşıklığı
REST’te rate limiting net: “dakikada max 100 istek”.
GraphQL’de tek bir request içinde ne kadar kompleksite olabilir? Complexity scoring gerekiyor:
user(id: 123) {
posts(first: 100) { # complexity: 100
comments(first: 50) { # complexity: 100 * 50 = 5000
...
}
}
}Bu tek request 5100 “complexity point” tüketiyor. Public GraphQL API’lerinde complexity-based rate limiting şart.
GitHub’ın GraphQL API’si bunun model: “dakikada 5000 point, her query complexity’e göre point tüketiyor”.
Tooling farkı
REST için araç setleri muazzam olgun: OpenAPI/Swagger documentation, Postman, Insomnia, curl, HTTPie. Herkes biliyor, herkes kullanıyor.
GraphQL için de tool’lar iyi (GraphQL Playground, Apollo DevTools, Hasura) ama öğrenme eğrisi var.
Migration sürecinin zorluğu
Mevcut REST API’yi GraphQL’e migrate etmek kolay değil. Eski client’lar REST bekliyor, yeni client’lar GraphQL istiyor. İki paralel stack.
Hybrid yaklaşım: önemli client için GraphQL endpoint, geri kalan REST kalıyor. Ama bu maintenance yükünü iki katına çıkarıyor.
Karar matrisim
Yeni API projesinde GraphQL vs REST karar verirken:
| Faktör | GraphQL | REST |
|——–|———|——|
| Public third-party API | – | ✓ |
| Internal microservice comm | – | ✓ |
| Mobile app, çeşitli ekranlar | ✓ | – |
| Basit CRUD | – | ✓ |
| Admin panel | – | ✓ |
| Multiple data source aggregation | ✓ | – |
| Küçük ekip | – | ✓ |
| File upload heavy | – | ✓ |
| Prototype, requirement değişken | ✓ | – |
| Strong HTTP caching gereksinim | – | ✓ |
| Real-time (subscription) | ✓ | – |
Çoğu proje sağ kolon ağır basıyor.
Sonuç
GraphQL belirli senaryolarda güçlü bir araç: mobile-first, çeşitli ekran, multiple data source, rapid iteration. Ama default seçim olmamalı.
REST basit, olgun, geniş tooling’li, herkes biliyor. Çoğu API için doğru araç. GraphQL’e geçiş kararı gerçek bir problem çözmekle kanıtlanmalı, moda takip etmekle değil.
2 projede GraphQL kullandım: ikisi de büyük scale mobile app’ler çeşitli ekran ihtiyaçlarıyla. Diğer 18 projede REST doğru seçimdi. Senin projen hangi kategoride?