Belajar Microfrontend - Deployment & CDN Multiple Remote

#Pendahuluan

Setelah keamanan terkunci di episode 13, saatnya membahas hal yang membuat microfrontend benar-benar berbeda: deployment. Janji utama "independent deploy" baru terwujud jika infrastruktur rilisnya benar. Episode ini membahas model deploy terpisah, versioned manifest, blue-green, caching, dan rollback.

Mengapa penting? Karena simpanan utama microfrontend bukan di kode, melainkan di kemampuan rilis independen — dan itu dimungkinkan oleh arsitektur CDN + manifest yang benar.

#Model Deploy

#Host + Remote Di-Deploy Terpisah

Prinsip utama: host dan setiap remote di-deploy sebagai artefak terpisah, masing-masing ke CDN/object storage-nya sendiri (S3, R2, Cloudflare). Tidak ada "satu deploy untuk semuanya".

Komponen	Artefak	CDN
shell (host)	bundle + index.html	`cdn.example.com/shell/`
catalog	chunk + manifest	`cdn.example.com/catalog/`
cart	chunk + manifest	`cdn.example.com/cart/`

#Build per Remote di Branch/Tim Pemilik

Setiap remote di-build di pipeline milik tim pemilik — di branch mereka, oleh workflow mereka — tanpa menunggu tim lain. Hasilnya di-upload ke CDN yang sesuai.

#Versioned Manifests

mf-manifest.json adalah titik rilis untuk sebuah remote. Ia berisi mapping export → chunk URL untuk versi tertentu:

Manifest versi (isi disederhanakan)

{
  "name": "catalog",
  "version": "1.4.2",
  "exposes": {
    "./CatalogApp": "https://cdn.example.com/catalog/1.4.2/CatalogApp.js"
  }
}

Rilis baru remote = manifest baru. URL manifest bisa di-pin atau di-swap (lihat blue-green di bawah).

#Blue-Green: Swap Manifest/CDN Tanpa Down Host

Karena host memuat remote via manifest (bukan hardcode di bundle), kita bisa menukar manifest lama → baru tanpa me-restart host. Jika remote lama mendarat di path stable (/catalog/latest/mf-manifest.json) dan ter-update, host otomatis memakai versi baru saat user berikutnya memuat.

#Caching: Immutable & Content-Hash

Chunk remote disimpan dengan content-hash di namanya (CatalogApp-abc123.js), sehingga dapat di-cache dengan header immutable — browser tidak perlu mengunduh ulang selama isinya sama:

http

Cache-Control: public, max-age=31536000, immutable

Karena nama file berubah saat isi berubah, tidak pernah ada cache stale. Manifest (yang paling sering di-fetch) di-cache singkat (misal no-cache) agar perubahan rilis terdeteksi.

#Rollback

Jika remote release bermasalah, rollback itu cepat: cukup kembalikan manifest (atau compute alias CDN) ke versi sebelumnya. Karena host tidak di-deploy ulang, rollback satu remote tidak menyentuh yang lain.

Note

Strategi blue-green + manifest-swap memungkinkan rollback dalam hitungan detik/menit tanpa downtime. Ini salah satu keunggulan terbesar microfrontend dibanding monolit yang harus rebuild seluruh bundle untuk rollback satu fitur.

#CI/CD

Arsitektur CI/CD-nya per remote:

Setiap remote punya pipeline sendiri (misal GitHub Actions): test → build → deploy CDN.
Host punya pipeline terpisah.
Pipeline remote bisa memicu "release train" opsional (episode 23).

Contoh deploy satu remote

pnpm --filter storefront-catalog build
pnpm --filter storefront-catalog run deploy:cdn  # upload chunk + manifest

#Penutup

Pada episode 14 ini, kalian telah memahami deployment microfrontend.

Inti yang harus dibawa pulang:

Host + remote di-deploy terpisah ke CDN/object storage masing-masing.
Versioned manifest adalah titik rilis; rilis baru = manifest baru.
Blue-green: swap manifest/CDN tanpa down host.
Caching immutable dengan content-hash; manifest di-cache pendek.
Rollback cepat dengan mengembalikan manifest — tanpa deploy ulang host.
CI/CD per remote: test→build→deploy independen; host pipeline terpisah.

Di episode 15 selanjutnya, kita akan membahas networking: CORS, headers & cross-origin — Access-Control-Allow-Origin untuk remote, hosting same-origin, caching headers, Cross-Origin-Resource-Policy, dan memastikan remote tidak mengekspos API sensitif. Pastikan pipeline deploy kalian siap!