Micro Frontends — the New Era of Front-End Edge Technology
เนื่องด้วย talk ล่าสุดของผมเกี่ยวกับ Micro Frontends ในงาน LINE Thailand Developer Conference 2019 อาจมีคนที่ไม่ได้เข้าฟังหรือในระหว่างที่ฟังมีข้อสงสัยที่ยังไม่มีโอกาสได้ถามเพื่อไขข้อข้องใจเกี่ยวกับ Micro Frontends ในบทความนี้ ผมจะมาทบทวนสิ่งที่ได้พูดไปอีกครั้ง แนะนำตัวนิดนึง ผม เต้ นะครับตอนนี้ทำงานเป็น Software Engineer อยู่ที่ LINE ประเทศไทย
ระบบสถาปัตยกรรมในปัจจุบัน
คงปฏิเสธไม่ได้ว่าสถาปัตยกรรมแบบ Microservices นั้นได้รับความนิยมมากในปัจจุบันเมื่อเปรียบเทียบกับการวางโครงสร้างระบบที่เป็นแบบ Monolithic ยุคก่อนๆ เมื่อพูดถึงประโยชน์..หรือว่ามันคืออะไรนั้น มีบทความและหนังสือให้หาอ่านมากมาย
แต่สถาปัตยกรรมแบบ Microservices นี้ถูกนำไปใช้จริงแค่เพียงในการออกแบบระบบหลังบ้าน (back-end) ทว่าฝั่งหน้าบ้าน (front-end) ที่เทคโนโลยีส่วนใหญ่จะวิวัฒนาการเน้นไปในเรื่องการพัฒนา Framework กับ library ใหม่ๆ ซะมากกว่า โดยที่โครงสร้างสถาปัตยกรรมนั้นยังคงเป็น client-server เดิมๆ (ผมเรียกว่า monolithic client ได้ไหมนะ … Monolithic client ⟺ Microservices)
ด้วยระบบฝั่งหน้าบ้านนั้นใหญ่ขึ้นเรื่อยๆ ซับซ้อนขึ้นเรื่อยๆ มีทีมมีคนมากขึ้น รวมทั่งเทคโนโลยีใหม่ๆ ที่จะเข้ามา มันจึงมีคำว่า Micro Frontends ที่คิดง่ายๆ จากข้อดีของ Microservices เองเกิดขึ้นมาเพื่อที่จะตอบรับการเปลี่ยนแปลงของการพัฒนาระบบในปัจจุบัน
เรื่องราวของ Micro Frontends
Micro Frontends เป็นเรื่องที่เริ่มพูดถึงกันมาสักพักแล้วตั้งแต่ช่วงปี 2016 อ้างอิงจากเครื่องมือของบริษัท ThoughtWorks© ที่ชื่อว่า Technology Radar
มาในปีนี้ (2019) Micro Frontends เข้าสู่ช่วง adopt state เป็นที่เรียบร้อยแล้ว นี่เป็นสัญญาณที่ดีมากๆ
Adopt
We feel strongly that the industry should be adopting these items. We use them when appropriate on our projects.
micro-frontend.org
เป็นอีกเว็บไซต์นึงที่ใครหลายๆ คนที่เริ่มศึกษานั้นใช้เป็นแหล่งอ้างอิงหลัก ในเว็บนี้เขามีคำอธิบายอย่างละเอียดทั้งหลักการ (Concept) และตัวอย่าง ใครสนใจแนะนำให้เข้าไปอ่านกันเลยนะครับ
The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specialises in. A team is cross functional and develops its features end-to-end, from database to user interface.
Frameworks & Libraries
มาดูเรื่องของ framework และ library ต่างๆ กันบ้าง มีหลายตัวที่ออกมาเพื่อเติมเต็มในแต่ละด้านของการทำ Micro Frontends แต่ละตัวก็จะใช้หลักการ (Concept) ต่างๆ กันไป — ที่ว่าต่างๆ นั้นคือยังไงเดี๋ยวเราจะไปขยายความกันในส่วนถัดไปอีกที
ในที่นี้ผมยกตัวอย่างมา 4 ตัวที่เห็นได้ชัดเจนถึงความต่างที่แต่ละตัวมีจุดเด่นกันในแต่ละแบบ
- Stencil — เป็น front-end framework ที่เขามุ่งเน้นเรื่องของ Web Components (เขานั้นบอกว่าตัวเองเป็น Compiler แต่ผมขอใช้คำว่า Framework นะครับทุกคนน่าจะเข้าใจง่ายกว่า) การใช้ Web Components นั้นเป็นหนึ่งในวิธีการของ Micro Frontends เหมือนกันครับ
- single-spa — เป็น framework อีกตัวที่ทำให้ front-end framework ทุกตัวมาทำงานร่วมกันได้ (เกือบทุกตัวแล้วกันครับ) และเขาก็บอกเลยครับว่าตัวนี้แหละเครื่องมือสำหรับการทำ Micro Frontends
- opencomponents — framework ตัวนี้ก็จะครบเครื่องขึ้นมาหน่อย คือมีให้ทั้งการทำ component เอง (ในรูปแบบของตัวเอง) การเก็บ component (Registry) แล้วก็การนำมันไปใช้ (Delivery)
- tailor — เป็น web service ที่ใช้ทำ Micro Frontends ที่ใกล้เคียงกับวิธีทำใน Microservices คือมันจะไปเรียก web service ต่างๆ มาประกอบรวมกัน ตัวนี้เป็น Component นึงใน stack สุดอลังที่เรียกว่า mosaic
และก็มีหลายๆ บริษัทที่ scale ค่อนข้างใหญ่เริ่มเข้ามาศึกษาและโฟกัสกับเทคโนโลยีนี้อย่างที่เห็นได้ชัด เช่น Zalando — ecommerce ในเยอรมัน (เขาเป็นคนทำ tailor ขึ้นมา)
แล้วก็ทีม Engineering ของ LINE ประเทศไทยเองก็เช่นกัน เรากำลังศึกษาเรื่องนี้อยู่อย่างจริงจัง
(แล้ว) Micro Frontends คืออะไร?
จากตัวอย่างเครื่องมือที่ผมยกมาข้างต้นนั้นทุกคนพอจะเดากันได้แล้วใช่ไหมครับ ..โอเคเข้าเรื่องกันดีกว่า งั้น Micro Frontends คืออะไร (กว่าจะเข้า)
Micro Frontends คือสถาปัตยกรรมที่ทำให้เราสามารถแยกส่วนของ front-end ออกเป็นส่วนย่อยๆ เพื่อแก้ปัญหาทางการพัฒนาระบบของฝั่ง client โดยเฉพาะหลักๆ 4 ประการ
Technology Agnostic — การไม่ขึ้นต่อเทคโนโลยีใดเทคโนโลยีหนึ่ง การพัฒนา front-end ในปัจจุบันเรามักจะเริ่มต้นด้วยไม่ framework ใด ก็ framework หนึ่ง (อย่าง angular หรือ vue.js) ซึ่งเมื่อเลือกแล้วคงจะเป็นไปได้ยากที่องค์กรนั้นๆ จะเปลี่ยนไปใช้อีกตัวแทนอย่างในกรณีที่เราพยายามจะเลือกเครื่องมือให้เหมาะกับงานส่วนนั้น เนื่องด้วยเราจะเจอปัญหาอย่าง ตัวอย่างเช่นหลายๆ frameworks มักจะทำงานพร้อมกันไม่ได้ หรือ code ส่วนนี้ไปทับส่วนนั้น ด้วยเหตุผลที่ว่า..ชื่ออาจจะซ้ำกัน เป็นต้น แม้จะตัดเรื่องความพร้อมของทีม (ด้านความรู้, การตั้งค่าเครื่องมือ) ออกไป แต่ cost of switch นั้นก็ยังสูงอยู่ดี การเป็น tech agnostic นั้นจะทำลายกำแพงตรงนี้ทิ้งไป ทำให้เราใช้อะไรก็ได้ที่อยากจะใช้ ..เลือกให้เหมาะสมกับงานนั้นๆ (ส่วนนั้นๆ)
Development Autonomy — การพัฒนาอย่างอิสระระหว่างทีม ด้วยระบบที่ใหญ่ขึ้นหรือซับซ้อนขึ้นจำนวนคนจึงจำเป็นต้องเพิ่มตามไปด้วย การทำให้ทีมนั้นสามารถทำงานได้อย่างอิสระแยกขาดออกจากอย่างชัดเจนนั้นจะช่วยให้เกิดความคล่องตัวในการทำงานและการพัฒนาระบบ (agility) อีกทั้งยังสามารถโฟกัสกับ cycle ของทีมได้มากขึ้น จริงๆ เราก็มักจะแบ่งทีมในการทำงานกันเป็นปกติอยู่แล้ว นั่นก็ส่วนหนึ่ง..ถ้าการแบ่งทีมนั้นทำให้การคุยงานกันระหว่างทีมลดลงเหลือแค่จุดที่สำคัญจริงๆ
Isolated Deployment — แยกกันส่งมอบงานโดยไม่เกิดปัญหา นอกเหนือจากสองข้อที่กล่าวมาถ้าหากถึงจุดที่เราต้องส่งมอบงาน (delivery) นั้นต้องไปกองรวมกันอยู่ที่ใดที่หนึ่ง..แบบทีมนี้ต้องรอทีมนั้นทีมนั้นต้องรอทีมนุ้น..ก็คงจะไม่ได้ประสิทธิภาพในการทำงานเท่าไหร่ การทำ flow deployment ที่แยกขาดออกจากกันได้นั้นเป็นการทำให้เราสามารถมั่นใจได้จริงๆ ว่าจะส่งงานขึ้นไปได้โดยไม่ต้องขึ้นอยู่กับส่วนอื่นๆ (ทีมอื่นๆ) ไม่ว่าจะทำระบบ CI/CD ให้ดีหรือใช้ความสามารถของโครงสร้างสถาปัตยกรรมเองก็ตาม
High Resilience — ความยืดหยุ่นต่อความผิดพลาด การแยกสิ่งต่างๆ ออกเป็นส่วนๆ อิสระออกจากกันนั้นก็มีความเสี่ยงอยู่ การทำให้ระบบคงทนต่อความเสียหายที่จะเกิดขึ้นในแต่ละส่วนๆ นั้น ก็เป็นหนึ่งในเรื่องที่ต้องคำนึงถึง การเป็น Micro Frontends นั้นจะต้องสามารถตอบสนองต่อความต้องการตรงนี้ได้ เมื่อส่วนใดส่วนนึงพังลงทั้งระบบยังสามารถทำงานได้หรือเมื่อส่วนใดส่วนนึงทำงานช้าลงก็ตาม ส่วนนั้นต้องไม่ไปกระทบส่วนอื่นๆ ให้ทำงานช้าลงตามไปด้วย
ทั้งหมด 4 ข้อที่กล่าวมานี่ล้วนเป็นปัญหาของการพัฒนาในฝั่ง front-end มาช้านานและเป็นสิ่งที่ Micro Frontends จะเข้ามาแก้ได้
(แล้ว..) Micro Frontends ทำงานยังไง?
อยากให้ย้อนกลับมาดูพื้นฐานง่ายๆ ของการทำ UI (user interface) กันสักนิดครับ
องค์ประกอบของหน้า 1 หน้านั้นประกอบด้วยชิ้นส่วนหลายส่วนอย่างกระจัดกระจาย ทำหน้าที่ต่างๆ กัน อย่างเช่น ปุ่ม checkbox, menu, รูปภาพ, ฟอร์มต่างๆ จากนั้นเรานำสิ่งเหล่านั้นมารวมขึ้นเป็นหน้าแต่ละหน้า..ใช่ไหมครับ เพราะงั้นสิ่งที่บอกว่าสิ่งนี้อยู่ตรงนี้สิ่งนั้นอยู่ตรงนั้นก็คือ “Layout”
Layout เรียกได้ว่าเป็นหนึ่งในส่วนหลักของการทำ front-end เลย แม้ปัจจุบันเราจะเปลี่ยนสไตล์การพัฒนามาเป็น SPA (single-page application) ที่เป็น component-base กันแล้วแต่ก็ยังจำเป็นต้องมี component อย่างน้อยตัวนึงดูแลเรื่อง layout อยู่..ถูกไหมครับ
Core ของการทำ Micro Frontends หรือความเป็น Micro Frontends นั้นก็เริ่มจากที่ layout เช่นกัน
คราวนี้มานิยามส่วนประกอบต่างๆ ใหม่ เรามี layout เพื่อบอกว่าอะไรควรวางอยู่ตรงไหนในแต่ละหน้า แยกออกเป็นกลุ่มๆ ของ UI component/element รวมๆ เราเรียกว่า fragment ส่วนที่ที่ระบุว่าตรงไหนอันนั้นก็คือ slot ต่างๆ ที่แต่ละหน้าอาจมี slot ที่แตกต่างกันไปก็ได้
..เราใช้คำว่า fragment เพราะว่ามันเป็นเหมือนชิ้นส่วนหลายๆ ส่วนมาประกอบรวมกันมากกว่าที่จะเป็น single root component ที่เราคุ้นเคยและใช้ใน front-end framework ทั่วไป และไม่จำเป็นที่จะต้องเป็น framework ใด framework หนึ่ง แค่สามารถสนองต่อความต้องการในส่วนๆ นั้นบน หน้าเว็บไซต์ได้ก็เรียกว่าเป็น fragment ได้เหมือนกัน..
ทบทวนกันอีกรอบ layout เป็นคนประกาศตำแหน่ง slot และ slot เป็นคนบอกว่าเอา fragment ตัวไหนมาวาง
นี่เป็นการทำงานแบบ overview ของสถาปัตยกรรม Micro Frontends แต่ยังมีรายละเอียดอีกพอสมควร ทั้งเรื่อง Layout เองและ Fragment แต่เพื่อไม่ให้บทความนี้ยืดยาวจนเกินไป เดี๋ยวเราค่อยมาลงลึกกันไปทีละตัวในบทความถัดๆ ไปแทนแล้วกันครับ
หวังอ่านกันมาถึงตรงนี้จะทำให้ทุกคนมองเห็นภาพ เข้าใจหลักการและการทำงานของมันกันมากขึ้นนะครับและถ้าตรงไหนผมกล่าวคลาดเคลื่อนไปหรือมีข้อเสนอแนะแสดงความคิดเห็นกันมาได้เรยนะครับ ขอบคุณครับ..
