Pattern: Micro Frontends (แพตเทิร์น: Micro Frontends)

แนวทาง micro frontend เป็นแพตเทิร์นเชิงองค์กรที่ทำให้ส่วนต่างๆ ของ frontend สามารถถูกพัฒนาและ deploy แยกจากกันได้อย่างอิสระ หากยกคำพูดจากบทความที่แนะนำอย่างยิ่งของ Cam Jackson ในหัวข้อนี้ 3 เราสามารถนิยาม micro frontend ได้ดังนี้ "รูปแบบสถาปัตยกรรมที่แอปพลิเคชัน frontend ซึ่งสามารถส่งมอบได้อย่างอิสระ ถูกประกอบรวมเข้าด้วยกันเป็นภาพรวมที่ใหญ่ขึ้น"

มันกลายเป็นแพตเทิร์นที่สำคัญสำหรับ stream-aligned team ที่ต้องการเป็นเจ้าของการส่งมอบทั้ง backend microservice และ UI ที่รองรับ ในขณะที่ไมโครเซอร์วิสมอบความสามารถ deploy ได้อย่างอิสระให้กับ functionality ฝั่ง backend micro frontend ก็มอบความสามารถ deploy ได้อย่างอิสระให้กับฝั่ง frontend เช่นกัน

แนวคิด micro frontend ได้รับความนิยมมากขึ้นเนื่องจากความท้าทายที่เกิดจาก UI บนเว็บแบบ monolithic ที่หนักไปด้วย JavaScript ซึ่งเป็นลักษณะเฉพาะของ single-page application ด้วย micro frontend ทีมต่างๆ สามารถทำงานและเปลี่ยนแปลงส่วนต่างๆ ของ frontend ได้ ย้อนกลับไปที่ Figure 14-2 ทีม stock ทีม purchase flow และทีม customer profile ต่างก็สามารถเปลี่ยนแปลง functionality ของ frontend ที่เกี่ยวข้องกับ stream งานของตัวเองได้อย่างอิสระจากทีมอื่น

Implementation (การนำไปใช้งาน)

สำหรับ frontend บนเว็บ เราสามารถพิจารณาเทคนิคการแยกส่วนหลักสองแบบที่ช่วยในการ implement แพตเทิร์น micro frontend ได้ การแยกส่วนแบบ widget-based คือการนำส่วนต่างๆ ของ frontend มาต่อรวมกันในหน้าจอเดียว ส่วนการแยกส่วนแบบ page-based คือการแยก frontend ออกเป็นหน้าเว็บอิสระต่างๆ ทั้งสองแนวทางนี้ล้วนคุ้มค่าแก่การสำรวจเพิ่มเติม ซึ่งเราจะพูดถึงกันต่อไป

When to Use It (เมื่อไรควรใช้)

แพตเทิร์น micro frontend มีความสำคัญมากหากคุณต้องการนำ stream-aligned team แบบ end-to-end มาใช้ และกำลังพยายามเลิกใช้สถาปัตยกรรมแบบเลเยอร์ ผมยังนึกภาพว่ามันมีประโยชน์ในสถานการณ์ที่คุณต้องการคงสถาปัตยกรรมแบบเลเยอร์ไว้ แต่ functionality ของ frontend ใหญ่มากจนต้องมีทีม frontend เฉพาะทางหลายทีม

มีปัญหาสำคัญอย่างหนึ่งกับแนวทางนี้ที่ผมไม่แน่ใจว่าจะแก้ได้หรือไม่ บางครั้งความสามารถที่ microservice มอบให้ไม่เข้ากับ widget หรือหน้าใดหน้าหนึ่งอย่างพอดี แน่นอนว่าผมอาจต้องการแสดงคำแนะนำในกล่องบนหน้าเว็บไซต์ของเรา แต่ถ้าผมต้องการสอดแทรกคำแนะนำแบบ dynamic ไว้ที่อื่นด้วยล่ะ เมื่อผมค้นหา ผมอยากให้ระบบ type ahead กระตุ้นคำแนะนำใหม่ๆ โดยอัตโนมัติ ตัวอย่างเช่น ยิ่งรูปแบบการโต้ตอบมีลักษณะข้ามระบบ (cross-cutting) มากเท่าไร โมเดลนี้ก็ยิ่งเข้ากันได้น้อยลงเท่านั้น และเรามีแนวโน้มที่จะต้องหันกลับไปเรียก API ตรงๆ มากขึ้น

Self-Contained Systems (ระบบที่พึ่งพาตัวเอง)

self-contained system (SCS) เป็นสไตล์สถาปัตยกรรมที่เกิดขึ้น อาจเป็นเพราะการขาดความใส่ใจต่อประเด็นด้าน UI ในช่วงแรกๆ ของยุคไมโครเซอร์วิส SCS หนึ่งๆ อาจประกอบด้วยชิ้นส่วนที่เคลื่อนไหวได้หลายชิ้น (อาจเป็นไมโครเซอร์วิส) ซึ่งเมื่อรวมกันแล้วก่อให้เกิด SCS เดียว

ตามคำนิยาม self-contained system ต้องเป็นไปตามเกณฑ์เฉพาะบางข้อ ซึ่งเราจะเห็นว่าซ้อนทับกับสิ่งที่เราพยายามทำให้ได้กับไมโครเซอร์วิสอยู่บ้าง คุณสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับ self-contained system ได้ที่ เว็บไซต์ SCS ที่อธิบายไว้อย่างชัดเจน แต่นี่คือประเด็นสำคัญบางส่วน

• แต่ละ SCS เป็นเว็บแอปพลิเคชันที่เป็นอิสระ ไม่มี UI ที่ใช้ร่วมกัน

• แต่ละ SCS เป็นของทีมเดียว

• ควรใช้การสื่อสารแบบ async ทุกครั้งที่เป็นไปได้

• ไม่มี business code ใดที่แชร์กันระหว่าง SCS ได้

แนวทาง SCS ยังไม่ได้รับความนิยมเทียบเท่าไมโครเซอร์วิส และผมก็ไม่ค่อยพบเจอแนวคิดนี้บ่อยนัก ทั้งที่ผมเห็นด้วยกับหลักการหลายข้อที่มันวางไว้ ผมชอบเป็นพิเศษที่มันเน้นว่า self-contained system ควรเป็นของทีมเดียว ผมสงสัยว่าการที่มันยังไม่ถูกใช้อย่างแพร่หลายนี้เป็นเหตุผลว่าทำไมบางแง่มุมของแนวทาง SCS ถึงดูแคบและเข้มงวดเกินไป ตัวอย่างเช่น การยืนกรานว่าแต่ละ SCS ต้องเป็น "เว็บแอปพลิเคชันที่เป็นอิสระ" นั้นหมายความว่า UI หลายประเภทไม่มีทางถูกนับเป็น SCS ได้เลย นั่นหมายความว่าแอปพลิเคชัน iOS แบบ native ที่ผมสร้างและใช้ gRPC จะนับเป็นส่วนหนึ่งของ SCS ได้หรือไม่

แล้วแนวทาง SCS ขัดแย้งกับไมโครเซอร์วิสหรือไม่ จริงๆ แล้วไม่นะ ผมเคยทำงานกับไมโครเซอร์วิสหลายตัวที่ เมื่อพิจารณาแยกกันแล้วก็เข้าข่ายนิยามของ SCS ได้ในตัวมันเอง มีไอเดียที่น่าสนใจอยู่หลายข้อในแนวทาง SCS ที่ผมเห็นด้วย และหลายข้อเราก็ได้พูดถึงไปแล้วในหนังสือเล่มนี้ ผมแค่รู้สึกว่าแนวทางนี้เข้มงวดเกินไป จนคนที่สนใจ SCS อาจพบว่าการนำแนวทางนี้ไปใช้เป็นเรื่องท้าทายอย่างมาก เพราะอาจต้องเปลี่ยนแปลงหลายแง่มุมของกระบวนการส่งมอบซอฟต์แวร์ทั้งหมด

ผมยังกังวลด้วยว่าแถลงการณ์อย่างแนวคิด SCS อาจนำเราไปสู่การโฟกัสมากเกินไปที่กิจกรรม แทนที่จะโฟกัสที่หลักการและผลลัพธ์ คุณอาจทำตามคุณลักษณะของ SCS ทุกข้อแล้วยังพลาดประเด็นสำคัญไปได้ เมื่อพิจารณาดูแล้ว ผมรู้สึกว่าแนวทาง SCS เป็นแนวทางที่เน้นเทคโนโลยีเพื่อส่งเสริมแนวคิดเชิงองค์กร ดังนั้นผมจึงอยากให้ความสำคัญกับ stream-aligned team ที่ลดการประสานงานลงมากกว่า แล้วปล่อยให้เทคโนโลยีและสถาปัตยกรรมไหลตามมาจากตรงนั้น