Mikro Frontend Mimarisi: Ne Zaman İşe Yarar, Nasıl Kurulur?

Mikro frontend mimarisi, bir web uygulamasının arayüzünü farklı ekiplerin ayrı ayrı geliştirip test ettiği ve yayına aldığı parçalara böler; kullanıcı ise yine tek bir ürün görür. Genellikle sayfa düzenini, oturumu ve üst seviye yönlendirmeyi yöneten ince bir kabuk (shell) uygulama ile her iş alanı için (arama, ödeme, hesap gibi) bir mikro frontend bulunur. Kabuk bu parçaları URL'ye göre ya da çalışma anında yükler. Aynı ön yüz üzerinde çalışan birkaç ekip birbirinin sürümünü sürekli bekletiyorsa bu mimari karşılığını verir. Tek ekipli bir projede ise çoğunlukla fazladan build ayarı, sürüm uyumsuzluğu ve daha yavaş sayfalar getirir.

Mikro frontend mimarisinin parçaları

Cam Jackson'ın 2019'da martinfowler.com'da yayımlanan yazısı mikro frontend'i, her biri bağımsız teslim edilebilen ön yüz uygulamalarının birleşip daha büyük bir uygulama oluşturduğu bir mimari tarz olarak tanımlar. Uygulamada iş dört parçaya iner.

Kabuk uygulama (host ya da container da denir) her sayfada ortak olan çerçeveyi çizer, URL'nin ilk bölümünü yönetir, kullanıcının oturumunu tutar ve hangi mikro frontend'in gösterileceğine karar verir. Kabuğu ince tutun. Oraya eklenen her özellik, bütün ekiplerin beklemek zorunda kaldığı bir işe dönüşür.

Her mikro frontend bir iş alanını uçtan uca kapsar ve tek bir ekibe aittir. Kendi reposu ya da klasörü, kendi pipeline'ı ve kendi sürüm takvimi vardır.

Parçalar birbirine sözleşmelerle bağlanır: her mikro frontend'in dışarı açtığı şey (bir bileşen, bir mount fonksiyonu, bir grup route), gönderdiği ve dinlediği olaylar, kabuktan beklediği ortak kütüphaneler. Bu sözleşmeleri herkese açık bir API gibi ele alın: sürüm numarası verin, bir şeyi kaldırmadan önce bir geçiş süresi tanıyın.

Bazı şeyler ise bilerek paylaşılır: tasarım sistemi, kimlik doğrulama istemcisi, loglama ve hata raporlama. Geri kalan hemen her şey ekibin kendi sınırı içinde kalmalı.

Bölmeyi iş alanına göre yapın. "Header ekibi" ile "kenar çubuğu ekibi" neredeyse her değişiklikte birbirini beklemek zorunda kalır. Sepetten sipariş onayına kadar her şeyin sahibi olan bir ödeme ekibi ise çoğu özelliği kimseye sormadan yayına alabilir.

Mikro frontend ne zaman masrafına değer?

Mikro frontend, ekipler arasındaki koordinasyon sorununu çözer. Bu maliyeti üstlenmeden önce şu işaretlere bakın:

• Aynı ön yüz koduna üç ya da daha fazla ekip commit atıyor ve biten işler, aynı sürümdeki başka bir ekibin henüz hazır olmayan değişikliği yüzünden bekliyor.
• Üründe sahibi belli, ortak ekranı az alanlar var: bir e-ticaret sitesinde arama, ödeme ve satıcı paneli ya da herkese açık site ile giriş yapılan uygulama.
• Ön yüz framework'ünü değiştiriyorsunuz ve eski kodla yeni kod aylarca yan yana çalışmak zorunda.
• Bazı alanlar günde birkaç kez yayına çıkmak isterken diğerleri daha yavaş, onaylı bir döngüyle ilerliyor.

Şu durumlarda ise uzak durun:

• Tek bir ekip var, kalabalık olsa bile. Böyle bir ekip, bağımsızlığın hiçbir faydasını görmeden bütün maliyeti öder.
• Sınırları henüz çizemiyorsunuz. Yeni bir üründe alanlar birkaç ayda bir yer değiştirir ve yanlış bir bölmeyi geri almak pahalıya patlar.
• Asıl şikâyet yavaş build'ler ya da birbirine dolanmış bir kod tabanı. Modüler monolit (modül sınırlarına uyulmasının araçlarla denetlendiği, çoğunlukla bir monorepo içinde artımlı build alan tek bir uygulama) bunu çok daha ucuza çözer.
• Sayfalar herkese açık ve performansa duyarlı, ama ekipler arasında yükleme stratejisinin sahibi olacak kimse yok.

Parçaları birleştirmenin beş yolu

Build sırasında birleştirme, her parçayı npm paketi olarak yayımlayıp hepsini tek bir uygulamaya kurmak demek. Bileşen kütüphanesi paylaşmak için makul bir yol. Jackson'ın yazısı ise mikro frontend için buna karşı çıkar: her değişiklik kapsayıcı uygulamanın yeniden build edilip yayına alınmasını gerektirdiği için ekipler yine hep birlikte sürüm çıkmaya mecbur kalır.

Yol bazlı bölme, gerçek bir mikro frontend mimarisinin en basit hâli ve ilk denenecek yol da bu. Sitenin her bölümü ayrı bir uygulamadır ve bir reverse proxy ya da CDN kuralı her yolu doğru uygulamaya gönderir. Next.js bunu Multi-Zones adıyla belgeliyor: aynı alan adında, her biri kendi yollarına bakan ve istenirse farklı bir framework kullanabilen birkaç uygulama. Bir bölgeden (zone) diğerine geçiş tam sayfa yüklemesidir. Bu yüzden dokümantasyon, bölgeler arası bağlantılarda <Link> yerine düz <a> etiketi kullanmanızı ve birlikte ziyaret edilen sayfaları aynı bölgede tutmanızı söylüyor.

Sunucu tarafında birleştirmede sayfa tektir ama parçalardan kurulur. Her ekibin servisi bir HTML parçası döner; bir birleştirme katmanı (kendi sunucunuz ya da Edge Side Includes destekleyen bir CDN) yanıt gönderilmeden önce bunları birleştirir. Bu yaklaşımın Türkiye'den bilinen bir örneği PuzzleJs: Facebook'un BigPipe tekniğinden esinlenen bu çatı, README'sinde Trendyol'un web ve mobil web sitelerini örnek olarak gösteriyor. Repoya Kasım 2024'ten beri commit gelmemiş; yeni bir projede seçmeden önce bunu hesaba katın. Bu yöntem, arama motorlarının HTML'in tamamını görmesi gereken içerik ağırlıklı sayfalara uyar. Bedeli de var: her ekip sunucu tarafında render etmek zorunda kalır ve bir parça yavaşladığında ya da hata verdiğinde sayfanın ne yapacağına sizin karar vermeniz gerekir.

Tarayıcıda çalışma anında birleştirme, çoğu kişinin "mikro frontend" derken kastettiği şeydir: kabuk her mikro frontend'in JavaScript'ini tarayıcıda indirir ve sayfaya yerleştirir. Birkaç ekibin aynı sayfadaki bölümleri birbirinden bağımsız yayına alabildiği tek seçenek budur. Kurulumu en karmaşık olan da bu; yazının geri kalanı çoğunlukla bu yöntemle ilgili.

iframe en güçlü yalıtımı verir; derin bağlantı, boyutlandırma, odak yönetimi, erişilebilirlik ve tutarlı stil konularında ise uğraştırır. Bir geçiş sürecinde eski bir yönetim ekranını gömmek için kabul edilebilir bir yol.

2026'da hangi aracı seçmeli?

• Module Federation 2.0: webpack, Rspack ya da Vite ile build edilen React ve Vue uygulamaları için. Module Federation, 5. sürümden beri webpack'in içinde geliyor. Projenin 2.0 paketleri (webpack ve Rspack için @module-federation/enhanced, Vite için @module-federation/vite) bunun üstüne her remote için bir manifest dosyası, sayfa yüklendikten sonra remote kaydetmeye yarayan bir runtime API, remote'lar arasında tip desteği ve bir Chrome DevTools eklentisi ekliyor. Angular ya da Next.js kullanmıyorsanız buradan başlayın.
• Native Federation: Angular için. Aynı host ve remote modelini ES modülleri ve import map'ler üzerine kuruyor ve Angular CLI'ın esbuild tabanlı builder'ıyla çalışıyor. @angular-architects/native-federation paketinin sürüm numaraları Angular'ınkileri izliyor.
• single-spa: Birkaç framework'ün uzun süre aynı sayfada çalışması gerektiğinde, örneğin AngularJS'ten adım adım çıkarken. Bootstrap, mount ve unmount yaşam döngüsü iyi bilinir ve büyük framework'lerin hepsi için adaptörü var. Yine de geliştirme yavaşladı: son kararlı sürüm 6.0.3 Eylül 2024'te çıktı, 7.0 betalarının sonuncusu da Eylül 2025 tarihli. Module Federation'ın Bridge paketleri de artık bir Vue uygulamasının içinde React uygulaması çalıştırmayı (ve tersini) destekliyor.
• Next.js kullanıyorsanız Multi-Zones'u seçin. Module Federation ekibinin kendi Next.js eklentisi @module-federation/nextjs-mf bakım moduna alındı: bakımcıları Kasım 2024'te App Router'ın desteklenmediğini ve eklentinin bugünkü hâliyle en fazla 2026'nın ortasına ya da sonuna kadar çalışmasının beklendiğini duyurdu; o tarihe geldik. Mart 2026'da projenin baş bakımcısı aynı başlıkta, Next.js 16'ya geçince webpack eklentisinin yine bozulduğunu yazdı.
• Web Components: framework'ten bağımsız bir yerleştirme noktası olarak. Her ekip bir custom element yayımlar, kabuk yalnızca etiketi render eder. React 19, custom element'te aynı adla tanımlı bir property varsa prop'u attribute yerine property olarak atıyor; React'le custom element kullanırken eskiden çekilen zorlukların çoğu bununla bitti. Yine de kodu yükleyecek bir mekanizma gerekiyor ve Shadow DOM yalıtımı ortak tema kullanmayı zorlaştırıyor.

Geri alınabilir bir Module Federation kurulumu

Sorunların çoğu üç ayardan çıkıyor: ortak kütüphanelerin nasıl tanımlandığı, kabuğun remote'ları nereden bulduğu ve remote build'lerin nasıl yayına alındığı.

React'i tek kopya olarak paylaşın

// catalog/webpack.config.js (katalog ekibinin remote'u)
const { ModuleFederationPlugin } = require('@module-federation/enhanced/webpack');

const version = process.env.RELEASE_VERSION; // ör. 1.14.2, CI tarafından verilir
if (!version) throw new Error('RELEASE_VERSION tanımlı değil');

module.exports = {
  output: {
    // her sürüm kendi klasörüne gider, hiçbir şeyin üzerine yazılmaz
    publicPath: `https://cdn.example.com/catalog/${version}/`,
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'catalog',
      filename: 'remoteEntry.js',
      manifest: true, // mf-manifest.json dosyasını da üretir
      exposes: {
        './ProductList': './src/ProductList.tsx',
      },
      shared: {
        react: { singleton: true },
        'react/': { singleton: true }, // react/jsx-runtime
        'react-dom': { singleton: true },
        'react-dom/': { singleton: true }, // react-dom/client
      },
    }),
  ],
};

singleton: true ile sayfada React'in yalnızca bir kopyası yüklenir. Kabuk ve remote farklı sürümlerle build edildiyse Module Federation yüksek sürümü yükler ve düşük sürümlü taraf için konsola uyarı yazar. Build sırasında hata çıkmaz; eski bir React ile build edilmiş remote, kabuğun yeni React'i üzerinde sessizce çalışır. Aynı ana sürüm içinde bu genellikle sorun çıkarmaz. Ana sürümler farklıysa remote'un dayandığı ve yeni sürümde değişen her şey çalışma anında bozulur; bunu ilk fark ettiğiniz yer de canlı ortam olur.

Sonu eğik çizgiyle biten anahtarlar da önemli. 'react' anahtarı yalnızca react paketinin kendisine yapılan import'ları yakalar; alt yollardan yapılan import'lar paylaşılmaz, remote'un içine paketlenir. Yeni JSX dönüşümüyle derlenen her bileşen react/jsx-runtime'ı, kendini sayfaya kendisi yerleştiren bir remote da react-dom/client'ı import eder. 'react/' ve 'react-dom/' girdileri olmazsa her remote bu dosyaların kendi kopyasını taşır; react-dom/client için bu, sayfada ikinci bir React DOM demektir.

@module-federation/enhanced webpack'in iç dosyalarını da kullanıyor; bu yüzden iki paketin sürümünü kilitleyin ve birlikte yükseltin. Bu yazı en son Ekim 2026'da kontrol edildiğinde webpack 5.112.0 bu dosyalardan birinin yerini değiştirmişti ve @module-federation/enhanced 2.9.2 ile build, Cannot find module 'webpack/lib/util/extractUrlAndGlobal' hatasıyla duruyordu. Webpack 5.111.1 ile build hatasız tamamlanıyordu.

Kabuk remote listesini çalışma anında okusun

Remote adresleri kabuğun build ayarına yazılıysa, bir remote'un başka bir sürümüne geçmek için kabuğu yeniden build edip yayına almanız gerekir. Kurtulmaya çalıştığınız bağımlılık tam olarak bu. Bunun yerine kabuk açılışta küçük bir JSON dosyası okusun ve remote'ları oradan kaydetsin. Kabukta da aynı eklenti kullanılır: name: 'shell', aynı shared bloğu ve remotes alanı olmadan.

// shell/src/index.ts
import { registerRemotes } from '@module-federation/enhanced/runtime';

// remotes.json, kabuğun bundle'ından ayrı olarak yayına alınır:
// { "catalog": "https://cdn.example.com/catalog/1.14.2/mf-manifest.json" }
async function start() {
  const res = await fetch('/remotes.json', { cache: 'no-store' });
  if (!res.ok) throw new Error(`remotes.json ${res.status} döndü`);
  const remotes: Record<string, string> = await res.json();
  registerRemotes(Object.entries(remotes).map(([name, entry]) => ({ name, entry })));
  await import('./bootstrap'); // React uygulamasını render eder
}

start().catch((err) => {
  console.error(err);
  document.getElementById('root')!.textContent = 'Uygulama açılamadı. Lütfen sayfayı yenileyin.';
});

Her remote build'ini kendi klasörüne koyun

Her ekibin pipeline'ı build çıktısını /catalog/1.14.2/ gibi sürümlü bir yola yükler ve öncekinin üzerine asla yazmaz. Bir remote'u yayına almak, remotes.json dosyasında tek satırlık bir değişikliğe dönüşür. Geri almak o satırı eski hâline getirmekten ibarettir ve hiçbir şey yeniden build edilmez. Sürümlü dosyaları uzun önbellek süresiyle, remotes.json dosyasını ise no-cache ile sunun. Mikro frontend başına bir pipeline'ı GitHub Actions ile kurmak zor değil; yayına alma adımı onay isteyen ayrı bir job olabilir.

Bozuk bir remote bütün uygulamayı düşürmesin

Module Federation'ın varsayılan shareStrategy değeri olan version-first, her ortak kütüphanenin en yüksek sürümünü seçebilmek için açılışta bütün remote'ların giriş dosyasını yükler. Bir remote'un sunucusu çökmüşse, o remote'u hiç kullanmayan sayfalar dahil bütün uygulamanın açılışı takılabilir. Sıkı sürüm eşleştirmesine ihtiyacınız yoksa kabuğun eklenti ayarında shareStrategy: 'loaded-first' kullanın; böylece her remote ancak bir sayfa ona ihtiyaç duyduğunda yüklenir. Bunun bedeli, remote'un kabuğun önceden yüklediği React kopyasını, daha eski olsa bile, kullanmasıdır; aşağıdaki sürüm kontrolü bu yüzden daha da önemli hâle gelir. Her remote'u ayrıca bir error boundary içine alın:

// shell/src/routes/CatalogRoute.tsx
import { lazy, Suspense, type ComponentType } from 'react';
import { ErrorBoundary } from 'react-error-boundary';
import { loadRemote } from '@module-federation/enhanced/runtime';

const ProductList = lazy(async () => {
  const mod = await loadRemote<{ default: ComponentType }>('catalog/ProductList');
  if (!mod) throw new Error('catalog/ProductList yüklenemedi');
  return mod;
});

function CatalogUnavailable() {
  return (
    <p>
      Katalog yüklenemedi.{' '}
      <button onClick={() => window.location.reload()}>Sayfayı yenile</button>
    </p>
  );
}

export function CatalogRoute() {
  return (
    <ErrorBoundary fallback={<CatalogUnavailable />}>
      <Suspense fallback={<p>Katalog yükleniyor…</p>}>
        <ProductList />
      </Suspense>
    </ErrorBoundary>
  );
}

React.lazy başarısız bir yüklemeyi hatırlar; bileşen, sayfa yenilenene kadar hata vermeye devam eder. Bu yüzden yedek ekran kullanıcıdan beklemesini istemiyor, sayfayı yenileme düğmesi sunuyor.

Yayından önce ortak sürümleri kontrol edin

Sürüm uyumsuzluğu yalnızca uyarı ürettiği için bunu CI'da yakalamak gerekir. Her remote'un mf-manifest.json dosyası, build edildiği ortak kütüphaneleri sürümleriyle birlikte listeler. Kabuğun pipeline'ı, yeni bir remotes.json yayına girmeden önce bunları karşılaştırabilir:

// shell/scripts/check-shared.mjs
// yayından önce CI'da: node scripts/check-shared.mjs yol/remotes.json
import { readFile } from 'node:fs/promises';

const major = (v) => v.split('.')[0];
const shellReact = JSON.parse(await readFile('node_modules/react/package.json', 'utf8')).version;
const remotes = JSON.parse(await readFile(process.argv[2], 'utf8'));

for (const [name, url] of Object.entries(remotes)) {
  const res = await fetch(url);
  if (!res.ok) {
    console.error(`${name}: ${url} ${res.status} döndü`);
    process.exitCode = 1;
    continue;
  }
  const manifest = await res.json();
  const react = manifest.shared.find((s) => s.name === 'react');
  if (react && major(react.version) !== major(shellReact)) {
    console.error(`${name} React ${react.version} ile build edilmiş, kabukta ${shellReact} var`);
    process.exitCode = 1;
  }
}

Ekipler arasında yönlendirme, ortak state ve CSS

URL'nin ilk bölümü kabuğun, altındaki her şey ilgili mikro frontend'in olsun: kabuk /hesap/* yolunu hesap ekibine bağlar, ekip kendi route'larını bunun içinde tanımlar. Router paketini singleton olarak paylaşın ki sayfanın tamamı tek bir router kullansın; hiçbir remote kendi browser router'ını oluşturmamalı. Ardından her derin bağlantıyı doğrudan açıp sayfayı yenileyerek test edin. Yalnızca ana sayfadan tıklayarak gelindiğinde çalışan bir mikro frontend, yer imlerinde ve paylaşılan linklerde bozulur.

State'i olabildiğince az paylaşın. Kabuk, ham token'ı window üzerine koymak yerine remote'lara bir getAccessToken() fonksiyonu verebilir. "Sepete ürün eklendi" gibi ekipler arası bildirimlerde, adının başında ekip öneki olan (sepet:urun-eklendi gibi) tarayıcı CustomEvent'leri ekipleri birbirinden ayrı tutar. Ancak bir mikro frontend, kendisi mount edilmeden önce tetiklenen bir olayı hiç görmez; ilk render'da gereken her şey kabuğun sağladığı bir getter'dan gelmeli. Her mikro frontend kendi verisini API'den kendisi çeker.

CSS'te tek global stil dosyası (reset, fontlar, temel tipografi) kabuğa ait olsun; geri kalan stilleri CSS Modules ya da ekibe özel bir sınıf önekiyle o ekibin bileşenleriyle sınırlayın. Renkler, boşluklar ve yazı ölçekleri, bütün ekiplerin kullandığı sürümlü tek bir tasarım token'ları paketinde dursun. Böylece hiçbir ekip diğerinin stilini içe aktarmadan sayfalar tutarlı kalır.

Test, yerel geliştirme ve performans

Her ekip kendi mikro frontend'ini, kabuğun yerine geçen bir mock ile tek başına test eder. Sözleşmelerin de testi olmalı. Module Federation 2.0, bir remote'un dışa açtığı şeyler için TypeScript tipleri üretebiliyor; böylece geriye dönük uyumu bozan bir değişiklik, canlıda boş bir bölüm bırakmadan önce kabuğun build'inde tip hatası olarak yakalanır. Bunlara ek olarak staging'deki birleşik uygulama üzerinde çalışan kısa bir uçtan uca test seti tutun; testlerden biri de bir remote kapalıyken çalışsın.

Günlük işte geliştirici yalnızca değiştirdiği mikro frontend'i yerelde çalıştırır, gerisini staging'den yükler. Module Federation'ın Chrome DevTools eklentisi tek bir remote'u yerel bir build'e yönlendirebiliyor; single-spa projelerinde aynı işi import-map-overrides görüyor.

Performansı birleşik uygulama üzerinde ölçün. İzlenecek değerler şunlar: ilk açılan route'ta indirilen toplam JavaScript, açılışta yapılan remote entry isteklerinin sayısı ve gerçek kullanıcılardan toplanan Largest Contentful Paint. Bütçe koymayı ve gerilemeleri CI'da yakalamayı performans mühendisliği yazımızda anlattık.

Eski bir ön yüzden çıkarken mikro frontend

Mikro frontend'e başvurmanın çoğu zaman en iyi gerekçesi bir geçiştir, bu mimari geçiş bitince kaldırılacak olsa bile. Eski uygulamanın önüne bir reverse proxy koyun, bir bölümü yeni teknolojiyle yeniden yazın ve o bölümün yollarını yeni uygulamaya yönlendirin. İki uygulama aynı alan adında çalıştığı için oturum çerezini paylaşabilir; kullanıcı yalnızca eski bir bölümle yeni bir bölüm arasında geçerken tam sayfa yüklemesi görür. Son bölüm de taşındığında proxy kuralı ve eski uygulama ortadan kalkar. Önce neyi taşıyacağınızı seçmeyi legacy sistem modernizasyonu yazımızda ele aldık.

Proxy ile bölmek yalnızca ekranları kapsar. Aynı projede backend de değişiyorsa verinin taşınması ve doğrulanması için ayrıca zaman ayırın. Müşterimiz Oplist'in hastane vardiya planlama yazılımını Flutter Web ve Flask'tan React ve Node.js'e taşırken en çok zorlandığımız konular zaman ve veri bütünlüğü oldu.

Sık sorulan sorular

Mikro frontend ile mikroservis aynı şey mi?

Mikro frontend aynı fikri tarayıcıya taşır: sahibi belli, bağımsız yayına çıkan küçük parçalar. Mikroservis şart değildir. Bir mikro frontend ortak bir API'yi çağırabilir ya da ekibi ona ait bir backend'i de yönetebilir; çoğu kurulumda ikisi bir arada bulunur.

Mikro frontend SEO'ya zarar verir mi?

Yol bazlı bölme ve sunucu tarafında birleştirme tam HTML gönderir; arama motorları sayfaları eskisi gibi görür. Tarayıcıda birleştirmede ise remote'ların içeriği ancak JavaScript çalıştıktan sonra ortaya çıkar. Google JavaScript'i render ediyor, ama kendi kılavuzuna göre bir sayfa render kuyruğunda birkaç saniyeden uzun bekleyebilir ve her bot JavaScript çalıştıramaz. Arama sonuçlarında yer alması gereken herkese açık sayfalarda sunucuda render eden yöntemlerden birini seçin.

Her mikro frontend'in ayrı bir reposu olmalı mı?

Şart değil. Bir mikro frontend'i bağımsız kılan, kendi build'i ve kendi yayına alma adımıdır. Monorepo'da ortak bir kütüphaneyi her yerde tek seferde güncellemek kolaylaşır. Ayrı repolar ekip sınırlarını daha net çizer, ama her ortak güncelleme her repoda ayrı bir pull request demektir. Next.js'in Multi-Zones dokümantasyonu da bölgeler için aynı şeyi söylüyor: herhangi bir repoda durabilirler, kod paylaşmak içinse monorepo çoğu zaman daha pratiktir.

Bir ekip kaç mikro frontend'in sahibi olmalı?

Çoğu durumda bir, en fazla iki. Her mikro frontend kendi pipeline'ını, kendi remote entry isteğini ve sabit tutulması gereken bir sözleşmeyi beraberinde getirir. Üç parçanın sahibi olan bir ekip bu maliyeti üç kez öder ve karşılığında bağımsızlık kazanmaz, çünkü üç parça da yine aynı ekibin takviminde ilerler.

Nereden başlamalı

Karar vermeden önce son çeyrekte başka bir ekibin işini beklediği için geciken sürümleri listeleyin. Liste kısaysa emeğinizi tek uygulama içindeki modül sınırlarına harcayın. Uzunsa bir bölümü yol bazlı bölmeyle kendi uygulamasına taşıyın, birkaç ay öyle çalıştırın ve çalışma anında birleştirmeyi ancak iki ekibin gerçekten aynı sayfada bağımsız olarak yayına çıkması gerektiğinde ekleyin. Ürününüzdeki sınırların nereden geçmesi gerektiği konusunda ikinci bir göz isterseniz web geliştirme ekibimiz memnuniyetle bakar.