API Gateway Nedir? 30 Dakikada Tek Kapı Kurun

Meta Description

API Gateway nedir? Auth, routing, logging ve limit işlemlerini tek noktada toplayın. Nginx ile 30 dakikada örnek gateway kurun.

Giriş (Introduction)

Mikroservislere geçtikçe “tek bir API” sandığınız yapı, aslında birden fazla servis, farklı portlar, farklı URL’ler ve farklı güvenlik kuralları demek oluyor. Sonuç: Frontend ekipleri servis servis endpoint kovalıyor, mobil uygulamalar her sürümde kırılıyor, güvenlik kontrolleri her serviste tekrar ediliyor.

İşte bu noktada API Gateway devreye girer: İstemci ile servisleriniz arasına “tek kapı” koyar; yönlendirme (routing), kimlik doğrulama, hız limiti, gözlemlenebilirlik gibi çapraz ihtiyaçları merkezileştirir.

Bu yazıda API Gateway nedir sorusunu netleştirip, gerçek hayatta ne işe yaradığını görecek ve Nginx ile 30 dakikada çalışan bir API Gateway örneğini adım adım kuracaksınız.

---

API Gateway Nouting: API Gateway Nedir ve Ne İşe Yarar?

API Gateway, istemcilerin (web, mobil, partner entegrasyonları) mikroservislerinize doğrudan gitmesi yerine, tüm trafiği önce tek bir katmandan geçirmenizi sağlayan ara bileşendir.

Neden API Gateway kullanmalıyım?

“Bunu neden yapmalıyım?” sorusunun kısa cevabı: karmaşıklığı yönetmek ve riski düşürmek.

API Gateway ile genelde şunları tek yerde çözersiniz:

• Routing / Reverse Proxy: /users -> user-service, /orders -> order-service
• Authentication & Authorization: Token doğrulama, rol bazlı kontrol
• Rate Limiting / Quota: Abuse’ı engelleme, maliyeti kontrol etme
• Logging & Metrics: Trafiği, hata oranını, latency’yi izleme
• TLS termination: HTTPS yönetimini tek noktaya toplama
• Request/Response dönüşümü: Header ekleme, path rewrite, CORS

LSI anahtar kelimeler: reverse proxy, mikroservis mimarisi, routing, load balancing, TLS termination, request throttling, observability

---

API Gateway vs Reverse Proxy vs Load Balancer

Bu kavramlar karıştığı için net ayıralım:

Bileşen	Temel Amaç	Tipik Kullanım
Load Balancer	Trafiği çoklu instance’a dağıtmak	L4/L7 dağıtım, yüksek erişilebilirlik
Reverse Proxy	İstekleri arka servislere iletmek	Nginx/Traefik ile routing, SSL termination
API Gateway	API odaklı çapraz ihtiyaçlar	Auth, policy, rate limit, logging, versioning

Pratikte: Birçok ekip Nginx/Traefik ile başlayıp “API Gateway gibi” kullanır; ihtiyaç büyüdükçe Kong / Tyk / Apigee gibi ürünlere geçebilir.

---

Hangi Senaryolarda API Gateway Şart?

Aşağıdaki durumlar sizde varsa API Gateway ciddi değer katar:

1) Birden fazla client varsa

Web + iOS + Android + partner API gibi farklı istemciler farklı versiyon/istekler üretir. Gateway tek noktadan yönetim sağlar.

2) Mikroservis sayısı artıyorsa

Servis sayısı arttıkça:

• endpoint keşfi zorlaşır
• güvenlik tutarlılığı bozulur
• log/metric standardı kaybolur

3) Güvenlik ve uyum (compliance) baskısı varsa

Token doğrulama, IP allowlist, header sanitization gibi kontrolleri servis servis kopyalamak yerine gateway’de standartlaştırırsınız.

4) Trafik dalgalanması ve maliyet riski varsa

Gateway’de throttle/limit koyarak “ani patlamalarda” servislerinizi korursunuz.

---

30 Dakikada Nginx ile API Gateway Kurulumu (Adım Adım)

Aşağıdaki örnekte lokal ortamda 2 servis ve bir gateway ayağa kaldıracağız:

• user-service (port 3001)
• order-service (port 3002)
• api-gateway (port 8080)

Adım 1) Örnek servisleri hazırlayın

Basit Node.js servisleri ile ilerleyelim.

user-service (3001)

// user-service.js
import express from "express";
const app = express();

app.get("/health", (req, res) => res.json({ ok: true, service: "user" }));
app.get("/users/me", (req, res) => {
  res.json({ id: "u_123", name: "Ada" });
});

app.listen(3001, () => console.log("user-service on 3001"));

order-service (3002)

// order-service.js
import express from "express";
const app = express();

app.get("/health", (req, res) => res.json({ ok: true, service: "order" }));
app.get("/orders", (req, res) => {
  res.json([{ id: "o_1", total: 149.9 }]);
});

app.listen(3002, () => console.log("order-service on 3002"));

Gerçek hayatta bu servisler Kubernetes’te, ECS’te ya da VM üzerinde olabilir. Gateway mantığı değişmez.

Adım 2) Nginx’i gateway olarak konumlandırın

Bir Nginx config’i oluşturun: nginx.conf

events {}

http {

# Basit log formatı (gözlem için faydalı)
  log_format main '$remote_addr - $request_method $request_uri '
                  '$status $body_bytes_sent $request_time '
                  'upstream=$upstream_addr upstream_time=$upstream_response_time';

  access_log /var/log/nginx/access.log main;

# Upstream tanımları (servisleri soyutluyoruz)
  upstream user_service {
    server host.docker.internal:3001;
  }

  upstream order_service {
    server host.docker.internal:3002;
  }

  server {
    listen 8080;

# CORS (örnek; prod'da origin bazlı kısıtlayın)
    add_header Access-Control-Allow-Origin "*" always;
    add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;
    add_header Access-Control-Allow-Headers "Authorization, Content-Type, X-Request-Id" always;

    if ($request_method = OPTIONS) {
      return 204;
    }

# Basit "request id" üretimi (yoksa ekle)
    set $req_id $http_x_request_id;
    if ($req_id = "") {
      set $req_id $request_id;
    }
    add_header X-Request-Id $req_id always;

# Routing: /api/users/* -> user-service
    location /api/users/ {
      proxy_set_header X-Request-Id $req_id;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

# Path rewrite: /api/users/me -> /users/me
      rewrite ^/api/users/(.*)$ /$1 break;
      proxy_pass http://user_service;
    }

# Routing: /api/orders/* -> order-service
    location /api/orders/ {
      proxy_set_header X-Request-Id $req_id;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

      rewrite ^/api/orders/(.*)$ /$1 break;
      proxy_pass http://order_service;
    }

# Health endpoint (gateway'in kendisi için)
    location /health {
      return 200 "ok\n";
    }
  }
}

Adım 3) Gateway’i Docker ile çalıştırın

Nginx’i hızlıca ayağa kaldırmak için:

docker run --name api-gateway \
  -p 8080:8080 \
  -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf:ro \
  nginx:stable

Windows kullanıyorsanız path mount için PowerShell uyarlaması gerekebilir. Alternatif olarak WSL kullanın.

Adım 4) Test edin

Servisleriniz çalışıyorken:

curl http://localhost:8080/api/users/users/me
curl http://localhost:8080/api/orders/orders
curl http://localhost:8080/health

Beklenen:

• İstemci sadece 8080 portunu bilir.
• Servislerin portları/URL’leri dışarı sızmaz.

Adım 5) Gerçek hayata yakınlaştırma: Basit “API Key” kontrolü

Ürünleştirme yolunda ilk güvenlik katmanı olarak basit bir header kontrolü ekleyebilirsiniz.

Nginx içinde server bloğuna ek bir kontrol:

# Örnek: X-API-Key zorunlu olsun
set $api_key $http_x_api_key;
if ($api_key = "") {
  return 401;
}

Not: Bu sadece örnek. Üretimde genelde JWT doğrulama, mTLS, ya da ayrı bir auth service ile policy uygulanır.

---

API Gateway Tasarımında Kritik İpuçları (Prod Odaklı)

1) Gateway’i “tek hata noktası” yapmayın

• En az 2 instance
• Health check + otomatik restart
• Load balancer arkasında çalışma

2) Log ve metrikleri standartlaştırın

En azından şunları loglayın:

• X-Request-Id (trace için)
• status code
• upstream response time

3) Versiyonlama stratejisi belirleyin

Örn:

• /api/v1/users/...
• /api/v2/users/...

Gateway, eski client’ları kırmadan yönlendirme yapmayı kolaylaştırır.

4) Timeouts ayarlayın

Gateway’de makul timeout’lar servisleri korur:

• connect timeout
• read timeout
• retries (dikkatli kullanılmalı)

---

Gerçek Hayat Örneği: Tek Domain ile Mikroservis Yayını

Diyelim ki bir e-ticaret girişiminiz var:

• auth-service
• catalog-service
• payment-service
• order-service

Müşteri uygulaması sadece şunu bilir:

• https://api.sirketiniz.com/api/...

Servis taşınır, port değişir, hatta altyapı Kubernetes’e geçer… client bundan etkilenmez. Bu, özellikle mobil uygulamada (store onay süreçleri yüzünden) büyük avantajdır.

---

Sık Sorulan Sorular (FAQ)

1) API Gateway nedir, neyi çözer?

API Gateway, istemci ile servisler arasına girerek routing, güvenlik, limit ve gözlemlenebilirlik gibi çapraz ihtiyaçları tek noktada çözer.

2) Küçük projede API Gateway kullanmalı mıyım?

Tek servis ve tek client varsa şart değil. Ama endpoint sayısı artıyorsa veya güvenlik/izleme ihtiyacı doğduysa erken kurmak uzun vadede işleri kolaylaştırır.

3) Nginx ile API Gateway olur mu?

Evet. Nginx iyi bir başlangıçtır: reverse proxy + routing + temel policy’ler. İhtiyaç büyüyünce Kong/Tyk/Apigee gibi API gateway ürünleri değerlendirilebilir.

4) API Gateway performansı düşürür mü?

Doğru konfigürasyonla genellikle kabul edilebilir bir ek gecikme olur. Buna karşılık caching, connection reuse ve merkezi kontrol ile toplam sistem daha stabil hale gelir.

---

Sonuç

API Gateway, mikroservislerin önüne koyduğunuz “tek kapı”dır: routing, güvenlik, log/izleme ve standartlaştırma sayesinde hem geliştirici deneyimini hem de operasyonel kontrolü iyileştirir.

Bugün:

• API Gateway nedir sorusunu netleştirdiniz,
• Nginx ile çalışan bir gateway’i kurdunuz,
• Gerçek hayatta hangi noktalarda şart olduğunu gördünüz.

Bir sonraki adım: Kendi projenizde 2–3 endpoint’i gateway arkasına alın, X-Request-Id ile logları birleştirin ve routing’i versiyonlayın. Denediğiniz yapıyı veya yaşadığınız problemi yorum olarak yazın; birlikte iyileştirelim.