React, Vue ve Angular Single Page Application’ları Aynı Alan Adında API ile Host Etmek: Nginx Yönlendirme ve SSL Mimarisi

Tek Alan Adı, Çoklu SPA ve API: Neden Uğraşmaya Değer?

Bir projede React ile bir yönetim paneli, Vue ile müşteri arayüzü, Angular ile de iç süreçlerin yönetildiği bir dashboard geliştirdiğinizi düşünün. Bir noktada şu soruya geliyorsunuz: “Tüm bu Single Page Application (SPA) projelerini ve API’yi tek alan adında, düzenli, güvenli ve performanslı şekilde nasıl host ederiz?” İşte bu noktada Nginx, doğru yönlendirme (routing) stratejisi ve sağlam bir SSL mimarisi oyuna giriyor.

SPA yapıları genelde statik dosyalara derleniyor; bunları hızlı bir web sunucusundan yayınlayıp, arka tarafta Node.js, PHP, .NET veya başka bir stack ile çalışan API’ye reverse proxy üzerinden istek geçirmek çok yaygın bir yaklaşım. Aynı alan adını kullanmak; CORS (cross-origin) karmaşasını azaltıyor, cookie tabanlı oturum yönetimini sadeleştiriyor, SEO ve marka algısını güçlendiriyor. Biz DCHost tarafında, müşterilerin React/Vue/Angular + API kombinasyonlarını tek domain altında, ölçeklenebilir ve güvenli bir şekilde çalıştırması için sık sık mimari tasarım desteği veriyoruz.

Bu yazıda; örnek Nginx konfigürasyonları, SSL/HTTPS stratejileri, history mode kaynaklı 404 tuzakları, performans ve dağıtım (deploy) pratiklerine kadar, tek alan adında çoklu SPA + API mimarisini adım adım ele alacağız. Hedefimiz: Gerçek dünyada uygulanabilir, kopuk değil bütün bir çözüm anlatmak.

Genel Mimari: React, Vue, Angular ve API’yi Nereye Yerleştiriyoruz?

Önce temel resmi netleştirelim. Basit ama güçlü bir senaryodan gidelim:

• Alan adınız: example.com
• React uygulaması: example.com/react
• Vue uygulaması: example.com/vue
• Angular uygulaması: example.com/panel
• API: example.com/api

Burada tüm trafik tek bir Nginx sunucusuna geliyor. Nginx:

• Statik SPA dosyalarını diskten doğrudan servis ediyor,
• /api altındaki istekleri arka plandaki API sunucularına reverse proxy ile iletiyor,
• HTTP isteklerini HTTPS’e yönlendiriyor ve TLS (SSL) bağlantısını sonlandırıyor.

Alan adı, DNS ve SSL’in birlikte nasıl çalıştığını daha temel seviyede hatırlamak isterseniz, domain, DNS, sunucu ve SSL’in birlikte nasıl çalıştığını anlattığımız detaylı rehbere de göz atabilirsiniz.

Bu mimariyi DCHost üzerinde bir VPS, dedicated sunucu veya colocation ortamında rahatlıkla kurabilirsiniz. paylaşımlı hosting yerine Nginx konfigürasyonuna tam erişiminiz olan bir ortam, bu tip gelişmiş routing senaryoları için çok daha esneklik sağlar.

Nginx ile Yönlendirme: /react, /vue, /panel ve /api Ayrımı

Şimdi işin kalbine, yani Nginx konfigürasyonuna gelelim. Örnek bir yapı üzerinden gideceğiz. Varsayalım ki SPA derleme çıktılarınız şu dizinlerde:

• React build: /var/www/react
• Vue build: /var/www/vue
• Angular build: /var/www/panel

API’niz de 127.0.0.1:4000 üzerinde çalışan bir Node.js uygulaması olsun.

Temel server bloğu

server {
    listen 80;
    server_name example.com;

    # Tüm HTTP trafiğini HTTPS'e yönlendir
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Ortak ayarlar (gzip, security header vs.)
    # include /etc/nginx/snippets/common.conf;

    # React SPA
    location /react/ {
        root /var/www/;
        try_files $uri $uri/ /react/index.html;
    }

    # Vue SPA
    location /vue/ {
        root /var/www/;
        try_files $uri $uri/ /vue/index.html;
    }

    # Angular SPA
    location /panel/ {
        root /var/www/;
        try_files $uri $uri/ /panel/index.html;
    }

    # API reverse proxy
    location /api/ {
        proxy_pass         http://127.0.0.1:4000/;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

Buradaki kritik nokta, her SPA için try_files direktifini kullanmamız. Bu sayede, React Router, Vue Router veya Angular Router history mode kullanırken; tarayıcı doğrudan /react/dashboard gibi bir URL’ye gittiğinde, Nginx fiziksel bir dosya bulamazsa ilgili index.html dosyasına geri düşüyor.

History Mode ve 404 Tuzakları

SPA’ların en sık yaşattığı sorunlardan biri, tarayıcıdan doğrudan derin bir URL’ye gidildiğinde (örneğin /vue/orders/123) 404 alınmasıdır. Bunun sebebi; bu path’in sunucu tarafında gerçek bir dosya veya klasör olarak bulunmamasıdır. History mode ile çalışan router, bu URL’yi aslında front-end tarafında çözümler; Nginx’in görevi sadece her şeyi doğru index.html’e düşürmektir.

Bu noktada iki şeye dikkat etmelisiniz:

• SPA path’lerini önceden tanımlamak: location /react/, /vue/, /panel/ gibi.
• Önce gerçek dosyaları denemek, sonra index’e dönmek: try_files $uri $uri/ /react/index.html;

Eğer path tabanlı değil de kök dizinde tek bir SPA yayınlıyor olsaydınız (/), konfigürasyon şu şekilde basitleşebilirdi:

location / {
    root /var/www/react;
    try_files $uri $uri/ /index.html;
}

API İçin Reverse Proxy Ayrıntıları

/api/ için reverse proxy kullanırken, sadece proxy_pass yazmak genelde yetmez; doğru header’ları da iletmeniz gerekir. En temel set şu şekildedir:

location /api/ {
    proxy_pass         http://127.0.0.1:4000/;

    proxy_set_header   Host              $host;
    proxy_set_header   X-Real-IP         $remote_addr;
    proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto $scheme;
}

Arka plandaki Node.js veya başka bir API framework’ü, gerçek istemci IP’si ve HTTP şemasını (http/https) bu header’lar sayesinde doğru görür. API’nizi Node.js ile kuruyorsanız, Node.js’i Nginx ve SSL ile canlıya alma rehberimizde reverse proxy tarafındaki pek çok ayrıntıyı uygulamalı şekilde görebilirsiniz.

SSL ve HTTPS Mimarisi: Tek Sertifika ile Çoklu SPA

Hem SPA’lar hem API aynı alan adında olduğunda, işin güzel tarafı SSL tarafında işler oldukça sadeleşir: Tek bir sertifika ile her şeyi güvenli hale getirebilirsiniz.

Senaryomuzda tüm trafiğimiz example.com üzerinde dönüyor. Yani ihtiyacımız olan, bu alan adını kapsayan bir SSL sertifikası (DV, OV veya EV). Eğer api.example.com, app.example.com gibi alt alan adları da işin içine girecekse, o zaman wildcard (*.example.com) veya SAN (Subject Alternative Name) içeren bir sertifika düşünmek mantıklı hale gelir.

Modern TLS özellikleri (TLS 1.3, OCSP Stapling, güçlü şifre paketleri, HSTS vb.) için Nginx tarafında atılacak adımları merak ediyorsanız, Nginx’te TLS 1.3, OCSP Stapling ve Brotli kurulumunu anlattığımız rehbere mutlaka göz atın.

HTTP’den HTTPS’e Yönlendirme ve HSTS

Çoklu SPA mimarisinde dahi, HTTP → HTTPS geçişi klasik kalıpları takip eder. Örneğimizde ilk server bloğu zaten tüm HTTP isteklerini 301 ile HTTPS’e yönlendiriyor.

SEO etkilerini ve HSTS (HTTP Strict Transport Security) kullanımını da düşünmek isterseniz, HTTP’den HTTPS’e geçişi, 301 yönlendirme ve HSTS ile SEO’yu nasıl koruyacağınızı detaylı anlattığımız yazımız iyi bir tamamlayıcı olacaktır.

Özetle: SPA’larınız hangi path’te olursa olsun, HTTPS katmanı Nginx’te tek bir yerde sonlanır; gerisi tamamen yönlendirme ve root ayarlarından ibarettir.

CORS, Çerezler ve Kimlik Doğrulama: Aynı Alan Adının Gücü

SPA + API mimarisinde geliştiricilerin en çok zorlandığı konulardan biri CORS ve cookie ayarlarıdır. API’nizi başka bir domain veya portta tuttuğunuzda, tarayıcı bunu “farklı origin” olarak görür ve:

• Preflight (OPTIONS) istekleri,
• CORS header’ları (Access-Control-Allow-Origin vb.),
• SameSite, Secure, HttpOnly gibi cookie bayrakları

gündeme gelir. API’yi example.com/api altında tuttuğunuzda ise tarayıcı gözünde her şey aynı origin’dedir; bu da CORS karmaşasını büyük ölçüde ortadan kaldırır. Böylece cookie tabanlı session veya JWT + cookie yaklaşımını çok daha zahmetsiz yönetebilirsiniz.

Özellikle kimlik doğrulama için cookie kullanıyorsanız, SameSite ve Secure bayraklarını doğru ayarlamak kritik hale gelir. Bu konuda daha derine inmek isterseniz, SameSite, Secure ve HttpOnly bayraklarını Nginx/Apache üzerinde nasıl doğru kurgulayacağınızı anlattığımız rehberi inceleyebilirsiniz.

Performans ve Önbellekleme: SPA’ları Uçurmak

SPA’lar statik dosyalardan oluştuğu için, Nginx gibi yüksek performanslı bir HTTP sunucusunun en sevdiği iş yükünü temsil ederler. Doğru yapılandırmayla hem TTFB’yi düşürmek hem de istemci tarafı önbelleklemeden maksimum verim almak mümkün.

Statik dosyalar için Cache-Control başlıkları

Derlenmiş JavaScript ve CSS dosyaları genellikle hash’li isimlere sahiptir (ör. app.7f3a2c.js). Bu sayede, uzun süreli önbellekleme yapmak güvenli hale gelir:

location ~* .(js|css|png|jpg|jpeg|gif|svg|ico)$ {
    root /var/www/;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

Bu ayar, özellikle mobil ve düşük bağlantı hızına sahip kullanıcılar için yeniden yükleme sürelerinde ciddi fark yaratır.

Gzip/Brotli ve HTTP/2/3

SPA paketleri genellikle büyük JavaScript bundle’larından oluştuğu için, sıkıştırma (gzip veya brotli) büyük kazanımlar sağlar. Aynı şekilde HTTP/2 veya HTTP/3 (QUIC) kullanmak, çok sayıda küçük dosyanın paralel indirilmesinde avantaj sunar.

Nginx tarafında modern TLS ve Brotli’yi nasıl etkinleştireceğinizi adım adım görmek için, tekrar Nginx + TLS 1.3 + Brotli rehberimize bakabilirsiniz. Oradaki prensipleri doğrudan bu SPA mimarisine uygulayabilirsiniz.

Dağıtım (Deploy) Stratejisi: Zero-Downtime Yayın Akışı

Tek alan adında çoklu SPA ve API kullanıyorsanız, en kritik konulardan biri de güncelleme sırasında kesinti yaşamamaktır. Özellikle canlı trafikli projelerde kullanıcıya 500 hata göstermek istemezsiniz.

Sürümlenmiş dizinler ve sembolik link yaklaşımı

DCHost üzerinde sıkça kullandığımız pratik bir yöntemden bahsedelim:

1. Her deploy’da yeni bir klasör: /var/www/react-20241201-1 gibi.
2. Stabil bir sembolik link: /var/www/react-current linki daima son çalışan sürümü işaret eder.
3. Nginx konfigürasyonu: Root olarak her zaman react-current gösterilir.
4. Yeni sürüm hazır olduğunda: react-current linkini yeni dizine çevirip Nginx’i reload edersiniz.

Bu sayede Nginx bir anda yeni dosyaları servis etmeye başlar; eski bağlantılar ise doğal ömürlerini tamamlayana kadar eski sürümden cevap alabilir.

Sıfır kesinti CI/CD süreci kurmak istiyorsanız, sembolik link + rsync + systemd kombinasyonunu anlattığımız VPS’e sıfır kesinti CI/CD kurulumu rehberimize mutlaka göz atın; oradaki yaklaşımı SPA build’lerinize kolayca uyarlayabilirsiniz.

API için blue/green veya canary yaklaşımları

API tarafında risk daha yüksek olduğu için, blue/green veya canary deployment stratejileri kullanmak mantıklı olabilir. Örneğin:

• api_v1 upstream’ine giden trafiği yavaş yavaş api_v2 upstream’ine kaydırmak,
• Belirli IP aralıklarını veya header’ları yeni sürüme yönlendirip küçük bir kullanıcı grubuyla denemek,
• Hata durumunda hızlı rollback yapabilecek bir konfigürasyon hazırlamak

Bu konuyu daha derinlemesine ele aldığımız, Nginx ağırlıklı canary dağıtım stratejilerini içeren rehberlerimiz de mevcut; ihtiyacınıza göre DCHost ekibiyle birlikte size özel bir plan da çıkarabiliriz.

DCHost Üzerinde Örnek Bir Senaryo

Gerçekçi bir örnek kuralım. Diyelim ki bir SaaS ürününüz var:

• Müşteri arayüzü: React ile yazılmış, /app altında.
• Yönetim paneli: Vue ile yazılmış, /admin altında.
• Raporlama modülü: Angular ile yazılmış, /reports altında.
• REST API: Node.js + PostgreSQL, /api altında.

DCHost’ta orta seviye bir NVMe VPS üzerinde aşağıdaki yapıyı kurabilirsiniz:

• Nginx: 443 portunda TLS sonlandırma, /app, /admin, /reports için statik dosya servisi, /api için reverse proxy,
• Node.js API: 127.0.0.1:4000 üzerinde, PM2 veya systemd ile yönetiliyor,
• PostgreSQL: Aynı VPS’te veya ayrı bir veritabanı VPS’inde,
• Yedekleme: Günlük veritabanı dump’ı + haftalık tam yedek, S3 uyumlu depolama veya ikinci bir lokasyona kopyalanıyor.

Bu mimariyi üretim ortamına alırken; DNS, SSL, yedekleme ve RPO/RTO hedeflerinizi de planlamayı unutmayın. Özellikle blog, e-ticaret veya SaaS projelerinde yedekleme stratejisini nasıl planlayacağınızı merak ediyorsanız, RPO/RTO odaklı yedekleme rehberimizi inceleyebilirsiniz.

DNS, TTL ve Taşıma Senaryoları

Bazen var olan bir projeyi farklı bir mimariye taşırken, örneğin üç ayrı sunucuda çalışan React, Vue ve Angular uygulamalarını DCHost’ta tek bir Nginx arkasında toplarken, DNS ve TTL ayarları kritik hale gelir. Yanlış planlanmış bir DNS geçişi; kullanıcıların bir kısmının eski, bir kısmının yeni ortama gitmesine yol açabilir.

Bu gibi geçişlerde:

• Geçişten birkaç gün önce TTL değerlerini düşürmek,
• Taşıma sırasında kaynak IP değişimini dikkatlice zamanlamak,
• Geçiş tamamlandıktan sonra TTL’i tekrar makul seviyelere yükseltmek

işinizi çok kolaylaştırır. Zero-downtime DNS stratejilerini detaylı anlattığımız TTL ve DNS yayılımı odaklı rehberimiz, özellikle SPA + API altyapısını yeni bir ortama taşırken elinizin altında olmalı.

Güvenlik ve Bakım: Loglar, WAF ve Güncellemeler

Tek alan adında birden fazla SPA ve API barındırırken, güvenlik perspektifini de bütün olarak düşünmek gerekir:

• Access ve error log analizi: 4xx–5xx hataları, beklenmedik pattern’leri görmek için düzenli log incelemesi yapın.
• WAF ve rate limiting: Brute-force, tarama (scan) ve kötü niyetli bot trafiğini sınırlamak için Nginx rate limiting veya harici bir WAF kullanın.
• SSL ve protokol güncellemeleri: TLS versiyonlarını ve şifre paketlerini periyodik olarak gözden geçirin.
• Yedekler ve test restore: Sadece yedek almak değil, geri yükleme sürecini test etmek de kritik.

SSL tarafında hangi tür sertifikanın (DV, OV, EV, wildcard) hangi senaryoda mantıklı olduğunu ve güvenlik güncellemelerini hangi sıklıkla yapmanız gerektiğini anlamak için, SSL sertifikasının temel kavramlarını anlattığımız rehbere ve SSL/TLS protokol güncellemeleriyle ilgili yol haritası yazımıza da göz atabilirsiniz.

Sonuç: SPA’larınızı Toplayın, Mimariniz Sadelessin

React, Vue ve Angular ile geliştirdiğiniz farklı SPA’ları ve bunlara hizmet veren API’yi aynı alan adında toplamak ilk bakışta karmaşık görünebilir; ama doğru Nginx yönlendirme kuralları ve sağlam bir SSL/HTTPS mimarisiyle, aslında işleri sadeleştirirsiniz. CORS ve cookie problemleri azalır, dağıtım süreçleriniz daha tutarlı hale gelir, monitoring ve güvenlik politikalarınızı tek bir giriş noktasında merkezileştirebilirsiniz.

DCHost’ta, ister tek bir NVMe VPS üzerinde, ister ayrı API ve veritabanı sunucularına bölünmüş daha gelişmiş bir mimaride çalışın; Nginx reverse proxy, TLS yapılandırması, yedekleme ve ölçeklendirme konularında yanınızdayız. Mevcut projenizi bu yapıya taşımayı veya yeni projenizi baştan böyle kurgulamayı düşünüyorsanız, altyapı ihtiyaçlarınızı birlikte değerlendirebilir, size özel bir plan çıkarabiliriz.

İsterseniz bugün küçük bir pilot ortamla başlayın: Tek bir domain, tek bir Nginx, bir React veya Vue uygulaması ve basit bir API. Mimarinin oturduğunu gördükçe, Angular panelinizi, yeni modüllerinizi ve ek servislerinizi de aynı iskelete güvenle ekleyebilirsiniz.