สถาปัตยกรรมไมโครฟรอนต์เอนด์

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

แอป Angular ขนาดใหญ่เพียงแอปเดียว (หรือ "ฟรอนต์เอนด์แบบโมโนลิธ") ทำให้ทุกทีมต้องผูกกับรอบการปล่อยเวอร์ชัน กระบวนการบิลด์ และการนำไปใช้งานชุดเดียวกัน เมื่อทีมเติบโตขึ้น สิ่งนี้จะทำให้ทุกอย่างช้าลง ไมโครฟรอนต์เอนด์ช่วยให้แต่ละทีมส่งมอบงานตามกำหนดเวลาของตนเองได้

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

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

สามารถรวมรีโมตได้ใน เวลาบิลด์ ที่ เซิร์ฟเวอร์ (SSI/เอดจ์) หรือใน เวลาทำงาน บนเบราว์เซอร์ การประกอบในเวลาทำงานด้วย Module Federation เป็นวิธีที่ใช้กันมากที่สุดสำหรับ Angular เพราะยังคงรองรับการนำไปใช้งานอย่างอิสระ

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

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

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

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

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

รีโมตของ Angular ต้องใช้เฟรมเวิร์ก Angular เพียงชุดเดียวร่วมกันขณะทำงาน การโหลด Angular สองเวอร์ชันจะทำให้การฉีดการพึ่งพาเสียหายและทำให้บันเดิลมีขนาดใหญ่ขึ้น เครื่องมืออย่าง Native Federation จัดการการแบ่งปันนี้ให้คุณ

ประโยชน์สำคัญของไมโครฟรอนต์เอนด์คืออะไร

ไมโครฟรอนต์เอนด์แบ่งแอปขนาดใหญ่ออกเป็นรีโมตที่นำไปใช้งานได้อย่างอิสระและโหลดโดยเชลล์โฮสต์ โดยแต่ละรีโมตสอดคล้องกับโดเมนธุรกิจ การประกอบในเวลาทำงานผ่าน Module Federation เป็นมาตรฐานสำหรับ Angular ซึ่งต้องใช้เฟรมเวิร์กเพียงชุดเดียวร่วมกัน แนวทางนี้แก้ปัญหาการผูกกันในระดับทีม แต่ก็เพิ่มต้นทุนด้านการปฏิบัติการอย่างแท้จริง