Next Steps
Mosaic พิสูจน์รูปทรงแล้ว: storefront ที่ประกอบตอน runtime และหลาย framework ที่แต่ละ slice deploy เองได้ สิ่งที่ Mosaic ตั้งใจละไว้คือทุกอย่างที่เปลี่ยนรูปทรงที่พิสูจน์แล้วให้กลายเป็นระบบระดับ production ส่วนต่อขยายแต่ละข้อด้านล่างบอกว่า สอนอะไร และ เสียบเข้ากับสิ่งที่คุณสร้างไว้แล้วตรงไหน ดังนั้นไม่มีข้อไหนเป็นการเขียนใหม่ทั้งหมด — ทุกข้อคือ commit ถัดไป
SSR and streaming micro-frontends
หัวข้อที่มีชื่อว่า “SSR and streaming micro-frontends”สอนอะไร: วิธี render remote ที่ฝั่ง server แล้ว stream HTML ออกไปใน response แรก เพื่อให้ user เห็น content ก่อนที่ remoteEntry.js ตัวใด ๆ จะโหลด — ช่องว่างที่ใหญ่ที่สุดของ shell ที่ประกอบฝั่ง client
เสียบเข้าตรงไหน: ตอนนี้ shell mount remote ที่ฝั่ง client หลังโหลด (the path of a runtime remote แสดง round trip ให้ดูแล้ว) เพิ่ม server ที่ประกอบ HTML fragment ของ remote เข้ามา — content remote อยู่ที่ฝั่ง server บางส่วนอยู่แล้วผ่าน Astro เริ่มตรงนั้นแล้วขยาย pattern ไปที่ shell ของ catalog และ cart
Module Federation runtime plugins
หัวข้อที่มีชื่อว่า “Module Federation runtime plugins”สอนอะไร: plugin API ของ @module-federation/runtime — hook ที่ดักการโหลด remote เพื่อเพิ่ม retry, สลับ URL ของ remoteEntry ต่อ environment, ยัด auth header, หรือ fall back ไปที่ version ที่ cache ไว้ตอน remote ล่ม
เสียบเข้าตรงไหน: คุณชี้ remotes ของ shell ไปที่ URL ที่ขับด้วย env อยู่แล้วใน Independent Deployment → runtime plugin คือบ้านที่สะอาดสำหรับ logic นั้น และสำหรับ resilience fallbacks ที่คุณเขียนเป็น error boundary — ย้ายเรื่องตอนโหลดลงไปในตัว loader เอง
A real design-system build and release pipeline
หัวข้อที่มีชื่อว่า “A real design-system build and release pipeline”สอนอะไร: การทำ version และ publish design system เป็น package ของตัวเอง — semver, changelog, และ release ที่ผู้ใช้ upgrade ขึ้นไปอย่างตั้งใจ แทนที่จะให้ทุกคน import HEAD จาก workspace
เสียบเข้าตรงไหน: วันนี้ @mosaic/design-system เป็น workspace package (Tokens & Primitives →) publish ขึ้น registry, pin แต่ละ remote ไว้ที่ version หนึ่ง แล้วตอนนี้การเปลี่ยน token คือ release ที่ทีม catalog และ cart รับไปตามตารางเวลาของตัวเอง — ความเป็นอิสระแบบเดียวกับที่คุณให้ remote นำมาใช้กับ shared layer
Contract testing between shell and remotes
หัวข้อที่มีชื่อว่า “Contract testing between shell and remotes”สอนอะไร: วิธีจับรอยต่อที่พัง ก่อน deploy — ว่า remote ยัง expose ./Catalog อยู่, ว่า <cart-app> ยังรับ attribute ที่ shell ส่งให้, ว่า event ของ bus ยังพา field ที่ผู้ consume อ่านมาด้วย
เสียบเข้าตรงไหน: จุด mount/interop จาก Module Federation Core → และ event จาก Cross-MFE Communication → คือ contract ของคุณ เขียน test ที่ remote รันใน CI เพื่อ assert surface ที่ตัวเอง expose และ test ที่ shell รันกับ contract ที่ remote publish ออกมา — เพื่อให้ bus.emit('cart:add', …) ที่เปลี่ยนชื่อ field ทำ pipeline พังแทนที่จะทำ cart ของ user พัง
Per-slice observability
หัวข้อที่มีชื่อว่า “Per-slice observability”สอนอะไร: การ trace action เดียวของ user ข้าม slice ที่ deploy แยกกัน — remote version ไหน render, BFF ตัวไหนตอบ, “add to cart” ที่ไม่เคยมาถึงพังตรงไหนกันแน่
เสียบเข้าตรงไหน: ทุก slice มีจุดวาง instrument ตามธรรมชาติ — Hono BFF สำหรับ span ฝั่ง backend, event bus สำหรับ trace ข้าม MFE, และ resilience layer สำหรับ metric ตอนโหลด remote ปั๊ม correlation id ที่ shell แล้วร้อยผ่าน bus และการเรียก BFF ทุกครั้ง
CI/CD per slice
หัวข้อที่มีชื่อว่า “CI/CD per slice”สอนอะไร: pipeline ที่การเปลี่ยน slice เดียว build, test, และ deploy เฉพาะ slice นั้น — หลักฐานเชิงปฏิบัติการของความเป็นอิสระที่สถาปัตยกรรมสัญญาไว้
เสียบเข้าตรงไหน: Independent Deployment → วางไว้แล้วว่า slice ปล่อยเองได้ ต่อสายให้ทำงานจริง: CI ที่ filter ตาม path ใน monorepo เพื่อให้การเปลี่ยนใต้ apps/cart/ deploy UI และ BFF ของ cart แล้วไม่แตะอย่างอื่น พร้อม publish remoteEntry.js ตัวใหม่ที่ shell โหลดในการเข้าครั้งถัดไป
Import maps as an alternative to Module Federation
หัวข้อที่มีชื่อว่า “Import maps as an alternative to Module Federation”สอนอะไร: ว่าการประกอบตอน runtime ไม่ได้มีแค่ Module Federation — import maps ที่มากับ browser resolve bare specifier ไปที่ URL ของ remote ที่มี version ได้ ให้คุณสลับตอน runtime ได้ด้วย tooling ที่น้อยกว่ามาก (และแลกกับ trade-off ที่ต่างออกไป: ไม่มีการเจรจา sharing หรือ dedupe dependency ในตัว)
เสียบเข้าตรงไหน: นี่คือทางเลือกที่คุ้มค่าจะพิจารณาแทนทุกอย่างใน Module Federation Core → ลองประกอบ remote สักตัวผ่าน import map แทน config ฝั่ง MF host แล้วสัมผัสความต่าง — คุณได้ความเรียบง่ายมาแลกกับอะไร คุณเสียการจัดการ shared-singleton ไปแค่ไหน การรู้ทั้งสองอย่างคือสิ่งที่ให้คุณ เลือก Module Federation แทนที่จะใช้เป็นค่าตั้งต้นโดยอัตโนมัติ
นั่นแหละ Mosaic คุณสร้าง storefront ที่หลายทีมเป็นเจ้าของแยกกันได้ ใน framework สามตัว ประกอบตอน runtime — และคุณเถียงแทนทุกรอยต่อในระบบได้แล้ว
กลับมาดูรูปทรงทั้งหมดได้ทุกเมื่อที่ Architecture overview → และพาโค้ดไปต่อได้ที่ source: github.com/avetavos/realworld-mosaic