Mikro-Önyüz (Micro-Frontend) Module Federation: Bağımlılık Kayması ve Single-SPA İzolasyonu

Staff/Principal (L6+)

⚡ÖZET VE TEKNİK CEVAP

Büyük kurumsal web uygulamalarında, devasa bir önyüz monolitini Webpack 5 Module Federation veya Single-SPA ile bağımsız dağıtılan Mikro-Önyüzlere (MFE) bölmek takımlara otonom canlıya çıkma özgürlüğü sağlar. Ancak katı versiyon mutabakat kuralları konulmadığında takımların bağımlılıkları zamanla kayar (dependency drift): A Takımı React 19 ile canlıya çıkarken, B Takımı hala React 18 kullanır. Ana kabuk (Host shell) her iki modülü çalışma anında dinamik yüklediğinde, tarayıcının belleğine iki farklı React motoru enjekte edilir. Bu durum meşhur 'Invalid Hook Call / Multiple React Instances' çökmesini tetikler, ortak React Context yapılarını bozar, JavaScript boyutunu 400 KB şişirir ve bellek sızıntılarına yol açar. Canlı sistemler bunu Katı Module Federation Singleton Kontratları ile çözer: Çekirdek kütüphaneler singleton: true, strictVersion: true, requiredVersion: '^18.3.0' olarak kilitlenir; uyumsuz eski bileşenler ise Shadow-DOM veya iframe kalkanlarına izole edilir.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Module Federation çalışma anı mutabakatı 3 adımda gerçekleşir:

Paylaşılan Kapsam Başlatma: Ana kabuk paylaşılan paketleri semver tanımlarıyla __webpack_share_scopes__.default global kaydına yazar.

Uzak Versiyon El Sıkışması: Ana kabuk uzak remoteEntry.js dosyasını çekerken, uzak modülün requiredVersion aralığını kayıtlı versiyonla kıyaslar.

Singleton Çözümleme: singleton: true aktifse ve versiyonlar uyumluysa ana kabuğun React örneği paylaşılır; strictVersion: true ihlal edilirse sistem belleğe sessizce ikinci bir React yükleyip çökmek yerine deterministik bir yükleme hatası fırlatır.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Çok takımlı kurumsal paneller (AWS yönetim konsolu, e-ticaret satıcı panelleri), ödeme, hesap ve kredi modüllerinin 10'dan fazla bağımsız ekip tarafından geliştirildiği bankacılık portalları.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
React veya React-DOM üzerinde singleton: false bırakıp iki farklı hook motorunun yüklenerek useContext() anında uygulamanın beyaz ekrana düşmesi (white-screen crash)
✓
paylaşılan tasarım sisteminde (Design System) kırıcı değişiklik yapıp yan mikro-önyüzlerin CSS düzenini bozmak

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
Tarayıcı konsolunda Invalid hook call hatalarının patlaması
✓
Ağ (Network) sekmesinde farklı MFE parçalarından 3 kez ayrı react.production.min.js indirildiğinin görülmesi
✓
paket analizinde aynı kütüphanenin birden fazla kopyasının tespit edilmesi

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
CI/CD sürecinde merkezi bir Paylaşılan Bağımlılık Matrisi denetimi uygulayın
✓
tüm çekirdek kütüphanelerde (React, DOM, Zustand) singleton: true, strictVersion: true zorunlu kılın
✓
canlıya çıkış öncesi MFE uyumluluk testlerini otomatik çalıştırın

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Katı singleton versiyonlama kütüphane şişmesini ve hook çöküşlerini sıfırlar; ancak ekiplerin ana framework güncellemelerinde (React 18'den 19'a geçiş gibi) senkronize olmasını zorunlu kılar.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir e-ticaret platformu web uygulamasını 4 mikro-önyüze böldü: Başlık, Katalog, Sepet ve Öneriler. Sepet takımı React 18.3'e geçerken Katalog 18.1'de kaldı. Module Federation ayarında singleton: false olduğu için tarayıcı iki React kopyası indirdi. Kullanıcılar 'Sepete Ekle'ye bastığında Sepet context'i ikinci React motorunda izole kaldığı için sepet güncellenmedi. Ekip Webpack ayarını { react: { singleton: true, strictVersion: true, requiredVersion: '^18.0.0' } } olarak güncelledi; 180 KB gereksiz JS silindi ve sepet çöküşleri tamamen çözüldü.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Webpack Module Federation Mikro-Önyüzlerde 'Invalid Hook Call' hatasına ne sebep olur?

Paylaşılan bağımlılıklar singleton olarak ayarlanmadığı için aynı tarayıcı sekmesinde birden fazla React kopyasının yüklenmesi.

Module Federation ayarlarındaki `strictVersion: true` ne işe yarar?

Uzak modülün versiyonu ana kabuğun `requiredVersion` kuralına uymuyorsa sessizce yanlış sürümü yüklemek yerine hata fırlatarak çökmeyi önler.

Mikro-Önyüz (Micro-Frontend) Module Federation: Bağımlılık Kayması ve Single-SPA İzolasyonu — Sıkça Sorulan Sorular

Bir Mikro-Önyüzü Module Federation yerine ne zaman bir iframe içine izole etmelisiniz?

Tamamen eski teknolojileri (React 19 içinde eski Angular 1.x veya jQuery) çalıştırırken ya da katı CSS ve güvenlik izolasyonu gerektiren üçüncü taraf satıcı eklentilerinde.

Module Federation bağımsız mikro-önyüzler arasında durumu (state) nasıl paylaşır?

Singleton olarak paylaşılan durum yönetim kütüphaneleri (Zustand/Redux), tarayıcı özel DOM olayları (`CustomEvent`) veya URL sorgu parametreleri üzerinden.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸
Module Federation bağımsız önyüz dağıtımı sağlar ancak bağımlılık kayması riski taşır.
▸
Tarayıcıda birden fazla React kopyası ölümcül hook çökmelerine ve durum bölünmesine yol açar.
▸
Çekirdek kütüphanelerde singleton: true, strictVersion: true ayarını zorunlu kılın.
▸
Uyumsuz eski bileşenleri Shadow DOM veya iframe kalkanları içinde izole edin.

Yaygın Yanılgılar

✗
Yanılgı: Mikro-önyüzler takımlar arası koordinasyon ihtiyacını tamamen yok eder (Gerçek: Çekirdek framework sürümleri ve tasarım kuralları ortak mutabakat gerektirir).
✗
Yanılgı: Module Federation tüm uzak kodları ilk sayfa açılışında indirir (Gerçek: Uzak modüller sadece ilgili sayfa veya bileşen ekrana geldiğinde tembel yüklenir).

Karar Kılavuzu & Önceliklendirme

Çoklu React çalışma anı çakışmalarını ve paket şişmesini önlemek için kurumsal mikro-önyüzlerde katı singleton bağımlılık sözleşmeleri uygulayın.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]Module Federation Architecture & Shared Dependency Management— Zack Jackson / Webpack Core Team