Gelecek Manzarası: Edge Computing ve Ötesi

Frontend build tooling, bundler hızının artık geliştirici deneyimini sınırlayan asıl etken olmadığı bir eşiği geçti; sıradaki sınır, build tooling’in kodun nerede ve nasıl çalışacağıyla nasıl etkileşeceği. Edge runtime’lar, deployment platformları ve framework seviyesindeki temel yapılar (React Server Components, streaming SSR, partial hydration), build boru hattını artık bundler’ın kendisi kadar etkiliyor. “Build” ile “deploy” arasındaki sınır, tek bir sunucuyu değil bir runtime kümesini hedefleyen tek bir boru hattına dönüşüyor.

Hareketli parçalar şunlar: edge-first build modeli, platformla bütünleşik framework’ler (Vercel, Cloudflare, Netlify) ve runtime’dan bağımsız bundling’den runtime’a özel artifact’lara geçiş. Build ile platform arasındaki bağın ne kadar sıkı olması gerektiği hâlâ açık bir soru; verilen yanıt, ortaya çıkan uygulamanın ne kadar taşınabilir olacağını belirliyor.

Edge Computing: Hesaplama Ağa Taşınıyor (2022-Şimdi)#

Edge computing’in ortaya çıkışı, frontend tooling’in neyi optimize ettiğini değiştirdi. Ama yanında sıkça anılan response sürelerini getirmedi.

CDN’den Edge Compute’a#

// 2020: CDN'den serve edilen statik dosyalar
// React app'iniz: en yakın CDN node'undan serve edilen bundle.js

// 2025: Edge'de kod execution
export default {
  async fetch(request, env) {
    // Sağlayıcının ağı genelinde çalışıyor
    const response = await handleRequest(request);
    return response;
  }
}

Ne değişti:

• Cold start’lar. Cloudflare’in cold start’ları ortadan kaldırma üzerine 2020 tarihli yazısı, Workers’ın arkasındaki isolate teknolojisinin bir function’ı 5 milisaniyenin altında ısıttığını söylüyor; karşısına da “tam saniyeler sürebilen” serverless container’ları koyuyor. Karşılaştırmanın container tarafı, Cloudflare’in bir rakibi anlatması. AWS kendi rakamını yayımlıyor ve bu bir aralık: “bir cold start’ın süresi 100 ms’nin altından 1 saniyenin üstüne kadar değişiyor”. “Tam saniyeler” ifadesine yanıt veren yalnızca aralığın üst ucu ve AWS o ucu açık bırakıyor. Bir cold start 1 saniyeyi geçebiliyor; dokümantasyon bir üst sınır vermiyor. Yani container tarafı bir niteleme olarak kalıyor; arkasında bir ölçüm yok.
• Dağıtım. Erişim genişliği sağlayıcılar arasında bir büyüklük mertebesi farklılaşıyor. Cloudflare’in ağ sayfası 348 şehir sayıyor; Vercel’in bölge dokümantasyonu 126’nın üzerinde point of presence ama yalnızca 20 compute yapabilen bölge listeliyor; Deno Deploy Classic ise altı bölgede çalışıyordu.
• Request handling. Uzun ömürlü bir server süreci olmadan dinamik yanıtlar; en iyi ayakta kalan değişiklik bu.

Platform Integration Devrimi#

Modern platform’lar kodunuzu deploy etmekle kalmıyor; nasıl yazdığınızı yeniden şekillendiriyor:

// Vercel Edge Functions
import { geolocation } from '@vercel/functions';

export default function handler(request) {
  // Bölge ayarıyla değil, platform tarafından yerleştiriliyor
  // Sıfır configuration gerekli
  // TypeScript desteği built-in
  const { city } = geolocation(request);
  return new Response(`Hello from ${city}!`);
}

// Cloudflare Workers (module sözdizimi)
export default {
  fetch(request, env, ctx) {
    // Cloudflare'in ağında V8 isolate'lerde çalışıyor
    // Bölge bazlı bir deployment adımı yok
    return handleRequest(request);
  }
};

// Deno Deploy
Deno.serve((request) => {
  // TypeScript-first edge runtime
  // Her yerde native Web API'ları
  return new Response("Powered by Deno");
});

Gecikme Rakamları Ne Söylüyor#

Yayımlanmış iki veri kümesi sorunu iki yandan çerçeveliyor ve ikisi de edge pazarlamasına eşlik eden yuvarlak sayıları vermiyor.

Microsoft, Azure omurgası için ölçülmüş bir gecikme matrisi yayımlıyor. Sayfa, değerlerin dahili ağ problarınca bir dakikalık aralıklarla toplanan gidiş dönüş ölçümlerinin 50. yüzdeliği olduğunu ve 30 Temmuz 2026’da biten 30 günlük pencereyi kapsadığını belirtiyor:

Bölge çifti	P50 gidiş dönüş süresi
East US - Southeast Asia (Singapur)	224 ms
East US - UK South (Londra)	78 ms
Australia East - East US	202 ms
East US - West Europe	85 ms
East US - Germany West Central (Frankfurt)	94 ms
Australia East - Germany West Central	267 ms
Southeast Asia - Germany West Central	166 ms

Bunlar özel bir omurga üzerinde veri merkezinden veri merkezine sürelerdir; yani bir taban değerdir. Ev internetindeki bir kullanıcı bu değerlerin üstünde kalır.

Yakınlık tarafında Cloudflare’in ağ sayfası, dünyanın internete bağlı nüfusunun %95’inin bir Cloudflare veri merkezine 50 milisaniye içinde olduğunu, çoğununsa 20 ms içinde bulunduğunu ve bunun 348 şehir üzerinden sağlandığını söylüyor. Bu rakam, kullanıcının en yakın point of presence’a olan mesafesini ölçüyor. Uygulamanın ardından ne kadar sürede yanıt verdiği hakkında hiçbir şey söylemiyor.

Ölçülmüş son kullanıcı gecikmesi iki ayrı sütun olarak veriliyor ve bunlardan yalnızca biri karşılaştırılabilir. Cloudflare Radar’ın dünya genelinde yapılan hız testlerinden derlediği 2025 yıl değerlendirmesi, en düşük ortalama boştaki gecikmeyi 13 ms ile İzlanda’da, 2 ms arkasında 15 ms ile Moldova’da buluyor. Bunlar, başka yük taşımayan bir bağlantıdaki gidiş dönüş süreleri; yakınlık iddiasının anlattığı büyüklük de bu. Diğer sütun, bant genişliği testi hattı doldururken ölçülen yük altındaki gecikme: orada ilk sırayı 73 ms ile Moldova alıyor, Macaristan, İspanya, Belçika, Portekiz, Slovakya ve Slovenya ise 100 ms’nin altında kalıyor. İki sütun arasındaki fark, kullanıcının kendi erişim hattındaki kuyruklanma. İkisi de, istek ulaştıktan sonra uygulamanın ne kadar sürede yanıt verdiğini ölçmüyor.

Yani edge iddiasının savunulabilir hâli, alışılmış hâlinden dar. Hesaplamayı ağa koymak, istek yolundan kıtalararası bir gidiş dönüşü çıkarıyor ve 224 ms’lik East US - Singapur sıçraması, çıkarılmaya değer gerçek bir maliyet. Yaptığı şey, yanıtın altındaki ağ tabanını indirmek; uygulamanın kendi işi hâlâ bu tabanın üstünde duruyor. Bu çıkarmanın kazandırdığı şey, eskiden istek yolunda mümkün olmayan bir iş sınıfı: kişiselleştirme ve A/B kararları artık hydration sonrasında değil, yanıt yazılmadan önce alınabiliyor.

Build-Deploy Yakınsaması (2023-2025)#

Edge computing olgunlaştıkça, build tool’lar ve deployment platform’lar arasındaki çizgi bulanıklaşmaya başladı.

Framework-First Deployment#

// Next.js on Vercel, depo bir kez içe aktarıldıktan sonra
git push origin main
// Otomatik olarak:
// - Next.js'i detect eder
// - Framework'ün build preset'ini uygular
// - CDN ve function'ları kurar
// - PR'lar için preview deployment'ları etkinleştirir

// Nuxt on Netlify
npm run build
// Otomatik olarak:
// - Netlify Edge için optimize eder
// - Form'ları ve function'ları configure eder
// - Split testing kurar
// - Environment variable'ları yönetir

Zero-Config Deployment Çağı#

Deployment yolu iki adımda kısaldı.

2015, manuel server konfigürasyonu: EC2 instance provision et, Node.js ve bağımlılıkları kur, nginx reverse proxy yapılandır, SSL sertifikalarını al, monitoring ve logging’i bağla.

2020, container tabanlı deployment: Dockerfile yaz, Kubernetes manifest’lerini yapılandır, CI/CD pipeline kur, ölçeklemeyi ve health check’leri yönet.

2025, git tabanlı deployment: depoyu platforma bir kez bağlayın, sonrası git push origin main. Platform, depoda tespit ettiği framework’ten geri kalanını kendisi çıkarıyor.

Infrastructure as Code’un Evrimi#

// Geleneksel Infrastructure as Code
const server = new aws.ec2.Instance("web-server", {
  instanceType: "t3.medium",
  ami: "ami-0abcdef1234567890",
  // 50+ satır configuration...
});

// Modern platform yaklaşımı
export default defineNuxtConfig({
  nitro: {
    preset: 'cloudflare-pages'
  }
  // Platform infrastructure'ı otomatik handle ediyor
});

AI, Build Boru Hattına Giriyor (2024-Şimdi)#

AI integration, code completion’ın ötesine geçerek uygulamaları nasıl geliştirdiğimizi temelden değiştiriyor.

Code Completion’dan Code Generation’a#

// 2023: Copilot-style completion
function validateEmail(email) {
  // AI önerir: return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}

// 2025: Natural language'den tam implementation'lara
// Prompt: "Form validation ile user authentication için React component yarat"
// AI tam component, hook'lar ve testleri generate ediyor

Build Boru Hattında AI#

Bugün güvenilir olan taraf analiz, aksiyon değil. Coverage araçları ve gerçek kullanıcı ölçümleri, oturumların çoğunun hiç uğramadığı route’ları işaret ediyor; ayırma işlemi ise hâlâ elle yazılan bir değişiklik:

import { lazy } from 'react';

// AdminPanel router'dan erişilebilir ama az oturumda yükleniyor;
// bu yüzden ilk chunk'tan çıkıp talep üzerine geliyor.
const AdminPanel = lazy(() => import('./AdminPanel'));

Hiçbir bundler ai-optimized diye bir chunking modu sunmuyor. Sunulan şey daha iyi ölçüm; kararı hâlâ birileri gözden geçiriyor.

Deno, Bun ve Tek Runtime Arayışı (2024-2025)#

En iddialı evrim universal deployment yönünde: her hedef için yeniden yazılmadan farklı environment’larda düzgün çalışan kod.

Deno Vizyonu#

// Bir kez yaz, her yerde çalıştır:
// - Edge function'lar (Deno Deploy)
// - Geleneksel serverlar (Deno CLI)
// - Desktop app'ler (Deno + Tauri)
// - Mobile app'ler (Deno + Capacitor)

Deno.serve((request) => {
  // Bu tam kod şuralarda çalışıyor:
  // - Global edge lokasyonları
  // - Local development server'ınız
  // - CI/CD environment'ları
  // - Production serverlar
  return new Response("Universal runtime!");
});

Bun Ekosistemi#

// Bun'ın all-in-one yaklaşımı:
{
  "scripts": {
    "dev": "bun run dev.ts",  // Runtime
    "build": "bun build src/*.ts",  // Bundler  
    "test": "bun test",  // Test runner
    "install": "bun install"  // Package manager
  }
}

// Tek binary, birden fazla rol:
// - Tek kurulumda paket yöneticisi, bundler, test runner ve runtime
// - Built-in bundling ve minification
// - Native TypeScript desteği

Framework Yakınsaması#

// Framework'ler arasında ortaya çıkan pattern:
// Aynı API, farklı deployment target'ları

// Next.js App Router
export async function GET(request) {
  // Vercel'de Edge Function olarak çalışır
  // Veya geleneksel serverlarda Node.js API
  // Veya adapter ile Cloudflare Worker
}

// SvelteKit
export async function load({ request }) {
  // Deployment target'a otomatik adapte olur:
  // - CDN için statik generation
  // - Dinamik content için server-side rendering
  // - Personalization için edge function'lar
}

Tooling Consolidation (2024-2025)#

Ekosistem olgunlaştıkça, entegre platform’lar etrafında konsolidasyon görüyoruz.

Platform Savaşları#

Vercel, React-first ve edge-native: Next.js optimizasyonu, otomatik performance monitoring, default olarak edge function’lar, built-in A/B testing.

Netlify, framework’ten bağımsız: universal edge function’lar, built-in form handling, ince ayarlı deployment kontrolleri, Jamstack optimizasyonu.

Cloudflare, geliştirici öncelikli altyapı: her yerde Worker’lar, global database (D1), object storage (R2), built-in analytics ve security.

Developer Experience Yakınsaması#

Depo bağlandıktan sonra akış her platformda aynı görünüyor:

1. Seçtiğiniz framework’te kodu yazın.
2. git push deployment’ı tetikler.
3. Platform edge dağıtımı için optimize eder.
4. Performance monitoring sürekli çalışır.
5. Başarısız deploy’lar otomatik geri alınır.
6. A/B testing platformla birlikte gelir.

Manuel infrastructure yönetimi yok, deployment konfigürasyonu yok, ayrı bir performance tuning adımı yok.

Mevcut Zorluklar ve Trade-off’lar#

İlerlemeye rağmen, önemli zorluklar kalıyor:

Vendor Lock-in Endişeleri#

// Platform integration ikilemi:
// Daha iyi performance ve DX = Daha yüksek lock-in riski

// Vercel-specific optimizasyonlar
export const runtime = 'edge';
export const regions = ['iad1', 'hnd1'];

// Cloudflare-specific API'lar
const kv = env.MY_KV_NAMESPACE;
await kv.put('key', 'value');

// Platform'lar arasında nasıl migrate edersiniz?

Karmaşıklığı Gizleme vs. Kontrol#

// Abstraction trade-off'u:
// Platform optimizasyonu otomatik handle ediyor
// Ama custom davranışa ihtiyacınız olduğunda ne oluyor?

// Bu "sadece çalışır" ama çalışmadığında nasıl debug edersiniz?
export default defineConfig({
  target: 'edge',
  // Platform diğer her şeyi çözüyor
});

// vs. explicit kontrol
export default {
  build: {
    target: ['es2020', 'edge88', 'firefox78', 'chrome87', 'safari13.1'],
    rollupOptions: {
      external: ['fsevents'],
      output: {
        manualChunks: {
          vendor: ['react', 'react-dom'],
          utils: ['lodash', 'date-fns']
        }
      }
    }
  }
};

Performance Paradoksu#

Edge computing, istek yolunun frontend tarafından kontrol edilen kısmını çözdü ve çözülmemiş kısmı görünür kıldı. Kullanıcıya yakın çalışan bir function, database’e uzak çalışıyor demektir.

Vercel bunu kendi platformunda belgeledi. Edge function’ları veriyle aynı yere taşımak üzerine yazdığı mühendislik yazısı, Sydney’de çalışan bir edge function’ın US East’teki bir database’e üç sorgu göndermesini anlatıyor ve toplamı “bir saniyeyi aşan database sorgusu” diye özetliyor. Function’ı database’in bölgesine taşıyınca aynı function database ile “yüzlerce milisaniye yerine birkaç milisaniyede” konuşabiliyor.

Cloudflare aynı şekle dair bir benchmark yayımladı. Smart Placement duyurusunda Sydney’den, Frankfurt’taki ücretsiz katman bir Upstash örneğine üç gidiş dönüş yapan bir Worker’a 3.500 istek gönderiliyor ve sonuç şöyle aktarılıyor: “Worker’ı backend’e yaklaştırmak uygulama performansını 4-8 kat iyileştirdi.” Sonuç grafik olarak yayımlandığı için alıntılanacak mutlak yüzdelik değerler yok.

Azure matrisi bu hikâyenin altına bir sayı koyuyor. Australia East ile Germany West Central arası P50’de 267 ms ölçülüyor; yani bu yol üzerinde art arda üç gidiş dönüş, database hiçbir iş yapmadan önce ağda kabaca 800 ms harcıyor. Vercel’in bağımsız olarak ulaştığı büyüklük mertebesi de bu.

Sorgu başına verilen sağlayıcı rehberliği ise daha kısa bir mesafeyi anlatıyor. Cloudflare’in Hyperdrive dokümantasyonu, her sorgunun “uzak bir bölgeden 20-30ms, yakına yerleştirildiğinde 1-3ms” eklediğini söylüyor. Buradaki “uzak” kıta içi demek; Azure rakamları ise kıtalararası çiftleri 166 ms ile 267 ms arasına koyuyor, yani bir büyüklük mertebesi üstüne. İki sayı da farklı mesafeler hakkında doğru; sadece küçüğünü alıntılamak da bu maliyetin nasıl hafife alındığını gösteriyor.

Vercel’in bugünkü rehberliği çözümün en kısa ifadesi: “Function’lar en düşük gecikme için database’inizle aynı bölgede ya da ona mümkün olduğunca yakın çalıştırılmalıdır.” Cloudflare’in Smart Placement’ı aynı hamleyi aynı çekinceyle yapıyor ve duyuru sınırı da adıyla koyuyor: Worker’ın konuştuğu servisler birçok bölgeye dağılmışsa Smart Placement “iyi bir seçim değil”; bu ağ kazanımının ne kadarının yanıta taşınacağını da database’in nerede durduğu belirliyor.

Bir Sonraki Sınırlar (2025-2030)#

Birkaç ortaya çıkan trend bir sonraki evrimi şekillendirecek:

Her Yerde WebAssembly#

// Compute-heavy task'ler için WASM'a compile edilmiş Rust
#[wasm_bindgen]
pub fn invert(data: &[u8]) -> Vec<u8> {
    // Piksel işlemleri browser ve edge runtime'larda native'e yakın hızda çalışır
    data.iter().map(|b| 255 - b).collect()
}

// wasm-bindgen, .wasm binary'sinin yanına bir JS glue modülü üretir
import init, { invert } from './pkg/image_processor.js';

export default function ImageEditor() {
  const handleProcess = async (imageData) => {
    await init();
    // Kazanç iş yüküne bağlı; en çok sıkı sayısal döngüler kazanır
    return invert(imageData);
  };
}

Streaming ve Partial Hydration#

// React Server Component'larının geleceği
function UserDashboard({ userId }) {
  return (
    <Suspense fallback={<DashboardSkeleton />}>
      <Suspense fallback={<ChartPlaceholder />}>
        <AnalyticsChart userId={userId} />
      </Suspense>
      <Suspense fallback={<TablePlaceholder />}>
        <DataTable userId={userId} />
      </Suspense>
    </Suspense>
  );
}

// Her component bağımsız stream ediyor
// Sadece görünür olduğunda hydrate oluyor
// Time to Interactive iyileşiyor: sayfa, her chunk hydrate olmadan
// kullanılabilir hale geliyor

AI Güdümlü Performans Optimizasyonu#

// Gelecek AI-powered development
export default function MyApp() {
  return (
    <div>
      <Header />
      <MainContent />
      <Footer />
    </div>
  );
}

// Yakın vadeli bir öneri, analitik raporlarının bugünkü diliyle:
// "Oturumların çoğu Footer'a hiç scroll etmiyor.
//  Lazy loading, o baytları ilk route'un dışına taşır."

Edge Database’ler ve Global State#

// Global olarak dağıtılmış database'ler, bugün geldikleri hâliyle
import { connect } from '@planetscale/database';

const conn = connect({ url: process.env.DATABASE_URL });

export default async function handler(request) {
  const userId = new URL(request.url).searchParams.get('id');

  // Sorgu, isteği karşılayan edge lokasyonundan çıkıyor.
  // Gecikmesi, function'ın nerede çalıştığına değil,
  // en yakın replica'nın nerede durduğuna bağlı.
  const { rows } = await conn.execute(
    'select id, email from users where id = ?',
    [userId]
  );

  return Response.json(rows[0]);
}

Tooling’de On Beş Yılda Ne Kazandı#

Manuel dosya yönetiminden AI-powered edge deployment’a kadar bu yolculuğa bakınca, kazananları açıklayan iki pattern öne çıkıyor.

Hangi Tool’lar Benimsendi#

Her değişim bir performance kazanımıyla başladı: Grunt ve Gulp manuel build adımlarını otomatize etti, webpack module management’ı çözdü, native tool’lar build süresini daha da kısalttı. Ama hız tek başına bir tool’u kalıcı kılmadı. jQuery DOM manipulation’ını keyifli hale getirdi, Create React App configuration overhead’ini kaldırdı, Vite ise neredeyse anında feedback verdi; her biri performance kazanımını daha az sürtünmeyle eşleştirdi. Edge computing de aynı örüntüye uyuyor: Cloudflare’in kendi ağı için verdiği rakamla, hesaplama dünya genelindeki internet kullanıcılarının %95’ine 50 ms içinde yerleşiyor.

Entegre Tool’lar Çıkış Kapısını Korudu#

• webpack ayrı minifier’ların ve bundler’ların yerini aldı ama default’ların karşılamadığı durumlar için tam customization’ı korudu; Next.js de elle kurulan bir React setup’ının yerini aynı şekilde aldı, configuration’ı kaldırmadan API route’ları ekledi.
• Vercel ve Netlify aynı hamleyi infrastructure katmanında yaptı: manuel server kurulumunun yerine, projelerin çoğunun hiç override etmesi gerekmeyen bir platform default’u geçti.
• Zero-config framework’ler geri kalanı için bir ejection opsiyonu tuttu: default’ta daha az configuration, elle configure etmek hâlâ mümkün.

Mevcut Tablo#

15 yıllık evrimden sonra, frontend tooling şu durumda:

Çalışan Taraf ve İddiaların Atladığı Yer#

npm create next-app my-app
cd my-app
gh repo create acme/my-app --private --source=. --remote=origin
git push -u origin main

Bu depoyu Vercel, Netlify ya da Cloudflare’e almak, platformun panelinde yapılan ayrı ve tek seferlik bir adım. Ondan sonra bir push gerçekten de TypeScript’i yapılandırılmış, ölçeklenmesi devralınmış, performance monitoring’i bağlanmış ve başarısız deploy’da geri alınan bir uygulama üretiyor. Yanına basılan iddialar ise daraltılmayı bekliyor.

Erişim, pazarlamanın ima ettiğinden dar. Vercel’in bölge dokümantasyonu “126’nın üzerinde PoP” işlettiğini ama “kodunuzun verinize yakın çalışabileceği 20 compute bölgesi” tuttuğunu söylüyor; point of presence’lar yalnızca TCP’yi sonlandırıp isteği ileri yönlendiriyor. Yoğunlaşma, açıkça tasarım hedefi: “Daha az ama daha yoğun bölge tutarak cache isabet olasılığını artırıyoruz.” Function’lar da “varsayılan olarak iad1 (Washington, D.C., ABD) bölgesinde çalışıyor”; yani ABD’nin doğu kıyısındaki tek bir bölgede. Deno Deploy Classic altı bölge listeliyordu ve dokümantasyonu “20 Temmuz 2026’da kapatılacağını” yazıyor. Cloudflare ise istisna: ağ sayfasında 348 şehir, kendi Workers ve CDN ürün sayfalarında ise 330+ geçiyor.

50 ms bir ağ mesafesi. Rakam, kullanıcıların Cloudflare veri merkezlerine ne kadar uzakta olduğunu ölçüyor ve karşılaştırılabilir ölçüm de bunu destekliyor: Cloudflare Radar’ın 2025 verisinde boştaki gecikme, en hızlı ülkede 13 ms ortalamaya oturuyor. İstek ulaştıktan sonra uygulamanın harcadığı süre ayrı bir büyüklük ve burada alıntılanan veri kümelerinin hiçbiri onu ölçmüyor. Yani sayı ağ sıçramasını sınırlıyor; yanıtın tamamının bu sınıra sığıp sığmadığı, verinin gösterdiği bir şey değil, okurun kendi eklediği varsayım.

Deploy süresi için yayımlanmış bir rakam hiç yok. Ne Vercel, ne Netlify, ne de Cloudflare medyan build ve deploy süresi yayımlıyor; üstelik bu sayıya platformdan çok uygulamanın kendisi hükmediyor. Bunun için verilen her süre, tek bir projeyi anlatıyor.

Edge runtime, üç platformdan birinde geri çekiliyor. Vercel’in 25 Haziran 2025 tarihli changelog kaydı “Edge Middleware ve Edge Functions’ın kullanımdan kaldırıldığını” ve yerlerini Routing Middleware ile Vercel Functions’ın aldığını yazıyor. Edge Runtime dokümantasyonu da artık bir taşınma önerisiyle açılıyor: “Daha iyi performans ve güvenilirlik için edge’den Node.js’e geçmenizi öneriyoruz.” Aynı sayfa, Next.js 16.3’ten itibaren runtime = 'edge' ayarının desteklenmediğini de belirtiyor.

Zorluklar#

Mevcut araçların hâlâ zorlandığı yerler:

• Platform entegrasyonuyla birlikte gelen vendor lock-in
• Dağıtılmış edge uygulamalarını debug etmek
• Edge lokasyonları arasında state yönetmek
• Edge context’lerinde database performance
• Edge computing için maliyet modellemesi

Fırsatlar#

Bu zorlukların yanında AI destekli development, runtime’lar arasında universal deployment, streaming ve partial hydration, performance-critical kod için WebAssembly ve edge optimizasyonlu global database’ler paralel olarak ortaya çıkıyor.

Yaygın Öngörülerin Ardındaki Veriler#

Frontend tooling’in nereye gittiğine dair hemen her anlatıda üç öngörü çıkıyor. Her biri hâlihazırda ölçülmüş bir şeyle karşılaştırılabilir. İkisi bu karşılaştırmadan sağ çıkmıyor; üçüncüsünü ise iki yönde de karara bağlayan bir ölçüm yok.

Platform Konsolidasyonu#

İki ya da üç platform diğerlerini yutacak ve development’tan deployment’a uçtan uca bir yol sunacak: öngörü bu, yayımlanmış veri ise bunu karara bağlamıyor. 2025 Stack Overflow Developer Survey’in 20.070 profesyonel geliştiricinin yanıtladığı teknoloji bölümü, önceki yıl yoğun olarak kullanılan bulut platformlarını şöyle veriyor: AWS %45,9, Microsoft Azure %27,2, Google Cloud %24,3, Cloudflare %19,7, Vercel %10,8 ve Netlify %5,7. Katılımcılar birden fazla platform işaretleyebiliyordu; bu yüzden bu rakamlar kullanım oranlarını gösteriyor. Tek bir pazarın payı değildir. Anlattıkları da tek bir yıl: 2025’te frontend tarafını ilgilendiren platformlar kabaca %5 ile %20 arasındaki bantta duruyordu ve tepedeki hyperscaler, framework entegrasyonlarını gönderen taraf değildi. Konsolidasyon öngörüsünün yoğunlaşmaya doğru bir eğilim çizgisine ihtiyacı var; tek bir kesit ise eğilim çizgisi sayılmaz. Geniş bir bant hızla daralıyor da olabilir, hiç daralmıyor da; daraldığı ya da daralmadığı, yanına karşılaştırılabilir eski ölçümler konana kadar açık kalıyor.

Default Olarak Edge-First#

Yeni framework’ler edge deployment’ı varsayacak ve default olarak global dağıtım için optimize edecek. Beklenti buydu; 2025’ten bu yana yaşanan en net iki platform hamlesi ise ters yöne gitti ve ikisi de sağlayıcıların kendi belgelerinde duruyor. Vercel, Edge Middleware ve Edge Functions’ı kullanımdan kaldırdı, artık edge runtime’dan Node.js’e geçilmesini öneriyor ve Next.js 16.3 seçeneği tamamen kaldırdı. TypeScript öncelikli edge runtime olan Deno Deploy Classic kapanıyor. Cloudflare karşı ağırlık; ama Cloudflare’in gecikme problemine yanıtı olan Smart Placement’ın amacı bile hesaplamayı kullanıcıdan uzaklaştırıp veriye yaklaştırmak.

Mekanizma yine performance paradoksu. Edge yerleşimi, istek yalnızca edge’in zaten elinde tuttuğuyla yanıtlanabildiğinde kazanıyor. Uygulama isteklerinin çoğu bir database okuyor ve yığında merkezde kalan her katman, hesaplamayı kendine doğru geri çekiyor.

Sürekli AI Optimizasyonu#

Öngörü şu: AI production’ı izleyip uygulamayı insan devrede olmadan ayarlayacak. Benimsenme gerçek. Ölçümlerin gösterdiği şey ise özerklik değil.

DORA’nın yaklaşık 5.000 katılımcıya dayanan 2025 State of AI-assisted Software Development raporu, yazılım geliştirme profesyonellerinin %90’ının artık AI kullandığını (yıllık bazda 14 puanlık artış) ve medyan günlük kullanımın iki saat olduğunu buluyor. Katılımcıların %80’den fazlası verimlilik artışı, %59’u kod kalitesine olumlu etki bildiriyor. Ayrım güvende beliriyor: AI üretimi koda “çok” ya da “epey” güvendiğini söyleyenler %24, “az” ya da “hiç” diyenler %30. Aynı rapor, yüksek AI benimsemesinin hem teslim hızıyla hem de teslim kararsızlığıyla aynı anda ilişkilendiğini buluyor.

METR’in randomize kontrollü deneyi aynı yönü başka bir açıdan gösteriyor. On altı deneyimli açık kaynak geliştiricisi, ortalama beş yıldır katkı verdikleri depolarda 246 görev üzerinde çalıştı; araç olarak Claude 3.5 ve 3.7 Sonnet ile Cursor Pro kullanıldı. AI’ya izin vermek tamamlanma süresini %19 artırdı; aynı geliştiriciler ise öncesinde %24 hızlanma öngörmüş, sonrasında da hâlâ %20 hızlanma tahmin etmişti.

Gözetimsiz çalışan bir optimizasyon döngüsü, iki veri kümesinin de desteklemediği bir güven ve güvenilirlik düzeyi gerektirirdi; bugün sahada olan tooling ise bu kararı hâlâ bir insana bırakıyor.

Görüş Olarak Kalanlar#

Altyapının tümüyle ortadan kalkması, asistanların bir tarifle bütün feature’ları yazması, performansın kendiliğinden gelmesi, tek bir codebase’in edge, mobil, masaüstü ve IoT’de iyi çalışması: bunların hiçbirinin arkasında iki yönde de bir ölçüm yok, dolayısıyla hepsi görüş sütununa girer.

Platform Bağımlılığının Sınırı#

Son 15 yıla damgasını vuran problemler (build süreleri, module management, tarayıcı uyumluluğu, deployment karmaşıklığı) büyük ölçüde çözüldü. Yerlerini bir bağlanma sorusu aldı. Platform’lar artık framework’ünüzü, hedef runtime’ınızı ve deployment topolojinizi biliyor; bu bilginin bedelini taşınabilirlikten kesiyorlar.

Bu bedeli ödemek şu durumlarda doğru default: uygulama tek bir platformda yayınlanıyorsa, ekip küçükse ve platformun default’ları ekibin elle kuracağı yapılandırmadan iyiyse. Şu durumlarda direnin: build birden fazla runtime’ı hedeflemek zorundaysa, hosting kararı teknikten çok satın alma kararıysa veya platforma özel bir API her route’un istek yolunda duruyorsa.

Pratikte bu, platforma özel kodu kod tabanının kenarında tutmak (adapter’lar, route handler’lar, config preset’leri) ve geri kalanı standart Web API’ları üzerinde bırakmak demek. Böylece taşınma, uygulamayı değil adapter katmanını yeniden yazmaya dönüşüyor.

Kaynaklar#

• Azure ağ gidiş dönüş gecikme istatistikleri (yeni sekmede açılır) - Microsoft’un Azure bölgeleri arasında dahili omurga problarıyla bir dakikalık aralıklarla ölçtüğü P50 gidiş dönüş süreleri matrisi; gecikme tablosundaki tüm bölgeler arası değerlerin kaynağı
• Cloudflare Global Network (yeni sekmede açılır) - “Dünyanın internete bağlı nüfusunun %95’i bir Cloudflare veri merkezine 50 milisaniye içinde” iddiasını ve 348 şehir sayısını taşıyan, sürekli güncellenen sayfa; 50 ms rakamının tam olarak neyi ölçtüğünü görmek için
• Cloudflare Radar 2025 Yıl Değerlendirmesi (yeni sekmede açılır) - 2025 boyunca dünya genelinde yapılan hız testlerinden derlenen ülke bazlı boştaki ve yük altındaki gecikme ortalamaları; boştaki değer sakin bir bağlantıdaki gidiş dönüş, yük altındaki ise bant genişliği testi hattı doldururken ölçülen aynı gidiş dönüş
• Cloudflare Workers ile cold start’ları ortadan kaldırmak (yeni sekmede açılır) - V8 isolate’lerin container’lardan neden daha hızlı başladığının açıklaması ve Workers için alıntılanan “5 milisaniyenin altında” rakamının kaynağı
• Lambda execution environment yaşam döngüsü (yeni sekmede açılır) - AWS’in kendi cold start rakamları; sıklık (çağrıların %1’inden azı) ve Cloudflare’in container karşılaştırmasına karşı alıntılanan süre aralığı dâhil
• Smart Placement duyurusu (yeni sekmede açılır) - 4-8 kat iyileşme rakamının arkasındaki Sydney-Frankfurt benchmark’ı ve hesaplamayı backend’e yaklaştırmanın ne zaman işe yaramadığına dair Cloudflare’in kendi değerlendirmesi
• Hyperdrive nasıl çalışır (yeni sekmede açılır) - Cloudflare’in uzak ve yakın database yerleşimi için sorgu başına gecikme rakamları ve gidiş dönüş sayısını azaltan bağlantı havuzu mekanizması
• Vercel’de edge’i verinizle aynı yere taşıyın (yeni sekmede açılır) - Database’inden uzaktaki bir edge function’ın neden bölgesel bir function’dan yavaş olduğunun Sydney-US East örneğiyle anlatımı
• Global network ve bölgeler - Vercel (yeni sekmede açılır) - Vercel’in point of presence ile compute yapabilen bölge ayrımı, varsayılan function bölgesi ve function’ları database’in yanında çalıştırma tavsiyesi
• Edge Runtime - Vercel (yeni sekmede açılır) - Vercel edge runtime’ının bugünkü durumu; Node.js’e geçiş önerisi ve edge runtime desteğini kaldıran Next.js sürümü dâhil
• Edge Middleware ve Edge Functions artık Vercel Functions ile çalışıyor (yeni sekmede açılır) - Kullanımdan kaldırmanın tarihini veren ve yerine gelenleri adlandıran changelog kaydı
• Deno Deploy Classic - Bölgeler (yeni sekmede açılır) - Deno’nun ilk edge platformunun bölge listesi ve kapanma duyurusu; her yerde edge iddialarına karşı işe yarar bir kontrol noktası
• 2025 Stack Overflow Developer Survey - Teknoloji (yeni sekmede açılır) - Profesyonel geliştiriciler arasında tek bir yıla ait platform kullanım oranları; soru birden fazla yanıta izin verdiği için yüzdeler birbirini dışlayan pazar payları değil
• DORA - State of AI-assisted Software Development 2025 (yeni sekmede açılır) - DORA’nın AI odaklı raporundan benimsenme, verimlilik, güven ve teslim kararlılığı bulguları; AI kullanımı ile çıktısına duyulan güven arasındaki ayrım dâhil
• Erken 2025 AI’sının deneyimli açık kaynak geliştiricilerinin verimliliğine etkisinin ölçümü (yeni sekmede açılır) - METR’in AI destekli ve desteksiz tamamlanma süresini ölçen randomize kontrollü deneyi ve geliştiricilerin kendi tahminleri
• React Server Components (yeni sekmede açılır) - Streaming SSR ve partial hydration’ın arkasındaki server component modelini açıklayan React referansı