Micro-frontend mimarisi kurmak: ne zaman, nasıl ve hangi bedelle

Micro-frontend nedir ve hangi sorunu çözer?

Micro-frontend, büyük bir web arayüzünü bağımsız geliştirilen, test edilen ve yayına alınan daha küçük arayüz parçalarına bölme yaklaşımıdır. Arka uçtaki mikro servis düşüncesinin ön yüze uyarlanmasıdır: her parça belirli bir iş alanına (örneğin sepet, ürün listesi, hesap ayarları) sahiptir ve bu alandan tek bir ekip sorumludur. Kullanıcı bunları tek bir uygulama gibi görür; ekipler ise aynı depoda, aynı dağıtım hattında birbirini beklemek zorunda kalmaz.

Yaklaşımın çözdüğü sorun teknik değil, daha çok organizasyoneldir. Tek bir büyük ön yüz kod tabanında birçok ekip çalıştığında şunlar yaşanır: yayın takvimi herkesi birbirine bağlar, bir ekibin hatası tüm uygulamayı geri almaya zorlar, kod sahipliği belirsizleşir, güncelleme riskli hale gelir. Micro-frontend bu bağımlılıkları azaltmayı hedefler.

Öte yandan yaklaşım bedelsiz değildir. Ekipler arası tutarlılık, ortak bağımlılıkların yönetimi, performans ve test karmaşıklığı artar. Tek ekipli, orta ölçekli bir uygulamada micro-frontend gereksiz bir yük olabilir. Bu nedenle beceri, mimariyi kurmaktan önce onu gerekçelendirebilmektir.

Micro-frontend için karar çerçevesi: kurmalı mıyım?

Karar verirken teknolojiyi değil, şu durumları sorgulayın: • Birden fazla ekip aynı arayüz kod tabanını sürekli değiştiriyor ve birbirini bekliyor mu? • Ürün, birbirinden görece bağımsız iş alanlarına net biçimde ayrılabiliyor mu? • Bazı bölümler farklı hızda yayın yapmak zorunda mı? • Eski bir uygulamayı tamamen yeniden yazmadan, parça parça yenilemek gerekiyor mu?

Bu sorulara olumlu yanıt veriyorsanız yaklaşım değerlidir. Hayır diyorsanız, iyi yapılandırılmış bir modüler tek parça (monolit) mimarisi, bileşen kitaplığı ve net klasör sınırlarıyla aynı ihtiyacı daha ucuza karşılayabilir.

Karar belgesine şunları da yazın: Hangi sınır neden seçildi, ekip sahiplikleri nasıl dağıldı, ortak parçalar (kimlik doğrulama, navigasyon, tasarım sistemi) kimin sorumluluğunda, geri dönüş planı nedir. Bu belge ilerleyen aşamada, yeni gelen mühendisin ve yönetimin 'bunu neden böyle yaptık' sorusuna cevap verir.

Uygulamayı parçalara nasıl bölersiniz?

Bölme stratejisi mimarinin en kritik kararıdır. Yaygın yaklaşımlar şunlardır: yatay bölme, aynı sayfada birden çok parçanın bir arada çalıştığı yapıdır (örneğin bir sayfada başlık, ürün önerileri ve sepet kutusu farklı ekiplerin parçalarıdır). Dikey bölme ise sayfa ya da rota düzeyinde ayırmadır: ürün sayfaları bir ekibin, ödeme akışı başka bir ekibin sahipliğindedir.

Sınır çizerken şu ilkeleri kullanın: • İş alanı sınırı: Bölünen parça bir iş kavramıyla örtüşmeli; teknik katmana (örneğin 'bütün butonlar') göre bölmeyin. • Ekip sınırı: Bir parçadan tek ekip sorumlu olmalı. • Veri sahipliği: Parçanın hangi arka uç servisle konuştuğu belirli olmalı. • Sıkı bağlılığın azlığı: Parçalar birbirinin iç durumunu bilmemeli, yalnızca sözleşmeli arayüzlerle konuşmalı.

Bölme çok ince yapılırsa her ufak bileşen ayrı bir uygulamaya dönüşür ve ağ çağrıları, yükleme süresi, koordinasyon maliyeti artar. Çok kaba yapılırsa ekipler yine birbirini engeller. İyi pratik, önce kaba sınırlarla başlayıp gerekçe oluştukça parçalamaktır.

Parçaları nasıl bir araya getirirsiniz? Module Federation ve diğer yöntemler

Parçaları birleştirme zamanına göre yöntemler değişir: • Derleme zamanında birleştirme: Her parça bir paket olarak yayımlanır ve ana uygulama bunları bağımlılık gibi içerir. Basittir; ancak bir parça güncellendiğinde ana uygulamanın yeniden derlenmesi gerekir, bağımsız yayın amacına tam hizmet etmez. • Çalışma zamanında birleştirme: Parçalar tarayıcıda yüklenir. Module Federation bunun en bilinen araçlarından biridir: bir uygulama (host) başka bir uygulamanın (remote) sunduğu modülleri çalışma anında yükleyebilir ve ortak bağımlılıkları paylaşabilir. • iframe: Güçlü yalıtım sağlar; fakat boyutlandırma, gezinme ve paylaşılan durum zorlaşır. • Web bileşenleri: Tarayıcı standardı olarak çerçeveden bağımsız parçalar sunar.

Module Federation ile çalışırken şu sorulara cevap verilmelidir: Hangi modüller dışarıya açılacak (expose)? Hangi bağımlılıklar paylaşılacak ve sürüm uyumsuzluğunda ne olacak? Bir parça yüklenemezse kullanıcıya ne gösterilecek? Sonuncu sorunun cevabı, hata sınırı (error boundary) ve yedek arayüz tasarımıdır. Parçalardan biri çökünce tüm sayfanın çökmesi, mimarinin amacını tersine çevirir.

Ortak altyapı, tasarım sistemi ve sürümleme

Bağımsız parçaların bir arada tutarlı görünmesi için bazı konular merkezi tutulur. Kimlik doğrulama ve oturum yönetimi, yönlendirme ve navigasyon, analitik ve hata izleme, ortak tema ile tasarım sistemi bunların başında gelir. Bu parçaların bir sahibi, kamuya açık bir sözleşmesi ve sürüm politikası olmalıdır.

Parçalar arası iletişimde şu kurallar işe yarar: İlk olarak doğrudan paylaşılan global durumdan kaçının. Bunun yerine olaylar, URL parametreleri ya da açıkça tanımlı arayüzler kullanın. İkinci olarak, bir parçanın başka parçanın iç yapısına erişmesini yasaklayın. Son olarak sözleşmeyi (veri şekli, olay adı) yazılı ve sürümlü tutun.

Tasarım sistemi konusunda uç noktalardaki hatalardan kaçınılmalıdır. Her ekip kendi bileşenini yazarsa kullanıcı arayüzü parçalanır. Her şeyi zorunlu tek paket yaparsanız, tasarım sistemi bir sürüm darboğazı olur. Semantik sürümleme, geriye dönük uyumluluk politikası ve eski sürümlere geçiş takvimi bu dengeyi kurar.

Dağıtım, performans, izolasyon ve gözlemlenebilirlik

Her parça kendi hattından yayına çıkacaksa, hat standartları ortak olmalıdır: otomatik test, güvenlik taraması, sürüm etiketleme, geri alma yöntemi. Sürüm yönetiminde 'hangi ana uygulama hangi parça sürümüyle çalışıyor' bilgisi izlenebilir olmalıdır; aksi halde bir hata ortaya çıktığında neden kaynaklandığı bulunamaz.

Performans, micro-frontend'in sık gözden kaçan bedelidir. Her parça kendi bağımlılıklarını getiriyorsa aynı kütüphane birden çok kez indirilebilir. Çözüm paylaşılan bağımlılıkları belirlemek, parçaları ihtiyaç duyulduğunda yüklemek (tembel yükleme) ve toplam paket boyutunu ölçmektir. Ölçümü yalnızca geliştirme ortamında değil, gerçek kullanıcı verisiyle yapın.

İzolasyon için stil çakışmalarını (CSS kapsama), global değişken kirliliğini ve olay adı çatışmalarını önleyin. Gözlemlenebilirlik tarafında ise hata kayıtlarına parça adı ve sürümü eklemek, kullanıcı oturumunu parçalar arasında izleyebilmek ve her parça için sağlık göstergesi tanımlamak gerekir. Yönetişim ise parçaları kimin açabildiği, hangi standartlara uyması gerektiği ve eski parçaların nasıl emekliye ayrılacağı sorularına cevap verir.

Sık yapılan hatalar ve öğrenme yolu

Sık yapılan hatalar: • Organizasyonel ihtiyaç olmadan, teknoloji merakıyla başlamak. • Parçaları teknik katmana göre bölmek. • Ortak bağımlılıkları yönetmemek; sürüm uyuşmazlığında beklenmedik hatalar almak. • Performansı ölçmeden büyütmek. • Tasarım sistemini sonradan düşünmek. • Geri alma ve hata durumunu tasarlamamak.

Öğrenme yolu önce klasik tek sayfalık uygulamada bileşen tasarımı, yönlendirme ve derleme araçlarının (bundler) mantığını anlamaktan geçer. Ardından küçük bir deneme uygulaması kurun: ana kabuk (shell) ve ona Module Federation ile bağlanan tek bir parça. Sonraki aşamada ortak bağımlılık paylaşımı, hata sınırı ve parça içi bir gezinmeyi ekleyin. İleri aşamada tasarım sistemi sürümleme, bağımsız dağıtım hattı ve gözlemlenebilirlik çalışması yapın. Gerçek bir ürün üzerinde sınır tasarlama alıştırması, araç bilgisinden daha öğreticidir.

Bu beceriyi Mindset programında nerede çalışırsınız?

Mindset kataloğunda bu konuya odaklanan program Micro Frontend Mimarisi ve Modül Federasyonu eğitimidir. Modül başlıkları şu akışı gösterir: micro frontend karar çerçevesi, Module Federation ile entegrasyon, ortak altyapı ve çapraz kesen ilgiler, tasarım sistemi ve sürümleme, dağıtım, performans ve izolasyon, gözlemlenebilirlik, yönetişim ve bir vaka çalışması.

Programın karar çerçevesiyle başlaması yöntem sırasıyla uyumludur: önce mimarinin gerekçesi, sonra teknik uygulama.