Micro FrontEnds หนทางแห่งการ Independent Tech Stack สำหรับหน้าบ้าน

Sirawich voungchuy
2 min readNov 22, 2020
ref : https://www.cygnismedia.com/blog/micro-frontends-development/

สวัสดีครับผม ช่วงนี้ไม่ค่อยได้อัพบทความอะไรเลยทั้งยังดองไว้อีกเพียบเลยเนื่องจากบริษัทของผม เริ่มที่จะมี front end developer เข้ามาเพิ่มมากขึ้น สิ่งนึงที่สังเกตได้คือ tech stack ที่ทุกคนใช้มันหลากหลาย บางคนเขียน Reactjs มา 4 ปี บางคนเขียน Angular มา 3 ปีแต่ที่บริษัทของผมใช้ Vuejs ในการพัฒนาหน้าบ้านเป็นหลักทำให้คนที่เพิ่งเข้ามาต้องเสียเวลาในการเรียนรู้ใหม่อีกทั้งการเว็บที่รอการพัฒนารอคิวกันยาวมากและใกล้เข้ามาทุกๆวันมีทั้งเว็บใหม่และหรือที่ต้องทำต่อใน Phase ต่อไปทำให้คนที่ไม่มีประสบการณ์ในการเขียน Vuejs ต้องมานั่งเรียนรู้ใหม่ปัญหาเหล่านี้นำมาสู่ความคิดที่ว่า

จะเป็นยังไงถ้า Frontend teams สามารถทำงานได้โดย independent กันในแต่ละหน้าหรือ Component ของโปรเจค

จะสร้างเว็บหรือเพิ่ม feature ยังไงให้มันไม่กระทบต่อระบบเดิมหรือ Component อื่นเมื่อมันเกิดปัญหา

เนื่องจาก Backend ของบริษัทผมทำ Microservice แล้วมันดีย์เลยลองเอาหลักการนี้มาทำกับหน้าบ้านบ้าง ไปๆมาๆก็เจอเจ้า Micro frontend มันคือ

การแบ่ง Monolithic App ไปเป็นเล็กๆหลายๆแอพ (โดยแต่ละแอพเล็กนั้นรับผิดชอบ feature ที่แน่นอนและชัดเจน)

คำถามต่อมา ถ้าแบ่งแล้วจะเอา project ทั้งสองหรือหลายๆอันมาเชื่อมต่อหรือตัดสินใจว่า micro frontend ส่วนใหนที่จะนำมาแสดงยังไงหว่า ?

คำตอบคือมีหลายวิธีมากแล้วแต่การใช้งาน ดังรูป

https://speakerdeck.com/squer/micro-frontends-beyond-the-buzzword?slide=28

มาไล่ดูแต่ละ integration กัน (ขอเว้น ServerSide integration นะครับยังไม่เคยลอง)
สมมุติว่าเราตกลงปลงใจที่จะใช้ micro frontend ทำกันในหนึ่งโปรเจค โดย TeamA รับผิดชอบ Component_1 และ TeamB รับผิดชอบ Component_2 ดังรูป

flow

Build time integration <ใช้ไม่ใช้ก็เรียกก่อนละกัน>

1.TeamA develops Component_1
2.ถึงเวลา Deploy ก็นำ Component_1 ไป Publish ให้มันเป็น NPM Package
3.ก็จะมี Component_1 อยู่ใน NPM Register
4.ทีมที่ดูแลเกี่ยวกับ Container ก็นำ Component_1 ไปติดตั้งเหมือนกับ Dependency ตัวนึง
5.Container Build !
6.เสร็จเท่านี้ bundle ที่ออกมาก็จะมี Component_1 ติดออกมาด้วยแล้ว

⚠️ ฟังดูดีย์และง่ายใช่ไหมล่ะ แต่! มันมีข้อเสียเยอะอยู่เหมือนกัน อาธิเช่น…
1. ถ้า TeamA มีการ Re-deploy ตัวเว็บ Container ก็ต้องมาทำการ Re-deploy ด้วย ฟังแล้ววิธีนี้เริ่มไม่สนุกละ ==’’
2. อันนี้รุนแรง คือ publish แสดงว่าใครก็ได้สามารถเรียกใช้ npm นี้ได้วันนึง Component ของเราอาจจะไปโผล่หน้าเว็บของ บริษัทคนอื่นก็ได้ใครจะรู้….

ด้วยปัญญหาของ Build time เหล่านี้นำมาสู่กรรมวิธีต่อไปคือ

Run time integration <จะใช้เมื่อไหร่ค่อยเรียกเอาเมื่อนั้น>

1.TeamA develops Component_1
2.ถึงเวลา deploy ก็แค่ deploy code ไปเก็บ เช่น https://ggwp.com/component_1.js
3.เวลา User ที่ใช้งานหน้าเว็บทำการ navigates ไปยัง ggwp.com ก็ให้ Container ทำการ fetches component_1.js แล้วทำการ execute มัน

ข้อดีล่ะ

1.Component_1 สามารถ deploy ได้โดยไม่ต้องกังวลว่า Container จะต้อง re-reploy ใหม่ตาม
2.ถ้าเกิด มี Component_1 หลายๆ version ก็ให้ Container เป็นคนเลือกสิ อิอิ

ข้อเสีย

ที่พบอย่างเดียวคือ init time setup จะใช้เวลาเยอะหน่อย( อย่างว่าทำการใหญ่เวลาต้องเยอะ )

วิธี Run time integration เลยเป็นวิธีที่น่าคบสุดแล้วสำหรับการ implement ในทาง frontend เพียวๆ

สรุป

ทั้งนี้ทั้งนั้น micro frontend ก็เป็นอีกแนวทางการแก้ปัญหาหนึ่งเมื่อทีมมีหลากหลายขึ้นและแก้ปัญหา Tech Stack ที่ไม่ตรงกันลดความผิดพลาด เวลาในการเรียนรู้ อีกทั้งยังยืดหยุ่น ไม่ขึ้นอยู่กับทีมใดทีมนึง

Extra เพื่อเตรียมตัวต่อบทความต่อจากนี้
หลายคนคงสงสัยว่าจะใช้อะไรในการ มัดรวม dependencies เข้าใน build file และ serve ไฟล์นั้น คำตอบคือ Webpack นี่เองซึ่งผมได้ทำการเขียน code อย่างง่ายแบบ no framework ทั้งสอง เชื่อมกันโดยใช้ webpack ใน localhost ไว้ ท่านสามารถเข้าไปลองเล่นกันได้ เพราะบทความหน้าผมจะมาทำ micro frontend แบบ coding และ จะเชื่อม Component จาก Vuejs และ Reactjs เข้าด้วยกันโดยใช้ Webpack Federation

repo การทำ micro frontend แบบง่าย (no framework)

https://github.com/SirawichDev/micro-frontend-demo

--

--