Cloudflare Web Fragments: Micro-Frontend Dünyasında "Sanallaştırma"
Cloudflare Web Fragments: Micro-Frontend Dünyasında "Sanallaştırma"
Micro frontend, büyük bir web uygulamasını farklı ekiplerin bağımsız olarak geliştirebileceği, test edebileceği ve yayına alabileceği daha küçük, özerk parçalara bölme mimarisidir. Bu yaklaşımda her modül kendi teknoloji yığınını kullanabilir ve ana uygulamaya çalışma zamanında (runtime) entegre edilir. En popüler ve modern çözümlerin başında modüller arası kod paylaşımını kolaylaştıran Module Federation (Webpack 5+) gelirken; farklı framework'leri bir arada çalıştıran Single-SPA geliyor.
Cloudflare, kendi devasa yönetim panelini (dash.cloudflare.com) modernize ederken geliştirdiği ve geçtiğimiz aylarda açık kaynak olarak sunduğu Web Fragments ile bu denklemi değiştirmeyi hedefliyor. Ryan Carniato'nun yayınında Cloudflare'den Igor Minar ve Microsoft'tan Natalia'nın paylaştığı derin teknik detaylarla, bu yeni yaklaşımın neden sadece bir "kütüphane" değil, tarayıcı içinde bir "sanallaştırma katmanı" olduğunu inceleyelim.
Sahte Paylaşım (Fake Sharing)
Micro-frontend dünyasında en büyük yanılgı, yeterince disiplinli olursak her şeyi tek bir global alanda (window) yönetebileceğimiz düşüncesidir. Ancak Cloudflare gibi 2.000'den fazla mühendisin çalıştığı ölçeklerde, bu "disiplin" kaçınılmaz olarak çöker.
Igor Minar, bu durumu "Fake Sharing" (Sahte Paylaşım) kavramıyla açıklıyor. Ekipler, aslında izole olması gereken bağımlılıkları ve durumları (state) paylaşılan bir window nesnesi üzerinden yönetmeye çalıştığında, sistem kırılganlaşır.
- Bir ekibin yaptığı
Array.prototypeyaması, diğer ekibin kodunu bozar. - Farklı React sürümleri (
v16vev18) aynı sayfada çakışır. - Global CSS sınıfları birbirini ezer.
Mevcut çözümlerin en büyük eksikliği, sunucu tarafındaki "Docker" mantığının ön yüze taşınamamış olmasıydı. Web Fragments, işte tam bu noktada devreye giriyor: Kodları birleştirmekle kalmıyor, tarayıcı içinde her fragment için izole bir çalışma ortamı yaratıyor.
Teknolojinin 3 Sütunu: Reframed, Piercing ve Gateway
Web Fragments, "İzole DOM Konteynerleri" mantığıyla çalışır. Bu yapı üç ana teknoloji üzerine kuruludur:
1. Reframed: Tarayıcı İçinde Sanallaştırma
Sistemin kalbinde Reframed kütüphanesi yer alır. Geleneksel iframe kullanımından farklı olarak, Web Fragments iframe'i bir görünüm aracı olarak değil, saf bir "Execution Sandbox" (Çalıştırma Alanı) olarak kullanır.
- Monkey-Patching: Reframed, oluşturduğu gizli iframe içindeki
document,windowvehistorygibi kritik API'leri "monkey-patching" yöntemiyle manipüle eder. - Sanal DOM Yönetimi: İframe içinde çalışan kod (
document.createElementveyaquerySelectorçağırdığında), sistem bu çağrıyı yakalar ve ana sayfadaki (Main Window) ilgili Shadow DOM köküne yönlendirir. - Event Retargeting: İframe içinden fırlatılan olaylar (events), sanki ana sayfadan geliyormuş gibi yeniden hedeflenir.
Sonuç? Kod kendini özel bir odada (iframe) sanır ve özgürce hareket eder, ancak çıktıları ana salonun (Main Window) tam da ayrılan köşesinde görüntülenir. Bu sayede instanceof Array gibi kontroller, farklı pencereler arasında bile doğru çalışır (çünkü global kurucular da yamalanmıştır).
2. Piercing: İçten Dışa Rendering (Inside-Out)
Micro-frontend'lerin en büyük baş ağrısı Server-Side Rendering (SSR) sürecidir. Genellikle "shell" (ana iskelet) yüklenmeden içerik gösterilemez. Natalia'nın vurguladığı "Inside-Out Rendering" (Piercing) özelliği ise bu kuralı yıkar.
- Bir fragment (örneğin "Sepet"), ana uygulama (Shell) henüz hazır olmasa veya hata verse bile ekranda belirebilir.
- Sunucu tarafında (Gateway), parçalar
HTMLRewriterile birleştirilirken, her parça kendi stil ve script'leriyle bağımsız olarak "mıhlanır". - Kullanıcı, JavaScript yığınları (bundles) yüklenmeden, HTML ve CSS ile oluşturulmuş içeriği anında görür ve etkileşime geçebilir.
3. Gateway: Kenar (Edge) Tabanlı Birleştirme
İşlem, kullanıcı tarayıcısına gelmeden çok önce, Cloudflare Workers gibi "Edge" noktalarında veya Node.js sunucularında başlar. Gateway, gelen isteği analiz eder ve hangi fragment'ın hangi servisten geleceğini belirler. Bu, istemci tarafındaki (Client-side) karmaşık "loader" mantığını sunucuya taşıyarak performansı artırır.
İletişim: Standart Web API'lerinin Gücü
Farklı teknolojilerle (örneğin biri Qwik, diğeri React ile yazılmış iki fragment) geliştirilen parçalar birbiriyle nasıl konuşacak? Cloudflare burada tekerleği yeniden icat etmek yerine web standartlarına güveniyor: Broadcast Channel API.
Web Fragments, karmaşık "Global State Management" kütüphaneleri yerine, tarayıcının yerel iletişim kanallarını kullanmayı teşvik eder:
// Sepet Fragment'ı (Qwik)
const cartChannel = new BroadcastChannel('/cart');
cartChannel.postMessage({ type: 'ADD_ITEM', id: 123 });
// Header Fragment'ı (React)
const cartChannel = new BroadcastChannel('/cart');
cartChannel.onmessage = (event) => {
if (event.data.type === 'ADD_ITEM') {
updateCartCount();
}
};
Bu sayede parçalar birbirlerinin iç yapısını (state management kütüphanesini, framework sürümünü) bilmek zorunda kalmadan, sadece mesajlar üzerinden haberleşir.
Neden Şimdi?
Cloudflare bu teknolojiyi sadece "havalı" yeni bir özellik olsun diye geliştirmedi. 8-10 yıllık, devasa bir monolit olan dash.cloudflare.com uygulamasını modernize etmek zorundaydılar. "Her şeyi çöpe atıp baştan yazalım" (Big Bang Rewrite) yaklaşımının getireceği felaket riskinden kaçınarak, uygulamayı parça parça, sayfa sayfa modernize etmenin yolunu Web Fragments ile buldular.
Proje "Vendor Agnostic" (Sağlayıcı Bağımsız) olarak tasarlandı. Yani bu mimariyi kullanmak için Cloudflare Workers kullanmak zorunda değilsiniz; AWS, Azure veya kendi sunucularınız üzerinde de çalıştırabilirsiniz.
Sonuç
Web Fragments, frontend dünyasına arka uçtaki (backend) mikro-servis disiplinini ve konteyner izolasyonunu getiriyor. Eğer ölçeklenebilirlik sorunları yaşayan büyük bir ekipseniz veya Legacy (eski) kodlarla boğuşuyorsanız, Web Fragments'ın sunduğu bu "tarayıcı tabanlı sanallaştırma" yaklaşımı, aradığınız çıkış yolu olabilir.
Daha fazlası için: web-fragments.dev