Belajar Microfrontend - Observability Frontend Multi-App

#Pendahuluan

Ketika aplikasi dipecah menjadi banyak remote yang dimiliki banyak tim, kita kehilangan satu pandangan utuh atas aplikasi. Tanpa observability yang baik, tim tidak tahu remote mana yang melambat, error meningkat di mana, atau KPI manakah yang menurun.

Mengapa penting? Karena di microfrontend, "siapa yang bertanggung jawab atas masalah?" adalah pertanyaan operasional yang harus bisa dijawab dengan data per-tim. Observability memungkinkan tiap remote punya metrik dan error budget-nya sendiri.

#Metrik per Remote

Setiap remote harus diekspos metriknya sendiri, memakai provider seperti Sentry, New Relic, atau RUM (Real User Monitoring):

• Web Vitals (LCP, INP, CLS) — diukur per halaman yang mengandung remote.
• Error rate — semua error yang ditangkap ErrorBoundary + uncaught exception, di-tag per remote.
• Load time remote — berapa lama host memuat dan menghidupkan remote.

import * as Sentry from '@sentry/react'
 
Sentry.withScope((scope) => {
  scope.setTag('remote', 'catalog')
  scope.setTag('version', '1.4.2')
  Sentry.captureException(error)
})

Tag remote dan version memungkinkan triase cepat: error di catalog adalah tanggung jawab tim catalog.

#Trace Request dari Host ke Remote

Karena satu aksi user bisa memicu request yang melintasi host dan beberapa remote, kita butuh tracing untuk melihat jalur lengkapnya. Dengan OpenTelemetry (+ propagasi header), kita bisa menghubungkan:

• Request host (UI) → API gateway → servis backend → kembali.
• Pembebanan resource remote dari CDN.

Trace memberikan gambaran di mana waktu hilang: di jaringan CDN, di render remote, atau di backend.

#A/B & SDK Consistency

Saat beberapa remote memakai analytics SDK (misal berbagi user session), penting agar SDK analytics menjadi true singleton di design-system/paket bersama — satu payload identitas per user, bukan beberapa SDK berbeda yang meng-capture event terpisah sebagai user berbeda.

// dipakai semua remote lewat paket bersama, bukan dinstall terpisah tiap app
export const analytics = createAnalytics({ appId: 'tokoku' })

Dengan shared singleton, identitas user konsisten di seluruh remote, dan aggretasi data tidak terpecah.

#KPI

Dua KPI kunci untuk microfrontend:

#Time-to-Clickable

Ukur berapa lama sejak halaman mulai dimuat sampai user bisa berinteraksi pada bagian yang dikandung remote (bukan sekadar "terlihat"). Remote yang lambat memperbesar metrik ini, jadi ini KPI bersama (host + remote).

#Remote Error Budget per Tim

Setiap remote punya error budget (misal error rate <= 1%) yang dimonitor. Melanggar budget memicu prioritas tim pemilik untuk memperbaiki — bukan tim lain. Ini menyelaraskan akuntabilitas dengan ownership.

#Penutup

Pada episode 16 ini, kalian telah memahami observability frontend multi-app.

Inti yang harus dibawa pulang:

• Metrik per remote: web-vitals, error rate, load time — dengan tag remote/version.
• Tracing request (OpenTelemetry) untuk melihat jalur host → remote → backend.
• SDK analytics singleton agar payload identitas user konsisten.
• KPI: time-to-clickable + remote error budget per tim untuk akuntabilitas ownership.

Di episode 17 selanjutnya, kita akan membahas versioning, compatibility & upgrade di skala tim — kontrak API antar remote dengan semver, menghadapi version skew, canary & feature flag remote, serta compatibility matrix. Pastikan observability kalian terpasang!