The results are in for the rebuilt LLM gateway, and the performance gains over the naive HuggingFace baseline (using the same Qwen 2.5 7B model) are massive.

Here are the actual benchmark numbers:
- 4.91× faster end-to-end at $c=4$ (with a 100% success rate on both sides)
- ⁠5.66× higher throughput thanks to vLLM continuous batching
- ⁠92% HTTP 429s at $c=16$—proving the rate limiter is working exactly as intended, not failing
- ⁠2 silent bugs caught mid-run (a CPU baseline issue and a SHA mismatch)

Version 0.2.0 is still in progress, but this benchmark pass proves the architecture is solid. Next up: overhead profiling and a deep dive into that "5ms budget."

Full write-up here: https://orhunkupeli.hashnode.dev/the-numbers-benchmarking-my-llm-gateway-on-a-h100

The Numbers: Benchmarking My LLM Gateway on a H100

Web dünyasında uygulamalar arasında veri alışverişi giderek daha önemli hale gelmiştir. Bu noktada REST API'ler, sistemler arası iletişimin temel yapı taşlarından biri olmuştur. Peki REST API nedir ve nasıl geliştirilir?

## REST API Nedir?

REST (Representational State Transfer), HTTP protokolü üzerinden istemci-sunucu arasında haberleşmeyi sağlayan bir yazılım mimari tarzıdır. RESTful API ise bu mimariye uygun geliştirilen arayüzlerdir. REST’in temel prensipleri şunlardır:

- **İstemci-Sunucu Ayrımı (Client-Server)**: Arayüz ile veri sağlayıcı katmanlar birbirinden ayrıdır.
- **Stateless**: Her istek birbirinden bağımsızdır; sunucu istemci hakkında hiçbir durum bilgisi tutmaz.
- **Cachelenebilirlik**: Cevaplar cachelenebilir olmalıdır.
- **Katmanlı Sistem**: API birden çok katmandan oluşabilir, örneğin proxy veya load balancer gibi.
- **İşlevsel Arayüz (Uniform Interface)**: Tüm kaynaklara erişim yolu standart olmalıdır.

## HTTP Methodları ve Kaynak Tasarımı

REST API’lerde temel HTTP methodları aşağıdaki gibidir:

- GET: Veri okuma
- POST: Yeni veri oluşturma
- PUT: Mevcut veriyi tamamen güncelleme
- PATCH: Mevcut veriyi kısmen güncelleme
- DELETE: Veri silme

Örnek bir kaynak URL’si:

```
GET /api/v1/users
POST /api/v1/users
GET /api/v1/users/42
PUT /api/v1/users/42
DELETE /api/v1/users/42
```

## JSON: Tercih Edilen Veri Formatı

REST API'lerde en yaygın kullanılan veri formatı JSON’dur. Hafif ve okunabilir yapısı ile hem istemci hem de sunucu tarafından kolaylıkla işlenebilir. Tipik bir JSON cevabı şu şekilde olabilir:

```json
{
  "id": 42,
  "name": "Mehmet",
  "email": "mehmet@example.com"
}
```

## REST API Nasıl Geliştirilir?

Bir REST API geliştirmek istiyorsanız aşağıdaki adımları izleyebilirsiniz:

### 1. İhtiyaç Analizi ve Kaynakların Belirlenmesi

Öncelikle API’nizin hangi kaynaklara (users, products, orders vb.) hizmet edeceğini belirlemeniz gerekir. Her kaynak bir veri kümesini temsil eder.

### 2. URL Tasarımı ve Versiyonlama

REST API'lerde anlaşılır, hiyerarşik ve sade URL’ler tercih edilmelidir. Ayrıca versiyonlama ile geri uyumluluğu koruyabilirsiniz:

```
/api/v1/users
```

Versiyonlama yöntemleri:

- URI bazlı versiyonlama
- Header bazlı versiyonlama

### 3. HTTP Status Kodları Kullanımı

REST API gelişiminde uygun HTTP status kodlarını döndürmek önemlidir. Yaygın kullanılanlar şunlardır:

- 200 OK – Başarılı istek
- 201 Created – Yeni veri oluşturuldu
- 204 No Content – İçerik yok (DELETE sonrası)
- 400 Bad Request – Hatalı istek
- 401 Unauthorized – Kimlik doğrulama gerekiyor
- 404 Not Found – Kaynak bulunamadı
- 500 Internal Server Error – Sunucu hatası

### 4. Exception Handling (Hata Yönetimi)

API kullanıcılarına anlaşılır hata mesajları göndermek kullanıcı deneyimi açısından kritiktir. Hatalar standart bir yapıda dönmelidir:

```json
{
  "status": 400,
  "error": "Bad Request",
  "message": "E-mail alanı zorunludur"
}
```

### 5. Authentication ve Authorization

REST API’ler genellikle JWT, OAuth 2.0 gibi yöntemlerle korunur. API’ye gelen her isteğin doğrulama mekanizmasından geçtiğinden emin olun. Kullanıcıların sadece erişmeye yetkili oldukları kaynaklara ulaşması gerekir.

### 6. Rate Limiting ve Güvenlik

DoS saldırılarını önlemek amacıyla IP bazlı rate limiting uygulanabilir. Güvenlik için HTTPS zorunlu olmalı ve input validation eksiksiz yapılmalıdır.

### 7. Swagger ve OpenAPI ile Dokümantasyon

API’nizin anlaşılır ve erişilebilir olması için OpenAPI standardını (eski adıyla Swagger) kullanabilirsiniz:

- API endpoint’leri otomatik belge haline gelir.
- Kullanıcılar API’yi test edebilir ve daha kolay entegre olabilir.

### 8. Test Etme

Unit ve integration testleri ile API’nizin işlevselliği sürekli kontrol edilmelidir. Postman, Insomnia gibi araçlarla manuel test yapılırken, Jest, Mocha, PHPUnit gibi test framework’lerinden de yararlanılabilir.

### 9. Performans İyileştirme

REST API performansı; sorgu optimizasyonu, database index’leri, cache mekanizmaları (Redis, Memcached) ve CDN'lerle artırılabilir. Ayrıca gzip ve benzeri HTTP sıkıştırmaları ile veri boyutu azaltılabilir.

### 10. Deployment Süreci

API’nizi geliştirip test ettikten sonra CI/CD süreçleri ile deployment gerçekleştirebilirsiniz. Kubernetes, Docker, Jenkins, GitHub Actions gibi araçlar otomasyon açısından oldukça güçlüdür.

## En İyi REST API Geliştirme Pratikleri

- API endpoint’lerinin anlamlı ve belirgin olması
- Standart JSON yapılarına uyum
- Versiyonlama desteği
- Güvenlik önlemleri (JWT, HTTPS, CORS)
- Rate limiting ve logging
- Swagger/OpenAPI desteği
- Performans ve hata yönetimi uygulamaları

## REST API ile Mikroservis Entegrasyonu

REST API’ler mikroservis mimarilerinde servisler arası iletişimde sıkça kullanılır. Bir sipariş sistemi ödeme servisi, kullanıcı servisi ve ürün servisine REST API aracılığıyla erişebilir. Her servis ayrı bir REST API sunar.

Bu noktada API Gateway çözümleri (NGINX, Kong) ile servisler orkestre edilebilir, cache, load balancing ve autentikasyon merkezi olarak sağlanabilir.

## Sonuç

REST API'ler günümüz yazılım geliştirme süreçlerinin vazgeçilmez parçalarından biridir. Sağlam bir mimari, standartlara uygunluk, güvenlik ve performans odaklı geliştirme ile başarılı bir REST API inşa etmek mümkündür. Bu nedenle REST mimarisinin temel prensiplerini öğrenmek ve uygulamak, yazılım geliştiriciler için kritik bir beceridir.

REST API Nedir? Nasıl Geliştirilir?

Yazılım geliştirme dünyasında artan proje ihtiyaçları, farklı mimari yaklaşımların doğmasına sebep olmuştur. Bu yaklaşımlar arasında en çok karşılaştırılanlardan ikisi monolitik ve mikroservis mimarileridir. Bu yazıda her iki yaklaşımın ne olduğu, hangi durumlarda tercih edilmesi gerektiği ve aralarındaki temel farklar ele alınacaktır.

## Monolitik Mimari Nedir?

Monolitik mimari, bir uygulamanın tüm bileşenlerinin tek bir kod tabanı üzerinde geliştirildiği, dağıtıldığı ve çalıştırıldığı klasik bir yazılım mimarisidir. Monolitik sistemlerde; kullanıcı arayüzü, iş mantığı, veri erişim katmanı gibi modüller tek bir uygulama halinde bir arada bulunur.

Örnek bir monolitik yapıda, tüm HTTP istekleri tek bir sunucuya gelir ve tüm işlemler aynı işlem havuzu içinde yapılır. Dağıtım yaparken tüm uygulama derlenir ve genellikle tek bir dosya olarak sunucuya aktarılır.

Avantajları:
- Basit bir geliştirme süreci sunar.
- Lokal geliştirme ortamında daha kolay test edilebilir.
- Dağıtımı yönetmek görece daha kolaydır.

Dezavantajları:
- Uygulama büyüdükçe, kod tabanı yönetimi karmaşık hale gelir.
- Herhangi bir modüldeki değişiklik, tüm uygulamanın yeniden derlenmesini ve dağıtılmasını gerektirebilir.
- Yüksek erişilebilirlik ve ölçeklenebilirlik sağlamak zordur.

## Mikroservis Mimarisi Nedir?

Mikroservis mimarisi, uygulamanın işlevsel bileşenlerinin bağımsız servisler halinde geliştirildiği ve dağıtıldığı bir mimari yaklaşımdır. Her servis, belirli bir işlevi yerine getirir ve diğer servislerle HTTP API, mesaj kuyruğu veya RPC protokolleri aracılığıyla iletişim kurar.

Mikroservislerde her servis bağımsız olarak dağıtılabilir ve yönetilebilir. Bu servisler farklı programlama dilleriyle yazılabilir ve kendilerine özel veritabanlarına sahip olabilirler.

Avantajları:
- Takımlar servis bazlı ayrılarak bağımsız geliştirilebilir.
- Servisler ihtiyaçlara göre bağımsız olarak ölçeklenebilir.
- Hatalı servis yalnızca kendisini etkiler, tüm uygulama zarar görmez.

Dezavantajları:
- Servisler arası iletişim karmaşık hale gelir.
- DevOps süreçleri daha karmaşık ve maliyetlidir.
- Uygulamanın tamamını test etmek daha zordur.

## Temel Farklar

| Özellik | Monolitik Mimari | Mikroservis Mimarisi |
|--------|------------------|----------------------|
| Geliştirme | Tek kod tabanı | Servis bazlı ayrık kod tabanları |
| Dağıtım | Tek uygulama paketi | Her bir servis bağımsız dağıtılır |
| Ölçeklenebilirlik | Yatay ölçekleme zordur | Her servis bağımsız olarak ölçeklenebilir |
| Hata Yalıtımı | Bir hata tüm sistemi etkileyebilir | Hatalar servisin izolasyonunda kalabilir |
| Esneklik | Düşük | Yüksek |
| Takım Yapısı | Merkezi | Dağıtık, domain bazlı |
| Teknoloji Kullanımı | Genellikle tek teknoloji | Servis bazlı farklı teknolojiler uygulanabilir |

## Ne Zaman Monolitik? Ne Zaman Mikroservis?

Yeni başlayan ve küçük ölçekli projeler için monolitik yapı tercih edilebilir. Bu yapı, hızlı geliştirme, düşük başlangıç maliyeti ve basit bakım avantajları sunar. Ancak monolitik sistem zamanla büyüdükçe yönetimi zorlaşır, bu da bakım ve geliştirme süreçlerinde gecikmelere neden olabilir.

Projeler büyüdüğünde, farklı domainler birbirinden bağımsız olarak gelişmeye başladığında ve ekipler çoğaldığında mikroservis mimarisi tercih edilmelidir. Ayrıca performans ihtiyacı doğrultusunda yatay ölçeklenebilirlik gerekiyorsa mikroservisler daha avantajlıdır.

Ancak mikroservise geçmeden önce DevOps olgunluğu, servis içi routing, loglama, izleme, otomatik dağıtım (CI/CD), hata ayıklama gibi temel altyapıların kurulması gerekir. Aksi halde mikroservis karmaşası ortaya çıkabilir.

## Hibrit Yaklaşımlar

Bazı durumlarda her iki yaklaşımın avantajlarını barındırmaya çalışan hibrit modeller kullanılmaktadır. Örneğin, öncelikle monolitik mimari üzerinde geliştirilen bir uygulama, zamanla bazı sık kullanılan fonksiyonları mikroservis olarak ayırabilir.

Bu geçiş süreci genellikle "modüler monolit" yaklaşımıyla yürütülür. Modüler yapılandırılmış monolitik uygulamalar, mikroservise geçiş sürecini kolaylaştırır. Bu sayede uygulama önceden segmentlere ayrılmaya başlanmış olur.

## Sonuç

Monolitik ve mikroservis mimarilerinin her birinin kendi kullanım senaryoları vardır. Her proje için en uygun yaklaşım; projenin büyüklüğü, ekip sayısı, süre, maliyet ve teknik yeterlilikler göz önüne alınarak değerlendirilmelidir. Mikroservisler modern uygulamalar için güçlü esneklik sunarken, küçük takımlı ve nispeten basit sistemlerde monolitik mimari daha verimli çözümler sunabilir. Bu nedenle mimari kararlar alınırken teknik yeterlilik kadar organizasyonel yapılara da dikkat edilmelidir.

Monolitik ve Mikroservis Mimarisi Arasındaki Farklar

My first LLM gateway had a bug that could have leaked user data across tenants.

So I rebuilt the whole thing. 👇

v0.1.0 was a classic MVP: FastAPI + LiteLLM, PII scrubbing, semantic caching. It worked — for one user, in a perfect world.

Then I looked at it through a production lens:
❌ Shared global cache → cross-tenant data leaks 
❌ Static API keys → no real identity 
❌ Zero budget controls → one bad client = $$$ gone 
❌ 200ms safety overhead → developers will bypass you

Every one of those had the same root cause: the gateway had no concept of identity. It was built for a user, not users.
v0.2.0 ships with:
✅ JWT-based multi-tenancy with isolated Redis Stack indices per tenant 
✅ Hybrid inference — vLLM (PagedAttention) for self-hosted, LiteLLM for cloud routing 
✅ Atomic rate limiting + USD budget caps via Redis Lua scripts 
✅ <5ms p50 overhead — safety layers fit inside the budget 
✅ 225+ tests — because production reliability is a silent feature

Think of it as an open-source alternative to Portkey or Kong AI Gateway — built around multi-tenant isolation and sub-5ms overhead.

The biggest lesson?
Moving from MVP to production isn't about adding features. It's about adding constraints.

Full architecture deep dive linked in the comments 👇

Would love feedback from anyone shipping LLM infrastructure.

Full write-up here: https://orhunkupeli.hashnode.dev/mvp-to-mission-critical-the-idea-behind-my-llm-gateway-rewrite

MVP to Mission-Critical: The Idea Behind My LLM Gateway Rewrite

Modern web uygulamalarının artan kullanıcı taleplerini karşılayabilmesi için performans, ölçeklenebilirlik ve kullanılabilirlik açısından yüksek standartlara sahip olması gerekir. Bu noktada, cache yönetimi devreye girer. Redis, açık kaynak kodlu bir bellek içi veri mağazası olarak en yaygın kullanılan cache sistemlerinden biridir.

## Redis Nedir?

Redis (Remote Dictionary Server), bellekte çalışan, anahtar-değer (key-value) yapısına dayalı bir veri deposudur. Yüksek performanslı, düşük gecikmeli ve çok çeşitli veri yapıları (string, list, set, sorted set, hash, bitmap vb.) sunan Redis, sadece cacheleme amacıyla değil, aynı zamanda geçici veri depolama, oturum yönetimi, sıralı yapılar ve kuyruk sistemleri gibi birçok farklı kullanım alanına sahiptir.

## Neden Redis Kullanmalıyız?

Redis’in en büyük avantajlarından biri veriyi direkt olarak bellekte (RAM’de) tutmasıdır. Bu, veritabanına yapılacak sorgulara kıyasla milisaniyelerle ölçülebilecek erişim süreleri sağlar. Özellikle sık kullanılan verilerin (ör. ürün bilgileri, konfigürasyon parametreleri) Redis üzerinde cache’lenmesi, hem uygulama performansını artırır hem de veritabanı yükünü azaltır.

## Tipik Cache Kullanım Senaryoları

### 1. Sık Okunan Verilerin Saklanması
Bir e-ticaret sitesinde kampanyalı ürünleri listelemek gibi sıkça yapılan işlemler için Redis cache kullanmak, kullanıcı deneyimini ciddi şekilde geliştirir.

### 2. Oturum (Session) Yönetimi
Stateless olması üzerine kurulu dağıtık mikroservis mimarilerinde oturum yönetimi Redis’e devredilebilir. Kullanıcı oturum bilgileri Redis üzerinde saklanarak hızlı erişim sağlanabilir.

### 3. Rate Limiting (Oran Sınırlama)
Kullanıcının ya da API istemcisinin belirli bir zaman dilimindeki istek sayısını kontrol etmek için Redis zaman damgalı anahtarlar ve INCR komutu kombine şekilde kullanılarak hızlı ve etkili rate limiting mekanizmaları geliştirilebilir.

## Redis ile Cache Yönetimi Nasıl Yapılır?

Redis ile veriler genellikle belirli bir süre için tutulur. Bu sürenin sonunda otomatik olarak silinirler. Bu mekanizmaya TTL (Time To Live) denir. Cache'lenen objelere TTL vermek, hem veri tazeliğini garanti eder hem de bellek kullanımını kontrol altında tutar.

```bash
SET kampanya:2024 {"isim": "Sezon İndirimi", "indirim": "%30"} EX 600
```

Yukarıdaki komut Redis’e bir JSON veri ekler ve 600 saniye (10 dakika) sonra otomatik silinmesini sağlar.

## Cache Invalidation (Geçersizleştirme)

Bir verinin güncellenmesi veya silinmesi halinde, cache içerisindeki eski verinin de silinmesi gerekir. Bu durum cache invalidation olarak adlandırılır. Bu süreç otomatik hale getirilmediği takdirde "stale data" (bayat veri) sorunlarıyla karşılaşılır.

Bazı stratejiler:

- **Write-through:** Veri hem veritabanına hem de cache’e eş zamanlı olarak yazılır.
- **Write-behind:** Veri önce cache’e yazılır, sonra zamanlayıcı ile veritabanına aktarılır.
- **Cache aside:** Uygulama, veriye her ihtiyaç duyduğunda önce cache’i kontrol eder. Cache’te yoksa veritabanına gider, sonrası cache’e eklenir.

## Redis’in Performans Artırıcı Özellikleri

### 1. Pipeline Kullanımı
Birden fazla komutu tek bir TCP bağlantısı ile göndermek performansı artırır.

```python
pipe = r.pipeline()
pipe.set("k1", "v1")
pipe.set("k2", "v2")
pipe.execute()
```

### 2. Hash Yapıları ile Veri Gruplama
Aynı veri modeli içinde olan değerler hash yapısıyla gruplanarak daha verimli yönetilebilir:
```bash
HSET urun:123 isim "Çanta" fiyat 250.00 stok 42
```

### 3. Expire, Persist ve TTL Komutları
Her anahtar için süre tanımlanabilir. Bu komutlarla cache yaşam döngüsü etkili biçimde yönetilir.

### 4. LRU ve LFU Algoritmaları
Redis’te belleğin dolması durumunda hangi anahtarların düşürüleceği LRU (Least Recently Used) veya LFU (Least Frequently Used) ile belirlenebilir.

### 5. Redis Cluster ile Yük Dağılımı
Redis tek bir makinede çalışabildiği gibi, Redis Cluster ile yatayda ölçeklenebilir hale getirilerek çok sayıda node’a dağıtılabilir.

## Redis ve Mikroservis Mimarileri

Mikroservislerin birçoğu birbirinden bağımsız çalışır ve farklı veritabanlarını kullanabilir. Ancak merkezi bir cache altyapısı tüm servisler tarafından ortak kullanılabilir. Örneğin, bir kampanya servisi tarafından Redis'e yüklenen veriyi, kullanıcı arabirimi servisi okuyabilir. Bu tarz entegrasyonlarda Redis publish/subscribe ya da event-based mekanizmalarla da desteklenebilir.

## Redis Monitoring ve Gözlemlenebilirlik

Uygulamanın performansında Redis kullanımı kritik rol oynadığından, sistem kaynaklarını nasıl kullandığını izlemek önemlidir. Redis’in `INFO`, `MONITOR` komutları ya da `redis-cli` gibi yardımcı araçlar ile sorgulama yapılabilir. Ayrıca Prometheus + Grafana entegrasyonu ile Redis metrikleri görselleştirilebilir.

## Güvenlik Önlemleri

Redis varsayılan olarak korumasızdır. Üretim ortamında aşağıdaki güvenlik önlemleri uygulanmalıdır:

- Parola (AUTH) zorunluluğu getirin.
- Redis’i sadece localhost veya özel VPC üzerinden erişilebilir hale getirin.
- Güvenlik duvarları ile `6379` portunu dış erişime kapatın.
- TLS desteği aktive edilerek şifreli iletişim sağlanabilir.

## Redis Alternatifleriyle Kıyaslama

Redis’e alternatif olarak Memcached de kullanılabilir. Ancak Memcached sadece string tipi değer tutabildiği ve kalıcılık (persistence) sunmadığı için Redis genellikle daha tercih edilir bir çözümdür. Redis’in sunduğu zengin veri yapıları ve script desteği (Lua ile) birçok gelişmiş kullanım senaryosu için uygundur.

## Sonuç

Redis, modern web ve mikroservis tabanlı uygulamalarda cache yönetimi ve performans artırımı açısından vazgeçilmez bir bileşendir. Doğru konumlandırıldığında uygulama yanıt sürelerini dramatik şekilde düşürür, sistemin ölçeklenebilirliğini artırır ve kullanıcı deneyimini iyileştirir. Ancak cache yapılarının karmaşıklığı arttıkça, geçersizleştirme, veri tutarlılığı ve gözlemlenebilirlik konularında dikkatli olunmalı ve uygun stratejiler belirlenmelidir.

Redis’in sunduğu özellikler, onu sadece bir cache aracı değil; aynı zamanda hafif mesajlaşma, oturum yönetimi ve geçici veri saklama için de güçlü bir çözüm haline getirmektedir.

Kapsamlı Redis Kullanımı: Cache Yönetimi ve Performans Artırımı

JWT (JSON Web Token), modern web uygulamalarında kullanıcı kimlik doğrulamasını ve bilgilerin güvenli bir şekilde paylaşımını sağlamak için kullanılan hafif bir mekanizmadır. Özellikle stateless (durumsuz) mimarideki uygulamalar için ideal bir çözümdür.

## JWT Nedir?

JSON Web Token (JWT), iki taraf arasında güvenli bir şekilde bilgi aktarımı için kullanılan açık standart (RFC 7519) bir formattır. JSON formatında olan bu token, üç parçadan oluşur: Header (başlık), Payload (yük) ve Signature (imza).

## JWT Parçaları

- **Header**: JWT’nin algoritmasını ve türünü belirtir. Genellikle `alg` ve `typ` alanlarını içerir. Örnek: `{ "alg": "HS256", "typ": "JWT" }`

- **Payload**: Token içerisinde taşınan aslî veridir. Kullanıcı bilgileri, roller, izinler veya başka özel veriler bu bölümde yer alır. Doğruluk kontrolü yapılmadığı sürece bu veri herkes tarafından okunabilir.

- **Signature**: Token’ın bütünlüğünü korumak amacıyla oluşturulan imzadır. Header ve Payload HMACSHA256 gibi bir algoritma ile imzalanır.

## JWT ile Kimlik Doğrulama Akışı

JWT ile kimlik doğrulama işlemi temelde şu şekilde çalışır:

1. Kullanıcı, kullanıcı adı ve şifre ile giriş isteği gönderir.
2. Sunucu, kullanıcı bilgilerini doğrularsa, bir JWT üretir ve istemciye gönderir.
3. İstemci, bu token'ı sonraki tüm isteklerin Authorization başlığına `Bearer {token}` biçiminde ekler.
4. Sunucu, gelen token'ı doğrular ve geçerliyse isteği işler.

## Örnek JWT Üretimi (Node.js)

```javascript
const jwt = require('jsonwebtoken');

const user = { id: 1, username: 'user1', role: 'admin' };
const secretKey = 'mysecret';

const token = jwt.sign(user, secretKey, { expiresIn: '1h' });
console.log(token);
```

## Token Doğrulama

Token doğrulanırken hem imzanın hem de sürenin kontrolü yapılmalıdır. Örnek:

```javascript
jwt.verify(token, secretKey, (err, decoded) => {
  if (err) {
    return res.status(401).send('Yetkisiz erişim!');
  }
  req.user = decoded; // Token’dan gelen veriler kullanıcı nesnesi olarak atanır
  next();
});
```

## Güvenlik Önlemleri

JWT kullanımı sırasında uyulması gereken bazı önemli güvenlik önlemleri vardır:

- **Kısa süreli token kullanımı:** Token’ın ömrü kısa olmalıdır. Eğer token çalınırsa daha az zarar verir.

- **HTTPS kullanımı:** Token'lar açık bir şekilde taşındığı için, TLS olmadan iletildiğinde ortadaki adam saldırılarına (MiTM) açık hale gelir.

- **Token yenileme mekanizması (Refresh Token):** Erişim token’larının süresinin kisa olması nedeniyle kullanıcı çıkış yapmadan yeni token alabilmeli. Bu, refresh token yapısıyla sağlanır.

## Access Token ve Refresh Token Kullanımı

JWT, hem `Access Token` hem de `Refresh Token` olarak rol alabilir:

- **Access Token:** Kısa ömürlüdür ve API erişimlerinde kullanılır.
- **Refresh Token:** Daha uzun ömürlüdür ve yalnızca yeni access token üretmek için kullanılır.

Token yenileme için tipik senaryo:

1. Kullanıcı başarıyla giriş yaptığında, hem access hem de refresh token sunucu tarafından üretilir.
2. Access token süresi sona erdiğinde istemci, refresh token ile bir endpoint'e başvurarak yeni access token alır.
3. Refresh token da süresini doldurduysa veya iptal edildiyse, kullanıcı tekrar giriş yapmak zorundadır.

## Blacklist ve Token İptali

JWT'lerin stateless yapısı, genellikle sunucuda oturum tutmayı gereksiz hale getirir. Ancak bu, token’ın geçerliliğini iptal etmeyi zorlaştırır. Bir kullanıcı sistemden çıkış yaptığında veya token çalındığında, bu token’ı nasıl iptal edeceğimizi hesaplamalıyız. Bu hedefle kara liste (blacklist) yapısı kullanılabilir.

- Redis gibi bellek tabanlı veritabanında iptal edilen token değerleri saklanabilir.
- Her API isteğinde token’ın blacklist’te olup olmadığı kontrol edilir.

## JWT Middleware Kullanımı (Express.js)

Token doğrulamanın her API endpoint'inde yapılması yerine, bir middleware ile merkezi hale getirilebilir:

```javascript
function authenticateJWT(req, res, next) {
  const authHeader = req.headers.authorization;

  if (authHeader) {
    const token = authHeader.split(' ')[1];

    jwt.verify(token, secretKey, (err, user) => {
      if (err) {
        return res.sendStatus(403);
      }

      req.user = user;
      next();
    });
  } else {
    res.sendStatus(401);
  }
}
```

Bu middleware, korumak istediğiniz rotalarda kullanılabilir:

```javascript
app.get('/dashboard', authenticateJWT, (req, res) => {
  res.send('Dashboard verileriniz');
});
```

## JWT ile Yetkilendirme (Authorization)

JWT payload içinde kullanıcının rol bilgilerini ekleyerek yetkilendirme işlemini yapabilirsiniz.

Örneğin Token Payload:

```json
{
  "id": 1,
  "username": "user1",
  "role": "admin"
}
```

Middleware seviyesinde basit bir kontrol:

```javascript
function authorizeRole(role) {
  return (req, res, next) => {
    if (req.user.role !== role) {
      return res.sendStatus(403);
    }
    next();
  };
}
```

Kullanım:

```javascript
app.get('/admin', authenticateJWT, authorizeRole('admin'), (req, res) => {
  res.send('Admin paneli');
});
```

## JWT’nin Avantajları

- Sunucu tarafında oturum saklamaya gerek yoktur.
- Mikroservis mimarilerinde, stateless şekilde erişim yönetimi sağlar.
- Token taşınabilir ve farklı kaynaklarda güvenli şekilde kullanılabilir.

## JWT’nin Sınırlamaları

- Token süresince erişim geçerliliği devam eder. Böylece token çalınırsa kötüye kullanılabilir.
- Blacklist yapılandırması ekstra kaynak tüketir.
- Kaybolan ya da süresi dolan refresh token'ların yönetimi zordur.

## Sonuç

JWT ile kimlik doğrulama, modern web servislerinin güvenliğini sağlamak için oldukça etkili bir yöntemdir. Özellikle durumsuz mimariye sahip sistemlerde sade ve performanslı bir çözüm sunar. Ancak güvenlik önlemleri ve token yönetimi doğru uygulanmazsa ciddi açıklar oluşabilir. Bu nedenle access/refresh token ayrımını doğru yapmak, HTTPS kullanmak, blacklist stratejilerini uygulamak gereklidir.

JWT ile Kimlik Doğrulama Nasıl Yapılır?

Backend geliştirme dünyasında iki popüler teknoloji sıklıkla karşılaştırılır: Go (Golang) ve Node.js. Her ne kadar her ikisi de yüksek performanslı backend sistemleri oluşturmak için kullanılabilse de, farklı kullanım senaryoları, mimari ihtiyaçlar ve ekip tercihlerine göre birbirlerine kıyasla avantajlar veya dezavantajlar sunabilirler.

## Go (Golang) Nedir?

Go, Google tarafından geliştirilen açık kaynaklı, statik tipli, derlemeli bir programlama dilidir. Performansa odaklanır, düşük bellek kullanımı ve yüksek eşzamanlılık desteği ile dikkat çeker. Go, özellikle mikroservis mimarilerinde, sistem programlamasında ve üst düzey API hizmetlerinde oldukça popüler hale gelmiştir.

## Node.js Nedir?

Node.js, Chrome’un V8 JavaScript motoru üzerine inşa edilmiş, olay güdümlü, asenkron I/O özellikleri olan, non-blocking mimariye sahip bir çalışma zamanıdır. JavaScript dilinin backend tarafında çalışmasını mümkün kılar. Node.js sayesinde geliştiriciler, aynı dil ile hem frontend hem de backend geliştirme yapabilir.

## Performans Karşılaştırması

Go'nun derlenmiş bir dil olması, ham performans açısından Node.js'e kıyasla ciddi avantajlar sağlamaktadır. Özellikle CPU yoğunluklu uygulamalarda Go çok daha az kaynak tüketimi ile yüksek performans verebilir. Node.js ise I/O işlemlerini oldukça verimli bir şekilde yönetebilir, ancak parallel işlem (concurrent execution) konusunda Go kadar başarılı değildir. Örneğin, log işleyen, büyük veri pipeline'ları yöneten bir servis geliştirmek istiyorsanız Go sizin için daha uygun olabilir.

## Eşzamanlılık (Concurrency) ve Paralelizm

Go’nun en güçlü yönlerinden biri native olarak sunduğu “goroutine” mekanizmasıdır. Hafif thread’lar olan goroutine’ler sayesinde binlerce eşzamanlı işlemi minimum kaynakla gerçekleştirebilirsiniz. Bu, özellikle mikroservis tabanlı, çok fazla arkaplan iş yükü olan sistemlerde büyük bir avantaj sağlar.

Node.js ise “event loop” yaklaşımı ile tek thread üzerinden eşzamanlılık sağlamak üzere geliştirilmiştir. Küçük ve orta ölçekli uygulamalar için yeterli performans sunar. Ancak CPU-bound işlemler Node.js üzerinde teknik kısıtlamalara takılabilir. Çözüm olarak child process veya worker thread’ler kullanılabiliyor, ancak bu yapı Go’nun sunduğu sadelik ve verimlilikten uzak olur.

## Ekosistem ve Kütüphane Desteği

Node.js, daha uzun süredir geliştirilen ve JavaScript’in yaygın kullanımı sayesinde çok geniş bir ekosisteme sahiptir. npm üzerinden erişilebilen yüzbinlerce paket sayesinde birçok işlemi hızlıca çözüme kavuşturabilirsiniz. Ancak bu geniş ekosistem zaman zaman güvenlik açıklarına ve kalitesiz paket kullanımına yol açabilir.

Go tarafında kütüphane sayısı daha az fakat daha kararlı ve düşük bağımlılık seviyeleriyle geliştirilmiş paketler görmek mümkündür. Ayrıca Go standard kütüphanesi oldukça güçlüdür, birçok ihtiyacı ek bir kütüphane olmadan çözebilirsiniz.

## Geliştirme Hızı

Node.js geliştiriciler için hızlı prototipleme ve uygulama geliştirme imkanı sağlar. JavaScript dilinin esnekliği ve dinamik yapısı sayesinde işler daha hızlı ilerleyebilir. Bu özellik MVP geliştirme veya startup uygulamalarında Node.js’i öne çıkarır.

Go ise sağlam, okunabilir ve sürdürülebilir kod yazılması amacıyla geliştirilmiştir. Bu nedenle ilk geliştirme süreci biraz daha uzun olabilir. Ancak projeyi büyüttüğünüzde sistemin sürdürülebilirliğini sağlamak açısından Go daha avantajlıdır.

## Hata Yönetimi ve Tip Sistemleri

Go’nun statik tipli olması ve hata yönetiminin `error` dönüşü ile yapılması geliştiricilere daha sağlam kodlar yazma isteği aşılar. Compile zamanı hatalarının çoğu erkenden yakalanır. Bu durum büyük projelerde bakım maliyetini azaltır.

Node.js ve JavaScript dinamik tipli olduğu için gelişim süreci esnektir ancak hatalar runtime’da ortaya çıkabildiğinden üretim ortamında dikkat edilmesi gerekir. TypeScript kullanılarak bu problem belirli ölçüde çözülebilir fakat bu, Node.js’in gömülü bir özelliği değildir.

## Topluluk ve Dokümantasyon

Her iki teknoloji de büyük topluluklara sahiptir. Node.js’in popülerliği nedeniyle daha fazla eğitim kaynağı ve örnek proje bulunmaktadır. Ancak Go’nun minimalist yapısı ve detaylı resmi dokümantasyonu, öğrenme sürecini hızlı hale getirir. Ayrıca Go’nun topluluğu daha çok performans ve mimariye önem veren profesyonel geliştiricilerden oluşmaktadır.

## Dağıtım ve Operasyonel Kolaylık

Go uygulamaları tek bir statik binary haline derlenerek dağıtılabilir. Bu özellik, deployment süreçlerini inanılmaz derecede basitleştirir. Cross-compilation desteklediği için farklı işletim sistemleri için tek noktadan binary üretebilirsiniz.

Node.js tarafında uygulama dağıtmak için node modüllerinin tamamı ile birlikte paketleme yapmanız gerekir. Uygulama runtime'a bağımlı olduğu için production ortamında node ve gerekli modüllerin kurulu olması gerekir. Bu durum Docker veya benzeri container teknolojileriyle çözülebilir.

## Kullanım Senaryolarına Göre Tercih

### Ne Zaman Go Kullanalım?

- Yüksek performans gerektiren sistemler (örneğin, messaging queue, streaming pipeline)
- Mikroservis mimarileri
- CLI arayüz veya sistem seviyesinde yazılımlar
- Düşük bellek tüketimi ve hız önceliği olan uygulamalar

### Ne Zaman Node.js Kullanalım?

- Hızlı prototipleme gereken uygulamalar
- JavaScript bilen ekiplerle çalışılması planlanan projeler
- Websocket tabanlı gerçek zamanlı uygulamalar
- Bir frontend-backend ortak stack geliştirilecekse (Fullstack JS)

## Sonuç

Go ve Node.js her biri farklı avantajlar sunan güçlü backend teknolojileridir. Tercih yapılırken sistemin ihtiyaçları, ekip yapısı, operasyonel gereksinimler ve performans beklentileri dikkate alınmalıdır. Go daha çok sistem mühendisliği ve performans odaklı projeler için tercih edilirken, Node.js geliştiricilerin etkin olduğu, hızlı dönem projelerde öne çıkmaktadır. Doğru araç, doğru problem için seçildiğinde uzun vadede teknik borçları önlemenin yanı sıra sisteminizin başarısını da artırır.

Go vs Node.js: Hangi Backend Teknolojisi Ne Zaman Tercih Edilmeli?

Azure, Azure Databricks, Azure HDInsight ve Azure Kubernetes Service (AKS) gibi çeşitli Azure barındırılan teknolojiler için çalışan ve sürücü düğümleri de dahil olmak üzere, farklı iş yüklerine ve kullanım örneklerine hitap eden çeşitli sanal makine (VM) türleri sunar. İşte farklı VM türlerinin ve çalışan veya sürücü düğümleri için uygunluklarının kısa bir özeti:

### Genel Amaçlı Sanal Makineler

-   **B serisi (Patlamalı Sanal Makineler)** : Sürekli CPU performansı gerektirmeyen iş yükleri için uygun maliyetli sanal makineler.
    -   **Kullanım durumu** : Geliştirme ve test ortamları, küçük veritabanları, düşük trafikli web sunucuları.
-   **D serisi** : Dengeli CPU-bellek oranı, çoğu üretim iş yüküne uygundur.
    -   **Kullanım durumu** : Web sunucuları, kurumsal uygulamalar ve küçük ve orta ölçekli veritabanları.

### Hesaplama için Optimize Edilmiş Sanal Makineler

-   **F serisi** : Yüksek CPU-bellek oranı, yoğun işlem yükü gerektiren iş yükleri için uygundur.
    -   **Kullanım durumu** : Toplu işleme, web sunucuları, analiz, oyun.

### Bellek Optimize Edilmiş Sanal Makineler

-   **E-serisi** : Yüksek bellek-CPU oranı, bellek yoğun uygulamalar için uygundur.
    -   **Kullanım durumu** : Büyük veritabanları, bellek içi analitik, SAP HANA.
-   **M serisi** : Çok yüksek bellek-CPU oranı, son derece büyük bellek iş yükleri için uygundur.
    -   **Kullanım durumu** : Büyük ölçekli SAP HANA, veri ambarı, bellek içi analiz.

### Depolamaya Optimize Edilmiş Sanal Makineler

-   **L serisi** : Yüksek disk verimi ve G/Ç, depolama yoğunluklu uygulamalar için uygundur.
    -   **Kullanım durumu** : Büyük veri, SQL ve NoSQL veritabanları, veri ambarları.

### GPU Optimize Edilmiş Sanal Makineler

-   **NC serisi** : İşlem ve grafik yoğunluklu iş yükleri için GPU özellikli sanal makineler.
    -   **Kullanım durumu** : Yapay zeka ve derin öğrenme, yüksek performanslı bilgi işlem (HPC), işleme.
-   **NV serisi** : Görselleştirme ve grafik yoğunluklu iş yükleri için GPU özellikli sanal makineler.
    -   **Kullanım durumu** : Uzaktan görselleştirme, oyun, simülasyon.

### Yüksek Performanslı Hesaplama Sanal Makineleri

-   **H serisi** : Yoğun işlem gücü gerektiren iş yükleri için yüksek performanslı sanal makineler.
    -   **Kullanım alanı** : Moleküler modelleme, akışkanlar dinamiği, sonlu elemanlar analizi.

## **Dağıtık Sistemler**

### **1. Kubernetes (AKS: Azure Kubernetes Hizmeti)**

Kubernetes, konteynerleştirilmiş uygulamaların dağıtımını, ölçeklenmesini ve yönetilmesini sağlayan bir konteyner düzenleme aracıdır. Azure Kubernetes Hizmeti (AKS), konteynerleri ölçeklendirmek ve yönetmek için Azure VM örnek türlerinden yararlanır.

-   **AKS'de VM Kullanımı:**
    -   **Genel amaçlı sanal makineler (B/D serisi)** : Bunlar daha hafif uygulamalar veya daha küçük iş yükleri için kullanılır.
    -   **Hesaplama için optimize edilmiş sanal makineler (F serisi)** : Güçlü CPU gücüne ihtiyaç duyan yüksek performanslı uygulamalar için kullanışlıdır.
    -   **Bellek açısından optimize edilmiş sanal makineler (E serisi)** : Durum bilgisi olan uygulamalar veya veritabanları gibi önemli miktarda bellek gerektiren iş yükleri için mükemmeldir.
    -   **GPU için optimize edilmiş sanal makineler (NC/ND serisi)** : Konteynerleştirilmiş makine öğrenimi iş yükleri ve yapay zeka çıkarım görevleri için kullanılabilir.

**Kubernetes'in rolü** : Bir Kubernetes kümesinde, sanal makineler kapsayıcıları çalıştırmak için düğüm (çalışan düğüm) görevi görür. Azure, kapsayıcılaştırılmış iş yüklerine ve seçtiğiniz sanal makine boyutuna göre otomatik olarak sanal makineler sağlar.

### **2. Azure'da Databricks**

Azure Databricks, veri mühendisliği, veri bilimi ve makine öğrenimi için Azure ile entegre olan Apache Spark tabanlı bir analiz platformudur. Spark işlerinin çalıştırıldığı kümelerin sağlanması için sanal makineleri kullanır.

-   **Databricks'te VM Kullanımı** :
    -   **Genel amaçlı sanal makineler (D serisi)** : Veri mühendisliği işleri ve etkileşimli veri bilimi not defterleri gibi küçük ve orta ölçekli iş yükleri için idealdir.
    -   **Bellek açısından optimize edilmiş sanal makineler (E serisi)** : Daha fazla bellek gerektiren büyük veri kümelerini ve makine öğrenimi modellerini işlemek için kullanışlıdır.
    -   **Hesaplama için optimize edilmiş sanal makineler (F serisi)** : Toplu işlem ve paralel hesaplama gibi veri yoğun görevlerin daha hızlı yürütülmesine ihtiyaç duyduğunuzda kullanılır.
    -   **GPU için optimize edilmiş sanal makineler (NC/ND serisi)** : Spark MLlib veya TensorFlow kullanarak makine öğrenimi ve derin öğrenme görevlerini çalıştırmak için kullanılabilir.

**Databricks'in rolü** : Veri işleme, ETL ve makine öğrenimi için Apache Spark iş yüklerini çalıştıran Databricks kümelerine sanal makineler tahsis edilir. Seçilen sanal makine türleri iş yükünün niteliğine bağlıdır ve kümenin ölçeği, performans gereksinimlerine göre dinamik olarak ayarlanabilir.

### **3. Azure HDInsight**

HDInsight, Hadoop, Spark ve Hive gibi çerçeveleri çalıştıran büyük veri analitiği için tamamen yönetilen bir bulut hizmetidir. HDInsight'taki sanal makineler, iş yüklerinin niteliğine (veri işleme, sorgulama vb.) göre seçilir.

-   **HDInsight'ta VM Kullanımı** :
    -   **Genel amaçlı sanal makineler (D serisi)** : Genellikle sorgulama veya küçük ölçekli işleme gibi daha küçük, daha az kaynak gerektiren iş yükleri için kullanılır.
    -   **Bellek açısından optimize edilmiş sanal makineler (E serisi)** : Bellek içi analizler ve Spark tabanlı veri analizi gibi daha büyük ölçekli işleme görevleri için idealdir.
    -   **Depolama için optimize edilmiş sanal makineler (L serisi)** : HDInsight'ın büyük veri kümelerini, genellikle dağıtılmış depolama uygulamaları veya veri gölleri için yönettiği durumlarda kullanılır.
    -   **Hesaplama açısından optimize edilmiş sanal makineler (F serisi)** : Hadoop kümelerinde MapReduce işleri veya toplu işlemler gibi büyük ölçekli, hesaplama yoğun görevler için kullanılır.

**HDInsight'ın rolü** : HDInsight kümeleri bu sanal makinelere dayalı olarak oluşturulur. Örneğin, HDInsight'taki bir Spark kümesi veya Hadoop kümesi, hesaplama görevleri için D serisi ve büyük veri hacimlerini işlemek için L serisinin bir karışımını kullanabilir.

### **4. Azure Makine Öğrenimi**

Azure Machine Learning (AML), makine öğrenimi modelleri oluşturmak, eğitmek ve dağıtmak için bir bulut hizmetidir. Sanal makineleri kullanarak iş yüklerini isteğe bağlı olarak ölçeklendirebilir.

-   **Azure Machine Learning'de VM kullanımı** :
    -   **Genel amaçlı sanal makineler (D serisi)** : Bunlar genellikle yüksek hesaplama kaynakları gerektirmeyen temel ML model eğitimi için kullanılır.
    -   **Bellek açısından optimize edilmiş sanal makineler (E serisi)** : Belleğin darboğaz oluşturduğu büyük veri kümelerinde modelleri eğitmek için idealdir.
    -   **GPU için optimize edilmiş sanal makineler (NC/ND serisi)** : Bu sanal makineler, GPU hızlandırması gerektiren derin öğrenme modellerini eğitmek için en faydalıdır.
    -   **Yüksek performanslı hesaplama sanal makineleri (H serisi)** : Kapsamlı hesaplama gücü gerektiren gelişmiş araştırmalar ve makine öğrenimi modelleri için kullanılır.

**AML'nin rolü** : Sanal makineler, AML'de model eğitimi ve dağıtımı için işlem düğümleri görevi görür. Karmaşık modelleri eğitirken veya derin öğrenme için GPU'ları kullanırken daha yüksek performanslı sanal makineleri tercih ederek, işlem kaynaklarını iş yüküne göre ölçeklendirebilirsiniz.

### **5. Azure Synapse Analytics (Eski Adıyla SQL Veri Ambarı)**

Synapse Analytics, büyük veri ve analitik iş yükleri için bir bulut veri platformudur. Büyük veri kümelerini analiz etmek için büyük veri ve veri ambarlarını birleştirir.

-   **Synapse Analytics'te VM kullanımı** :
    -   **Genel amaçlı VM'ler (D serisi)** : ETL süreçlerini veya daha küçük veri işlemlerini çalıştırmak için kullanılır.
    -   **Bellek açısından optimize edilmiş sanal makineler (E serisi)** : Büyük bellek içi veri kümeleri veya gerçek zamanlı analizler işlenirken kullanılır.
    -   **Depolama için optimize edilmiş sanal makineler (L serisi)** : Genellikle dağıtılmış veri göllerinde büyük veri hacimlerini yönetmek için kullanılır.

**Synapse Analytics'in rolü** : Synapse'deki sanal makineler, veri sorguları çalıştırmak, büyük veri kümeleri üzerinde analizler gerçekleştirmek ve iş yüklerini ölçeklenebilir bir şekilde işlemek için kullanılır. Synapse'in SQL havuzları ve Apache Spark havuzları bu sanal makineler tarafından desteklenmektedir.

### **6. Azure İşlevleri**

Azure Functions, olaylara yanıt olarak kod çalıştıran sunucusuz bir bilgi işlem hizmetidir; ancak yine de optimize edilmiş ölçekleme için farklı türdeki sanal makine örneklerinden yararlanabilir.

-   **Azure Functions'ta VM kullanımı** :
    -   **Genel amaçlı sanal makineler (B/D serisi)** : Bunlar, ani yüklenen iş yükleriyle hafif, düşük maliyetli sunucusuz işlevler için kullanılabilir.
    -   **Hesaplama için optimize edilmiş sanal makineler (F serisi)** : Bunlar, hızlı yürütülmesi gereken yüksek performanslı işlevler veya hizmetler için kullanılabilir.

**Azure İşlevleri'nin rolü** : İşlevler, sunucusuz bir modeldeki sanal makinelere dağıtılır. Sistem, iş yükü taleplerine göre sanal makineleri otomatik olarak arka planda ölçeklendirir ve ihtiyaç duyulduğunda uygun sanal makine boyutlarını seçer.

## Azure VM Türleri ve Rolleri

Aşağıda çeşitli Azure VM örnek türlerinin ve dağıtılmış sistemlerdeki çalışan/düğüm türleri olarak rollerinin basitleştirilmiş bir görüntü gösterimi bulunmaktadır:

1.  **Genel amaçlı sanal makineler** – Çok yönlüdür, çok çeşitli uygulamalar için kullanılır
2.  **İşlem için optimize edilmiş sanal makineler** – CPU yoğun görevler için
3.  **Bellek açısından optimize edilmiş sanal makineler** – Bellek yoğunluklu görevler için
4.  **Depolama için optimize edilmiş sanal makineler** – Veri yoğun iş yükleri için.
5.  **GPU için optimize edilmiş sanal makineler** – Makine öğrenimi ve GPU tabanlı iş yükleri için
6.  **Yüksek performanslı hesaplama sanal makineleri** – Süper hesaplama ve simülasyonlar için

| Bulut Hizmeti  | Kullanılan VM Türleri | Sanal Makinelerin Tipik Rolü |
|--|--|--|
| Kubernates (AKS) | B/D/F/E/NC serileri | Konteynerleştirilmiş uygulumalar için ölçeklenebilir hesaplama ihtiyaçları için çalışan workerlar |
| Databricks | D/E/F/NC serileri | Spark kümeleri, makine öğrenimi ve veri mühendisliği iş yükleri |
| HDInsight | D/E/F/L serileri | Büyük veri analitiği (Hadoop, Spark), büyük ölçekli veri işleme |
| Azure ML | D/E/NC/ND/H serileri | Model eğitimi, derin öğrenme, yoğun hesaplama gerektiren iş yükleri |
| Synapse Analytics | D/E/L serileri | Veri ambarı, analitik ve büyük veri işleme |
| Azure Functions | B/D/F serileri | Otomatik ölçeklendirmeye sahip serverless işlevler |


Azure VM Örnek Türleri ve Farklı Dağıtılmış Yazılım Sistemlerindeki Rolleri

Modern uygulamalar, özellikle mikroservis mimarisi benimseyenler, birçok bağımsız servisten oluşur. Bu servislerin her biri farklı portlarda, farklı protokollerle çalışabilir ve doğrudan erişime açık olduklarında güvenlik, versiyonlama ve yük dengeleme gibi sorunlara yol açabilir. Bu gibi karmaşaları çözmek, sistemin ölçeklenebilirliğini artırmak ve merkezi bir kontrol noktası sağlamak için API Gateway çözümleri kullanılır.

### API Gateway Nedir?

API Gateway, istemciler (client) ile arka uç sistemleri (backend services) arasında bir proxy olarak görev yapan bir servis katmanıdır. Gelen istekleri uygun servis(ler)e yönlendirir, yanıtları toplayıp istemciye döner ve genellikle yük dengeleme, kimlik doğrulama, hız sınırlama (rate limiting), önbellekleme gibi ek özellikler de sunar.

Geleneksel olarak, istemci doğrudan birçok servisle iletişim kurarken, API Gateway bu ihtiyacı ortadan kaldırarak tüm dış bağlantıları üzeriden kendisi yönetir. Böylece istemciler sadece tek bir uç noktaya istek gönderir ve gerisini gateway'in yönettiği bir yapı elde edilir.

### API Gateway Ne İşe Yarar?

- **Güvenlik:** Kimlik doğrulama (authentication) ve yetkilendirme (authorization) işlemleri gateway seviyesinde yapılabilir.
- **Hız Sınırlama ve Trafik Kontrolü:** Rate limiting, circuit breaker ve retry mekanizmaları gateway seviyesinde uygulanabilir.
- **Servis Keşfi ve Yönlendirme:** API Gateway, servisleri dinamik olarak keşfedebilir ve routing yapabilir.
- **Yanıt Bileşimi (Response Aggregation):** Birden fazla servise yapılan çağrılar birleştirilip tek bir yanıt oluşturulabilir.
- **Versiyonlama:** Versiyon kontrolü yapılan API'lerin yönlendirmesi gateway üzerinden kolayca yönetilebilir.
- **Loglama ve İzleme:** Merkezi log toplama ve metrik üretme için gateway'ler kullanıcı davranışlarını kayıt altına alabilir.

### Yaygın API Gateway Çözümleri

Piyasada birçok açık kaynak ve ticarî API Gateway çözümü mevcuttur. Bu yazıda, iki popüler araç olan **NGINX** ve **Kong** üzerinde duracağız.

### NGINX ile API Gateway

NGINX, HTTP sunucusu olarak bilinse de, güçlü ters proxy (reverse proxy) ve yük dengeleme yetenekleri sayesinde bir API Gateway olarak da kullanılabilir.

#### Avantajları:

- Hafif ve hızlıdır.
- Geniş dökümantasyon ve stabilite sunar.
- Rate limiting, caching, gzip, SSL sonlandırma gibi yetenekleri içerir.
- Lua ile uzatılabilir yapıdadır (OpenResty tabanlı).

#### Kullanım Örneği:

```nginx
server {
  listen 80;

  location /users/ {
    proxy_pass http://user-service:3000/;
  }

  location /orders/ {
    proxy_pass http://order-service:4000/;
  }
}
```

Bu örnekte, /users/ endpoint'i gelen istekleri user-service'e yönlendirirken, /orders/ istekleri order-service'e yönlendirilmektedir. Basit bir yönlendirme yapılandırması dahi API Gateway davranışını taklit edebilir.

#### Dezavantajları:

- UI ya da dashboard yönetimi yoktur (ek araç gereklidir).
- Servis discovery desteği yerel olarak mevcut değildir.
- Gelişmiş plugin ekosistemi sınırlıdır.

### Kong API Gateway

Kong, açık kaynaklı, bulut yerel (cloud native) bir API Gateway çözümüdür ve üzerinde çalışan geniş bir plugin ekosistemiyle dikkat çeker. Go ve NGINX/OpenResty altyapılıdır.

#### Avantajları:

- Zengin plugin altyapısı (JWT auth, ACL, Rate Limiting, CORS, Prometheus Metrics, vb.)
- Admin API ile merkezi yönetim imkânı.
- Servis discovery, Load Balancing ve Health Check desteği.
- OpenAPI/Swagger entegrasyonu.
- Kong Manager adlı GUI panel mevcuttur (Kong Enterprise).

#### Kullanım Örneği (Kong Admin API)

Bir servis tanımlayıp route oluşturmak için aşağıdaki gibi bir istek gönderebilirsiniz:

```bash
curl -i -X POST http://localhost:8001/services \
  --data name=example-service \
  --data url='http://example.com'

curl -i -X POST http://localhost:8001/routes \
  --data service.name=example-service \
  --data paths[]=/example
```

#### Dezavantajları:

- Sistemi kurmak ve konfigüre etmek ilk aşamada karmaşık gelebilir.
- Enterprise versiyon ayrımı açık kaynak kullanıcıları için sınırlayıcı olabilir.

### NGINX vs Kong: Kıyaslama

| Özellik               | NGINX     | Kong           |
|----------------------|-----------|----------------|
| Performans           | Çok yüksek| Yüksek         |
| Plugin Ekosistemi    | Sınırlı   | Geniş          |
| Kullanım Kolaylığı   | Kolay     | Orta-Zor       |
| UI / Admin Panel     | Yok       | Var (Manager)  |
| Extensibility        | Lua ile   | Lua/Go plugin  |
| Rate Limiting        | Varsayılan| Varsayılan     |
| Service Discovery    | Yok       | Var            |
| Monitoring           | Dış araç  | Prometheus içn hazır plugin |

### API Gateway Seçiminde Dikkat Edilmesi Gerekenler

1. **Trafik Miktarı ve Performans Beklentisi:** Yüksek trafikli sistemlerde NGINX gibi düşük seviyeli kontrol iyidir, fakat ileri düzey ihtiyaçlar varsa Kong gibi platformlar tercih edilebilir.
2. **Sistem Karmaşıklığı:** Basit yönlendirme yeterliyse NGINX tercih edilebilir. Daha karmaşık kimlik yönetimi, istatistik toplama, gelişmiş plugin kullanımı gerekiyorsa Kong öne çıkar.
3. **Geliştirme Hızı ve Ekip Bilgisi:** NGINX daha kolay öğrenilebilirken, Kong daha fazla fonksiyonalite sunduğu için eğri daha diktir.
4. **Yönetim Arayüzü:** GUI ihtiyacı varsa Kong daha uygundur, NGINX için ek arayüzler kurmak gerekir.

### Sonuç

API Gateway mimarisi, mikroservis yapılarını yönetilebilir ve güvenli hale getirmede kritik rol oynar. NGINX ve Kong, bu amaçla yaygın ve güçlü çözümler sunmaktadır. NGINX performans ve yapılandırma kontrolü açısından öne çıkarken, Kong, plugin özellikleri ve yönetim arayüzü ile kompleks yapılarda avantaj sağlar. Uygulamanızın ölçeği, erişimi ve geliştirici becerileri doğrultusunda doğru API Gateway’i tercih etmek, sürdürülebilir ve esnek bir altyapı kurmanın anahtarıdır.

Makaleler