İçeriğe atla

Kapatmak için ESC tuşuna basın

Modern webin yedi başarısızlığından altyapı ekiplerine dersler

Web SQL'den micro front end'e yedi örnekten çıkan web mimarisi dersleri ve bunların platform, CI/CD ve deploy kararlarına yansıması.

Yazar
Sezer Şanlıkan
Yayın
2 Kasım 2026,
Okuma
4 dakika
Bu haberde
  1. Micro front end nedir, ne işe yarar?
  2. Bu liste neden altyapı ekibini de ilgilendiriyor
  3. Web mimarisi dersleri platform tarafına nasıl uyuyor
  4. AMP ve golden path dayatması
  5. Bundle maliyetini pipeline’da yakalamak
  6. SSR’a dönüş sunucu tarafına iş yüklüyor

Modern web tarihindeki yedi başarısız teknolojiyi inceleyen bir yazı, Web SQL, Angular 2, Flow, Google AMP, runtime CSS-in-JS, micro front end ve yalnızca client’ta çalışan SPA (single-page app) örneklerinden web mimarisi dersleri çıkarıyor. Yazara göre bu teknolojilerin çoğunda fikir iyiydi, çöküş uygulamadan geldi.

Micro front end nedir, ne işe yarar?

Micro front end, bir web arayüzünü bağımsız geliştirilen, test edilen ve deploy edilen küçük parçalara bölen mimari yaklaşımdır. Microservice fikrini tarayıcı tarafına taşır. Genellikle aynı ürün üzerinde çalışan çok sayıda ekibi olan büyük kuruluşlar kullanır. Alternatifi, tek bir build ile yayımlanan ve içinde modüllere ayrılmış monolitik frontend uygulamasıdır.

Bu liste neden altyapı ekibini de ilgilendiriyor

Yazıdaki yedi örneğin hiçbiri kötü bir fikirle başlamadı. Hepsi uygulamada çöktü. Metin frontend tarihi gibi okunuyor ama hataların çoğu platform ve DevOps kararlarında aynen tekrar ediyor.

Aşağıdaki web mimarisi dersleri, iç platform kuran, pipeline şablonu yazan ya da frontend ekibine altyapı veren herkes için doğrudan karşılık buluyor.

Web mimarisi dersleri platform tarafına nasıl uyuyor

  • Web SQL: Chrome’a giren Web SQL, aslında SQLite etrafında ince bir wrapper’dı. Mozilla ve Microsoft tüm spesifikasyonu tek bir C kütüphanesine bağlamayı reddetti, sonunda deprecation geldi. Platformdaki karşılığı şu: “standart” diye seçtiğiniz şey aslında tek bir projenin davranışıysa, o proje yön değiştirdiğinde siz de değişmek zorunda kalırsınız. Araç seçerken arkasında bir spesifikasyon ve birden fazla bağımsız implementasyon olup olmadığına bakın.
  • Angular 2: Geriye uyumsuz rewrite, büyük kurumsal kod tabanlarına geçiş yolu bırakmadı. React bu boşluktan girdi. İç kütüphanelerde, paylaşılan Helm chart’larında ve pipeline şablonlarında breaking change çıkarıyorsanız eski ve yeni sürümün bir süre birlikte çalışabildiği bir yol bırakın. Kullanıcılarınız iç ekipler olsa bile yol bulamazlarsa alternatif ararlar.
  • Flow: Facebook içinde büyüyen Flow, dışarıda hatalıydı, ağır bir arka plan sunucusu istiyordu ve Windows’ta çöküyordu. İç araçlarda en sık görülen hata budur. Yazan ekibin makinesinde ve kendi CI ortamında çalışan bir CLI, başka bir işletim sisteminde dağılabilir. Paylaşmadan önce farklı ortamlarda çalıştırın.

AMP ve golden path dayatması

Google, AMP’yi yayıncılara arama sıralaması tehdidiyle kabul ettirmeye çalıştı. Yazar aynı dinamiğin küçük şirketlerde de görüldüğünü söylüyor: yukarıdan dayatılan katı standartlar sürtünme ve direnç üretiyor.

Platform mühendisliğindeki golden path yaklaşımı bu tuzağa yakın duruyor. Zorunlu tek bir deploy şablonu ekiplerin işini zorlaştırıyorsa ekipler etrafından dolanır. Elle açılmış kaynaklar ve kayıt dışı pipeline’lar böyle çıkar. Golden path, tek izinli yol olduğu için değil, en kolay yol olduğu için seçilmeli.

Bundle maliyetini pipeline’da yakalamak

Runtime CSS-in-JS ve micro front end örnekleri aynı yere çıkıyor: developer experience için ödenen bedeli kullanıcının cihazına yüklemek. CSS-in-JS, tarayıcının yerel olarak hızlı yaptığı stil işini tek thread’li JavaScript motoruna devretti. Micro front end’lerde ise ekipler aynı sayfaya birden fazla bundle, tekrarlanan bağımlılıklar ve zaman zaman yarışan framework sürümleri gönderdi.

Bu şişmeyi ilk yakalayabilecek yer pipeline. Aynı paketin birden fazla sürümü bağımlılık ağacına girmiş mi, build öncesinde bakabilirsiniz:

npm ls react

Çıktıda aynı paket farklı sürümlerle görünüyorsa ikisi de bundle’a girebilir. Bundle boyutunu her pull request’te raporlayan bir adım, büyümeyi merge’den önce görünür kılar. Micro front end yapısında bu kontrolü her ekibin kendi repository’sinde değil, sayfayı birleştiren yerde yapmak gerekiyor; sorun parçalar yan yana gelince ortaya çıkıyor.

SSR’a dönüş sunucu tarafına iş yüklüyor

Son örnek yalnızca client’ta çalışan SPA’lar. State’i tarayıcıda çoğaltmak dağıtık sistem sorunlarını client’a taşıdı. Yazara göre sektör Next.js gibi full-stack framework’lerle SSR’a (server-side rendering) geri dönmek için beş yıl harcadı.

Bu dönüş ops tarafı için somut bir değişiklik. Önceden statik dosya olarak CDN (content delivery network) üzerinden servis edilen frontend, artık her istekte render yapan bir sunucu süreci demek. Yani container image, scaling kuralı, health check, caching katmanı ve log toplama gerekiyor.

Frontend ekibi SSR’a geçmeyi planlıyorsa kapasite planlamasını en başta konuşun. Trafik artışında darboğaz artık CDN değil, render yapan pod’lar olur. Hangi sayfaların cache’lenebildiğini, hangilerinin kullanıcıya özel render gerektirdiğini geçişten önce ayırmak, ilk yük testinde sürpriz yaşamamanın en kısa yolu.

İlgili haberler

Tüm haberler

Yeni yazılardan haberdar olun

Sunucu, Kubernetes, DevOps ve güvenlik üzerine yeni yazılar ve site duyuruları e-postanıza gelsin. Reklam yok, adresiniz kimseyle paylaşılmaz.

© 2021–2026 Sezer Şanlıkan