Micro Frontends คืออะไร?
หลายๆ คนคงเคยได้ยินคำว่า Microservices ใช่ไหมครับ Microservices เป็นแนวคิดที่ให้ Software กระจายตัว แยกไปเป็นแต่ละ Business Capability ทำให้แต่ละทีม focus ที่ business มากขึ้น และมีอิสระจากกัน ทำให้โดยรวมธุรกิจสามารถเข้าหาลูกค้าได้เร็วขึ้น
Microservices เป็นนิยามใหม่ แต่ได้รับความนิยมอย่างรวดเร็ว โดยดูจาก Trend
ความนิยมเพิ่งมาเริ่มปลายปี 2014 เท่านั้น แต่ปัจจุบันแทบจะเป็น standard ที่ทุกบริษัทต้องทำตาม
จริงๆ แล้ว นิยามของ Microservices นี่ ครอบคลุมถึง Frontend ด้วย แต่ความเป็นจริง Frontend อาจจะต้องแบ่งกลุ่มตามประเภทผู้ใช้ แทนที่จะเป็น Business Capabilities เช่น App ธนาคารอาจจะแบ่งเป็นลูกค้าส่วนบุคคลกับลูกค้าธุรกิจ และลูกค้าแต่ละประเภทก็จะใช้งานได้ทุก Function เช่น เงินฝาก เงินกู้ ลงทุน บัตรต่างๆ ทำให้ Frontend เดียวกัน ต้องครอบคลุมหลาย Business Capabilities
และในปัจจุบัน ความยุ่งยากในการจัดการ Frontend กลับสวนทางจากในอดีต Frontend มีความหลากหลายมากขึ้น ปริมาณข้อมูล ฟังก์ชั่นต่างๆ ถูกผลักมาอยู่ที่ Frontend มากขึ้น ในขณะที่ Backend เทคโนโลยีอย่าง Cloud, Docker, Toolchain ของ DevOps, Microservices Framework ต่างๆ ทำให้ Backend เล็กลงเรื่อยๆ
ด้วยเหตุผลข้างต้น แทนที่เราจะได้ enjoy กับการ deploy แบบอิสระ แต่ปัญหากลับกลายเป็นว่า สุดท้ายก็ต้องมารอ Frontend ที่ทำงานแบบ Monolith
เป็นที่มาที่เริ่มมีกระแส Micro Frontends โดยปัจจุบัน Micro Frontend ถือเป็น 1 ใน Technology Radar ของ ThoughtWorks (https://www.thoughtworks.com/radar/techniques)
Micro Frontends ทำได้ยากกว่า Microservices เพราะเป็นระบบที่ติดต่อกับผู้ใช้โดยตรง โดย talk เรื่อง Micro frontends ในงาน JSUnconf2018 กล่าวถึง challenges ของ Micro frontends ดังนี้
- Bundle Sizes: ถ้าทำให้แต่ละทีมใช้ JS Framework อิสระจากกัน เหมือนแนวคิดของ Microservices ปัญหาที่ตามมาอาจจะเป็นเรื่อง ขนาดของ App ซึ่งใน client side ขนาดของ App มีผลโดยตรงกับ conversion rate
- Consistent look and feel: User experiences เป็น topic หลักของ client side ถ้าให้แต่ละทีมแยกกันทำถ้าจะให้ consistent กันก็ยาก
- Tooling: tool ของ Frontend นี่ค่อนข้างอิสระจากกันในแต่ละ project บางทีใช้ Grunt บางทีก็ Gulp, Webpack, Rollup, Parcel ต่อให้เป็น tool เดียวกัน script ก็ต่างกัน ทำให้โดยรวม เรามี effort เรื่อง tooling มากขึ้น
- Routing: การเปลี่ยนหน้า รวมถึงการ communicate ระหว่างหน้า ถ้าใช้ JS Framework ต่างกัน อาจจะต้องคิดว่าเราจะเชื่อมหน้าต่างๆ ได้อย่างไร และทำอย่างไรที่จะทำให้ page transition ไม่เสีย user experience
โดยรวมคุณอาจจะมีทางเลือกหลักๆ ดังนี้
- แยก run-time ด้วย url: นี่อาจจะเป็นวิธีที่ classic และถูกต้องตามหลัก Microservices มากที่สุด เพราะ run-time แต่ละ UI แยกออกจากกัน ทำให้แต่ละทีมอิสระจากกัน แต่คุณอาจจะเจอ challenges ที่กล่าวมาข้างต้น
- IFrame: อีกวิธีที่ classic สามารถแยก run-time ได้เหมือนวิธีแรก แต่สามารถฝังตัว IFrame ให้เป็นส่วนหนึ่งของ page ช่วยทำให้คุม user experiences ได้ในระดับหนึ่ง แต่การใช้งาน IFrame มักไม่ง่าย เช่น เวลาต้องแสดง dialog หรือต้องสื่อสารกับ page นอก IFrame
- Micro Frontends framework: มีหลาย implementation เช่น Single SPA ซึ่งเป็น framework สามารถทำ lazy load และ routing บน client side ได้, TailorJs เป็น framework ที่รวม UI ต่างๆ (เรียกว่า fragment) ที่ server side ยืมแนวคิด BigPipe ของ Facebook มาใช้, OpenComponents เป็น framework ต้อง deploy frontend บน registry ของ oc เอง แต่การประกอบ UI สามารถทำได้ทั้งบน client side และ server side
- Web Components: เช่น การใช้ Custom Elements api การใช้ web standard เป็นการลดการพึ่งพา framework ที่อาจเปลี่ยนไปเรื่อยๆ (ลองดูข้อมูลเพิ่มที่ https://micro-frontends.org/)
- ใช้ Framework เดียวกัน: เช่น React/Angular/VueJs โดยแต่ละทีมต้องตกลง Framework และ Version ที่ใช้ร่วมกัน ข้อดีคืออาจจะแก้ปัญหา challenges ข้างต้น แต่แต่ละทีมมี dependency สูงขึ้น และการ upgrade ระบบก็ทำได้ยากขึ้นด้วย
คุณไม่จำเป็นต้องใช้วิธีเดียวก็ได้ เช่น เว็บ Shopping การเลือกสินค้าประเภทต่างๆ อาจใช้ framework เดียวกัน พวก comment หรือ social feature อาจจะเป็น IFrame ส่วนระบบ checkout อาจจะเป็นอีก url นึง
Micro Frontend เป็น concept ที่ยังไม่นิ่ง อนาคตคงมี web standard และ framework มาช่วยเรื่องนี้ ส่วนตอนนี้ถ้าชอบแนวทางไหน ก็ปรับใช้กันได้ครับ