Edge Computing Nedir ve Frontend Neden Artık Sunucuya İhtiyaç Duymuyor?

Bir kullanıcı İstanbul'dan, diğeri São Paulo'dan aynı web uygulamasını açıyor. İkisi de aynı sunucuya istek gönderiyor — diyelim ki Virginia, AWS us-east-1. İstanbul kullanıcısı 180ms gecikme yaşarken São Paulo kullanıcısı 250ms bekliyor.

Bu gecikmenin yarısı kaçınılmaz değil. Sadece sunucunun yanlış yerde olmasından kaynaklanıyor.

Edge computing'in çözdüğü temel sorun bu: kodu kullanıcıya götürmek, kullanıcıyı koda değil.

1. "Edge" Ne Demek, Tam Olarak?

Edge, ağın "kenarı" — yani kullanıcıya en yakın fiziksel nokta. Cloudflare'in edge ağı bugün 300'den fazla şehirde çalışıyor. Bir kullanıcı İzmir'den istek attığında yanıt Amerika'daki bir sunucudan değil, birkaç yüz kilometre ötedeki bir düğümden geliyor.

Klasik mimaride süreç şöyle işliyor:

Kullanıcı → CDN (statik dosyalar) → Origin Server (dinamik içerik) → Veritabanı

Edge mimaride ise:

Kullanıcı → Edge Node (hem statik hem dinamik) → Veritabanı (edge-uyumlu)

Aradan bir katman kalkıyor. Sadece hız değil, maliyet ve karmaşıklık da azalıyor.

2. Cloudflare Workers ve Vercel Edge Functions Ne Yapıyor?

İkisi de aynı fikri farklı ekosistemlerle sunuyor: küçük JavaScript/TypeScript fonksiyonlarını edge düğümlerinde çalıştırmak.

Cloudflare Workers daha çok bir platform. Kendi KV store'u (Workers KV), kendi veritabanı (D1, SQLite tabanlı), kendi blob depolaması (R2) var. Teorik olarak bir uygulamayı tamamen Cloudflare altyapısında çalıştırabilirsiniz — origin sunucusu olmadan.

Vercel Edge Functions ise Next.js ile daha sıkı entegre çalışıyor. Middleware'i edge'de çalıştırmak, A/B testini sunucu tarafında yapmak, coğrafi yönlendirme — bunları framework seviyesinde kolaylaştırıyor.

Pratik fark şu: Cloudflare daha fazla kontrol sunuyor ama daha fazla şeyi kendiniz yapılandırıyorsunuz. Vercel'de daha az sürtünme var ama ekosisteme bağımlısınız.

3. Peki Ya "Sunucusuz Frontend" İddiası?

"Frontend artık sunucuya ihtiyaç duymuyor" cümlesini biraz açmak lazım.

Statik site üretimi (SSG) zaten yıllardır var. Gatsby, Hugo, Eleventy — bunlar zaten sunucu gerektirmiyor. Bu yeni değil.

Asıl değişen şu: dinamik içerik de artık origin sunucusu gerektirmiyor.

Kullanıcıya özel içerik sunmak istiyorsunuz diyelim — sepet bilgisi, oturum durumu, coğrafi fiyatlandırma. Klasik yaklaşımda bunu bir API sunucusu yapardı. Şimdi bunu edge middleware'de halledebiliyorsunuz. Cookie okuyorsunuz, isteği yönlendiriyorsunuz, header ekliyorsunuz — hepsi kullanıcının en yakın düğümünde, origin'i hiç uyandırmadan.

Next.js'in middleware.ts dosyası tam bu işi yapıyor. Vercel'e deploy ettiğinizde bu dosya edge'de çalışıyor, Türkiye'den gelen bir kullanıcı için Türkçe içeriği otomatik döndürüyor.

4. Sınırlar Neler?

Edge cazip görünüyor ama bazı şeyleri yapamıyor — ya da yapmamalı.

Node.js API'larının tamamı desteklenmiyor. Edge runtime güvenlik ve performans nedeniyle kısıtlı bir ortamda çalışıyor. fs, child_process, bazı crypto metodları yok. Bunu fark etmeden canlıya almak hoş değil.

Veritabanı bağlantısı hâlâ sorunlu. Geleneksel PostgreSQL bağlantısı (connection pool ile) edge'de çalışmıyor. HTTP üzerinden çalışan alternatifler gerekiyor: PlanetScale, Neon, Turso. Bu alternatiflerin olgunluk seviyesi değişiyor ve bazıları production'da sürpriz yapabiliyor.

Cold start sorunu bitmedi. Edge fonksiyonlar klasik Lambda'dan hızlı başlıyor ama sıfır değil. Cloudflare Workers bu konuda daha iyi durumda, Vercel edge fonksiyonları bazen değişken davranabiliyor.

Her şeyi edge'e taşımak mantıklı değil. Ağır hesaplama, büyük veri işleme, karmaşık veritabanı sorguları — bunlar origin sunucusuna ait. Edge'in gücü basit, hızlı, sık çalışan işlemlerde.

5. Gerçek Bir Senaryo: A/B Testi Edge'de

Landing page'inizin iki versiyonunu test ediyorsunuz. Klasik yöntemde ya client-side JavaScript ile yapıyorsunuz (layout shift, flickering riski) ya da bir feature flag servisi kullanıyorsunuz (ek gecikme, ek maliyet).

Edge middleware ile şöyle oluyor:

// middleware.ts (Next.js)
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const bucket = request.cookies.get('ab-bucket')?.value ?? 
    (Math.random() > 0.5 ? 'a' : 'b')
  
  const response = NextResponse.rewrite(
    new URL(`/landing-${bucket}`, request.url)
  )
  
  response.cookies.set('ab-bucket', bucket, { maxAge: 60 * 60 * 24 * 30 })
  return response
}

Kullanıcı isteği edge'e geliyor, bucket atanıyor, doğru sayfa döndürülüyor — origin sunucusu devreye girmeden. Layout shift yok, ekstra gecikme yok, harici servis bağımlılığı yok.

Sonuç

Edge computing'i bir hype olarak değil, araç kutusuna eklenen bir katman olarak görmek mantıklı. Her uygulamayı edge-first yazmak ne gerekli ne de her zaman mümkün.

Ama doğru yerde — kimlik doğrulama, yönlendirme, coğrafi özelleştirme, basit API proxy'leri — gerçekten işe yarıyor.

Vercel ve Cloudflare bu konuda geliştirici deneyimini oldukça ileriye taşıdı. Ekosistem olgunlaştıkça, özellikle edge-native veritabanları yaygınlaştıkça, "origin sunucusu olmadan full-stack uygulama" iddiası daha az teorik daha çok pratik olmaya başlayacak.

Şu an için en makul yaklaşım: statik içeriği CDN'de, hafif dinamik mantığı edge'de, ağır işlemleri origin'de tutmak. Üç katmanın da ne zaman devreye gireceğini bilmek.

Projelerinizde bu mimariyi nasıl kurabileceğinizi konuşmak isterseniz iletişim sayfamdan ulaşabilirsiniz.