Smashing Podcast ตอนที่ 6 กับ Luca Mezzalira: Micro Frontend คืออะไร?

ปิดท้ายปีนี้ด้วยพอดคาสต์ Smashing อีกอัน! คราวนี้เราจะพูดถึงไมโครฟรอนท์เอนด์ ไมโครฟรอนท์เอนด์คืออะไร? แตกต่างจากแนวทางที่เราอาจมีในขณะนี้อย่างไร มาหาคำตอบจากผู้บุกเบิกไมโครฟรอนท์เอนด์ Luca Mezzalira

แสดงหมายเหตุ

อัพเดทประจำสัปดาห์

• “การเพิ่มฟังก์ชันไดนามิกและ Async ให้กับไซต์ JAMstack” Jason Lengstorf
• “เครื่องมือข้อมูลเชิงปริมาณสำหรับนักออกแบบ UX” Adonis Raduca
• “การสร้างทักษะการใช้เสียงสำหรับ Google Assistant และ Amazon Alexa” Tris Tolliday
• “ Beyond Sprint 0: ทางเลือกสำหรับการบูรณาการทีม” Shamsi Brinn
• “ช่วยให้เบราว์เซอร์ปรับให้เหมาะสมด้วยคุณสมบัติ CSS Contain” Rachel Andrew

ไมโครฟรอนต์เอนด์

• เว็บไซต์ของ ลูก้า เมซซาลิรา
• ลูก้า ทางทวิตเตอร์
• “ไมโคร Frontends อนาคตของสถาปัตยกรรมส่วนหน้า” บน Medium
• อ่านบทความเพิ่มเติมของ Luca เกี่ยวกับไมโครฟรอนท์เอนด์ได้ในบัญชีสื่อของเขา
• หนังสือของลูก้าเรื่อง Front-End Reactive Architectures

การถอดเสียง

Drew McLellan: เขาเป็นผู้เชี่ยวชาญด้านนักพัฒนาซอฟต์แวร์ของ Google ด้านเทคโนโลยีเว็บและผู้จัดการชุมชน London JavaScript ด้วยประสบการณ์มากกว่า 15 ปี ปัจจุบันเขาทำงานเป็นรองประธานฝ่ายสถาปัตยกรรม ซึ่งออกแบบแพลตฟอร์มวิดีโอกีฬา DAZN ซึ่งนำเสนอเนื้อหากีฬาตามความต้องการแก่ผู้ใช้หลายล้านคนที่ดูสดทั้งหมด เขาเป็นผู้เขียนหนังสือ Front-End Reactive Architectures for Apress และยังเป็นผู้ตรวจสอบทางเทคนิคสำหรับ Apress, Packt Publishing, Pragmatic Bookshelf และ O'Reilly ตลอดจนเป็นวิทยากรในที่สาธารณะที่มีประสบการณ์ในการประชุมทางเทคนิคทั่วโลก เขาเป็นคนอิตาลี มีเคราหล่อ และมีความรู้เกี่ยวกับแพลตฟอร์มเว็บอย่างชัดเจน แต่คุณรู้หรือไม่ว่าเขาเคยข้ามทวีปอเมริกาใต้ด้วยนกกระจอกเทศ? เพื่อนที่ยอดเยี่ยมของฉัน ยินดีต้อนรับ ลูก้า เมซซาลิรา สวัสดี ลูก้า คุณเป็นอย่างไรบ้าง?

ลูก้า เมซซาลิรา: ฉันยอดเยี่ยมมาก

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

ลูก้า: โอเค นั่นเป็นจุดเริ่มต้นที่ดี ในความคิดของฉัน โดยปกติเมื่อคุณใช้งานหรือออกแบบโครงการ Green Field ใหม่และคุณต้องการทำงานกับแอปพลิเคชันส่วนหน้า คุณมีสถาปัตยกรรมสองสามแบบที่คุณสามารถใช้ประโยชน์ได้ คุณสามารถใช้แอปพลิเคชันหน้าเดียว คุณสามารถใช้แอปพลิเคชันการแสดงผลฝั่งเซิร์ฟเวอร์ หรือคุณสามารถใช้แอปพลิเคชันแบบหลายหน้าที่ประกอบด้วยหน้า HTML อย่างง่าย เห็นได้ชัดว่าสิ่งเหล่านี้เป็นตัวเลือกที่ถูกต้องและฉันคิดว่านักพัฒนาหลายคนใช้กันมาก ปัญหาจริงที่เรากำลังพยายามแก้ไขคือวิธีที่คุณสามารถขยายแนวคิดเหล่านี้กับทีมแบบกระจายไปยังนักพัฒนาหลายร้อยคนที่ทำงานบนฐานโค้ดเดียวกัน เพราะความจริงก็คือเมื่อคุณกำลังทำงานในแพลตฟอร์มเหล่านี้โดยเฉพาะ เมื่อคุณนึกถึง ตัวอย่างเช่น แพลตฟอร์ม SaaS คุณต้องมีนักพัฒนาหลายคนและหลายทีมที่ทำงานในโครงการเดียวกัน และเห็นได้ชัดว่าวิธีการที่คุณทำการซื้อหรือเก็บรักษานั้นแตกต่างอย่างสิ้นเชิงกับวิธีที่คุณเปิดเผยแคตตาล็อกหรือวิธีแสดงส่วนเฉพาะของแพลตฟอร์ม

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

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

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

ลูก้า: แต่ความจริงก็คือการเสาหิน ดังนั้นแอปพลิเคชันหน้าเดียวและหั่นมันในลักษณะที่จะช่วยให้เราสามารถมุ่งความสนใจไปที่ปัญหาเล็กๆ น้อยๆ ได้ ดังนั้นปัญหาที่เล็กกว่าแอปพลิเคชันทั้งหมดและพยายามแก้ไขในวิธีที่ดีที่สุด ในทางเทคนิคแล้ว เห็นได้ชัดว่านำไปสู่ส่วนอิสระของแอปพลิเคชันส่วนหน้าของคุณที่สามารถปรับใช้ในการผลิตได้โดยไม่กระทบต่อส่วนอื่นๆ ทั้งหมด ดังนั้น ความท้าทายโดยทั่วไปสำหรับ Micro-frontend คือพยายามหาวิธีที่จะใช้แอปพลิเคชันหน้าเดียวหรือแอปพลิเคชันที่แสดงผลฝั่งเซิร์ฟเวอร์ และสร้างสิ่งประดิษฐ์ของสิ่งเหล่านี้ สมมติว่าใกล้เคียงกับโดเมนธุรกิจมากที่สุด และสามารถปรับใช้ได้อย่างอิสระ .

Drew: ดังนั้นฉันหมายความว่าคุณพูดถึงบริการไมโครที่ส่วนหลัง ดังนั้น ตามแนวคิดแล้ว นี่เป็นวิธีแก้ปัญหาที่คล้ายคลึงกัน บริการไมโครจะให้บริการที่ส่วนหลัง แต่ส่งต่อไปยังส่วนหน้า นั่นคือความเท่าเทียมกันอย่างคร่าวๆหรือมีส่วนเกี่ยวข้องมากกว่านั้นหรือไม่?

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

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

ลูก้า: นี่คือสามตัวเลือกที่คุณมี และนอกจากการแต่งแล้ว คุณต้องคิดว่าคุณต้องการกำหนดเส้นทางอย่างไร ดังนั้นวิธีที่คุณกำหนดเส้นทางจากฉันไม่รู้ /login หรือ /signin ไปยังส่วนแคตตาล็อกหรือวัตถุรายละเอียดเฉพาะ นอกจากนี้ที่นี่คุณมีสามตัวเลือก คุณสามารถทำได้ที่แอปพลิเคชันเซิร์ฟเวอร์ คุณสามารถทำได้ในระดับ CDN ด้วย Lambda Edge หรือผู้ทำงานเว็บอื่นๆ ใน CloudFlare หรืออย่างอื่น หรือคุณสามารถทำเว็บไซต์ลูกค้า ดังนั้นคุณจึงมีตรรกะภายใน App Shell ที่คุณบอกว่า โอเค ตอนนี้สำหรับ URL เฉพาะนี้ คุณต้องโหลดมุมมองอื่นหรือไมโครฟรอนท์เอนด์อื่น และส่วนสุดท้ายคือวิธีที่คุณสื่อสารกับ Micro-frontend

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

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

Drew: ดังนั้น แทนที่จะเป็นวิธีแก้ปัญหาทางเทคนิคเฉพาะ ส่วนหน้าของไมโครนั้นเหมือนกับรูปแบบการออกแบบที่คุณจะนำไปใช้ในเทคโนโลยีใดก็ตามที่เหมาะสมกับปัญหาเฉพาะที่คุณกำลังพยายามแก้ไข

ลูก้า: ใช่ มากกว่าเทคโนโลยี ฉันจะเห็นว่าเราเลือกสถาปัตยกรรมที่ใช่สำหรับงานที่เหมาะสม ฉันกำลังพูดถึงตัวอย่าง ... มีเฟรมเวิร์กที่มีชื่อเสียง ซึ่งค่อนข้างใหม่สำหรับ Micro-frontend เรียกว่าเฟรมเวิร์ก Luigi ซึ่งเปิดตัวโดยโอเพ่นซอร์ส SAP สิ่งที่พวกเขากำลังทำคือสร้าง iframes บางตัวที่ห่อหุ้มไมโครฟรอนท์เอนด์ไว้ข้างใน ดังนั้น ถ้าคุณคิดเกี่ยวกับเรื่องนั้น สมมติว่า ใช้ iframes ในปัจจุบัน คุณอยู่ในเว็บไซต์สาธารณะที่อาจจะเป็น SEO หรือคุณลักษณะอื่นๆ ที่จำเป็น อาจเป็นปัญหาได้

ลูก้า: แต่ในกรณีของ SAP ถ้าคุณคิดดู พวกเขามีแอปพลิเคชันระดับองค์กรที่สามารถควบคุมเบราว์เซอร์ที่ผู้ใช้ใช้ ควบคุมสภาพแวดล้อมได้ ไม่จำเป็นต้องพร้อมใช้งานในหลายๆ เบราว์เซอร์เวอร์ชันต่างๆ ดังนั้นสำหรับพวกเขา สิ่งเหล่านี้ทำให้พวกเขามีบางพื้นที่ของแอปพลิเคชันที่คงที่และมีพื้นที่บางส่วนที่เปลี่ยนแปลงอย่างอิสระโดยไม่มีปัญหาใดๆ แต่เห็นได้ชัดว่าโซลูชัน iframe จะไม่ทำงานในสถานการณ์อื่น ขอยกตัวอย่างอื่น Spotify เรากำลังใช้ iframes ในตอนเริ่มต้น อันที่จริง สิ่งพิมพ์บนโต๊ะทำงานยังคงประกอบด้วย iframe หลายตัว และ iframe แต่ละตัวก็เป็นแอปพลิเคชั่นเล็กๆ ที่ฉันทำอย่างนั้น ไม่รู้สิ แค่เครื่องเล่นเพลงหรือแค่คำแนะนำของพวกเขา ไม่ว่ามันจะเป็นอะไรก็ตาม พวกเขาพยายามที่จะใช้แนวทางเดียวกันบนเว็บ แต่พวกเขาปฏิเสธว่าในปีนี้เพื่อย้ายกลับไปใช้แอปพลิเคชันหน้าเดียว

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

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

Drew: คุณได้กล่าวไว้ก่อนหน้านี้ว่า Micro-frontend สามารถช่วยจัดโครงสร้างทีมภายในองค์กรของคุณได้อย่างไร และมีผู้คนจำนวนมากทำงานในแอปพลิเคชันเดียวกัน มีความหมายอะไรบ้างและมันสร้างความแตกต่างหรือไม่หากทีมของคุณมีการกระจายหรืออยู่ร่วมกันหรือมีความท้าทายใด ๆ ที่ต้องเผชิญที่นั่น?

ลูก้า : ครับ ฉันสามารถบอกคุณได้ว่าเรื่องราวของ DAZN คืออะไร นั่นคือบริษัทที่ฉันทำงานอยู่ ขณะนี้อยู่ใน DAZN เรามีความท้าทายที่ดี ดังนั้นขณะนี้ เรามีพนักงานมากกว่า 300 คนที่ทำงานทั้งส่วนหน้าและส่วนหลังของแพลตฟอร์มของเรา เป็นแพลตฟอร์ม OTT ที่ถ่ายทอดสดการแข่งขันกีฬาทั่วโลก และที่น่าสนใจคือถ้าไมโครเซอร์วิสทั้งหมดเรารู้วิธีจัดการมากหรือน้อยและเราได้กระจายทีม ดังนั้นเราจึงมีศูนย์พัฒนาสี่แห่ง เราต้องการให้ทีมอยู่ในศูนย์พัฒนาแต่ละแห่งเป็นแนวหน้า และเราลองใช้วิธีนี้แล้วและได้ผลค่อนข้างดี ดังนั้นด้วยไมโครฟรอนท์เอนด์ เราจึงสามารถจัดเตรียมโดเมนธุรกิจต่างๆ ในสถานที่ต่างๆ และอนุญาตให้มีการสื่อสารข้ามกันระหว่างทีมภายในโดเมนธุรกิจเฉพาะ เนื่องจากกรณีที่เลวร้ายที่สุดคือถ้าคุณต้องพูดคุยกับทีมอื่นในโดเมนธุรกิจเดียวกัน คุณเพียงแค่เดินไปถึงโต๊ะทำงานของคุณ หากคุณต้องการพูดคุยเกี่ยวกับเรื่องเฉพาะในทีมจัดจำหน่าย ดังนั้นกับใครบางคนในลอนดอนแทนที่จะเป็นอัมสเตอร์ดัม หรือแทนที่จะคุยเรื่องบริษัทในโปแลนด์ คุณเพียงแค่โทรหา

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

ลูก้า: เห็นได้ชัดว่ามีจุดติดต่อระหว่างพื้นที่เหล่านั้น แต่ก็มีหลายวิธีที่คุณสามารถพูดได้ว่าบรรเทาและมีการประชุมเชิงปฏิบัติการเบื้องต้นกับทีมต่างๆ ที่อยู่ในสถานที่ต่างกัน แล้วจึงทำงานตามสัญญา API เดียวกันหรือ เป้าหมายเดียวกันกับการมีด่านระหว่างการพัฒนา แต่ข้อดีของการเข้าหาที่อนุญาตให้เข้าถึง Micro-frontend คือความจริงที่ว่าในที่สุดเราก็เข้าใจอย่างลึกซึ้งว่าระบบของเราทำงานอย่างไร เรานั่งลงและวิเคราะห์ว่าเราถูกจัดโครงสร้างอย่างไร และเราไม่เพียงเปลี่ยนวิธีที่เราได้รับผลกระทบเท่านั้น แต่ยังรวมถึงวิธีที่บริษัททำงานด้วย และนั่นเป็นแนวทางที่แตกต่างไปจากที่พวกเขาเคยเห็นมา แต่เป็นการพิสูจน์ว่าทำงานได้ดีในกรณีที่แต่ละทีมสามารถโต้ตอบกับทีมในตำแหน่งเดียวกันในโดเมนเดียวกันได้

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

Drew: และทุกทีมเหล่านี้จำเป็นต้องใช้เหมือนเฟรมเวิร์ก JavaScript มาตรฐานหรือไม่ พวกเขาทั้งหมดจำเป็นต้องเข้ารหัสในสิ่งเดียวกันหรือไม่ พวกเขาทั้งหมดต้องเป็น React หรือ Angular หรือเพื่อเปิดใช้งานการทำงานร่วมกันระหว่างพวกเขา หรือผู้คนสามารถใช้สิ่งที่แตกต่างกันสำหรับ Micro-frontend ที่แตกต่างกันได้หรือไม่

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

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

ลูก้า: ความงามของแนวทางเหล่านี้ทำให้เราสามารถตัดสินใจได้อย่างอิสระว่ามีเครื่องมือที่เหมาะสมสำหรับงานที่ถูกต้อง มากกว่าการมีตัวส่วนร่วมทั่วทั้งกอง เพราะอย่างที่คุณจินตนาการได้ เมื่อคุณเริ่มทำงานในโครงการ การตัดสินใจของคุณในช่วงสองสามปีแรกอาจแตกต่างไปจากการตัดสินใจของคุณในวิถีที่บริษัทเติบโต ธุรกิจมีการพัฒนา และสิ่งเหล่านี้กลายเป็นผู้ใหญ่มากขึ้น และความท้าทายแตกต่างไปจากเดิมอย่างสิ้นเชิง ดังนั้นมันจะไม่ยืดหยุ่นพอหรือคล่องตัวเพียงพอ ถ้าคุณลองคิดดู ความจริงที่ว่าเรายึดติดอยู่กับการตัดสินใจแบบเดียวกับที่เราใช้เมื่อสองปีก่อน โดยเฉพาะอย่างยิ่งสถาบันอย่าง DAZN ที่เราย้ายจากศูนย์เป็น 3,000 คนในสามปี อย่างที่คุณสามารถจินตนาการได้ว่าเป็นการเติบโตอย่างมากและเป็นการเติบโตอย่างมากสำหรับบริษัทและฐานผู้ใช้

Drew: มีวิธีที่กำหนดไว้สำหรับ Micro-frontend ที่แตกต่างกันในการแบ่งปันข้อมูลและสื่อสารระหว่างกันหรือไม่ ตัวอย่างเช่น เพียงเพื่อให้แต่ละฝ่ายมีมุมมองเดียวกันหรือมีวิธีทำเช่นนั้นหรือไม่?

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

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

Drew: ฟังดูเหมือนเป็นแนวคิดที่น่าสนใจมาก และฉันอาจเห็นข้อดีมากมายในการทำงานในลักษณะนี้ แต่ก็ไม่สามารถไม่มีความท้าทายได้อย่างแน่นอน มีสิ่งใดบ้างที่ยากต่อการจัดการเมื่อสร้างสิ่งต่าง ๆ ด้วยวิธีนี้?

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

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

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

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

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

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

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

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

ลูก้า: ดังนั้น Micro-frontend จึงมีระดับความยืดหยุ่นและต้องใช้ความพยายามอย่างมากในการกำหนดสิทธิ์ในการกำกับดูแล เพราะเมื่อคุณมีสิทธิในการปกครอง ทุกอย่างก็จะราบรื่น บ่อยครั้งและโชคไม่ดีที่ฉันจะพูดบ่อยเกินไป ฉันเห็นบริษัทที่พวกเขาใช้เวลาไม่เพียงพอในด้านการกำกับดูแล เช่น ทำความเข้าใจ CICD เพราะพวกเขาไม่คิดว่าสิ่งนี้สำคัญ แต่สำหรับไมโครฟรอนท์เอนด์ เช่น ไมโครเซอร์วิส การมีระบบอัตโนมัติที่เหมาะสมจะช่วยให้คุณพัฒนาได้เร็วขึ้น หากคุณใช้เวลาไม่เพียงพอกับบิตการทำงานอัตโนมัติ คุณเสี่ยงที่จะมีภาระมากกว่าผลประโยชน์

Drew: ฉันเดาว่ามันเหมือนกับหลายๆ อย่างในโลกของการพัฒนาเว็บที่ผู้คนตกอยู่ในอันตรายจากการดำดิ่งลงไปด้วยวิธีแก้ปัญหาทางเทคนิคก่อนที่พวกเขาจะเข้าใจปัญหาจริงๆ และดูเหมือนว่าด้วย Micro-frontend จะเป็นกรณีที่คุณต้องดูปัญหาแล้วใช้วิธีแก้ปัญหาเพื่อดูว่าคุณกำลังแก้ปัญหาอะไรอยู่ ฉันเดาว่าธรรมชาติของไมโครฟรอนท์เอนด์ทำให้ง่ายต่อการเริ่มต้นการรวมเข้ากับแอปพลิเคชันที่มีอยู่ เพื่อระบุปัญหาเล็ก ๆ และสลับกับไมโครฟรอนท์เอนด์เพื่อแก้ปัญหานั้น นั่นเป็นข้อเสนอแนะที่สมเหตุสมผลหรือไม่?

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

ลูก้า: สิ่งที่เราทำในกรณีของเรานั้นโดยทั่วไปแล้วจะใช้รูปแบบ strangler ซึ่งเป็นรูปแบบที่รู้จักกันดีสำหรับไมโครเซอร์วิส แต่ในส่วนหน้า ดังนั้นตาม URL และตามเบราว์เซอร์และประเทศของผู้ใช้ อย่างช้าๆ แต่มั่นคง โดยพื้นฐานแล้วเรากำลังฆ่าเสาหิน ซึ่งในกรณีนี้คือแอปพลิเคชันหน้าเดียว การเปิดตัวแอปพลิเคชันใหม่ของเราบ่อยขึ้น และเห็นพฤติกรรมของผู้ใช้ หากเป็นการปรับปรุงประสบการณ์ก็ทำให้เกิดปัญหากับระบบของเรา หรือไม่. และนั่นทำให้เราสามารถให้คุณค่ากับธุรกิจได้ทันที แต่ในขณะเดียวกันก็ช่วยให้เราสามารถทดสอบสมมติฐานของเราและดูว่าเรากำลังไปในทิศทางที่ถูกต้องหรือไม่

Drew: ดูเหมือนจะเป็นวิธีการแก้ปัญหาที่น่าสนใจมากสำหรับปัญหาบางอย่างที่ฉันแน่ใจว่ามีคนจำนวนมากกำลังเผชิญอยู่ ถ้าฉันในฐานะนักพัฒนา ต้องการเริ่มตรวจสอบเพิ่มเติมเกี่ยวกับ Micro-frontend จะเริ่มที่ไหนดี

ลูก้า: ใช่ ตอนนี้ฉันใช้เวลาว่างมากในการพยายามสนับสนุนสถาปัตยกรรมเหล่านี้ เพราะฉันคิดว่ามีความเข้าใจผิดมากมาย ในบัญชีสื่อของฉัน ฉันได้เขียนบทความหลายบทความที่มีอยู่ในนั้นเช่นกัน บันทึกวิดีโอจำนวนมากในการประชุมที่คุณสามารถหาได้บน YouTube โดยไม่มีปัญหาใดๆ และอีกสิ่งหนึ่งที่ฉันอยากจะแนะนำถ้าคุณกำลังมองหาตัวอย่างโค้ดบนเฟรมเวิร์กบางตัว สิ่งที่ผมอยากจะแนะนำให้เริ่มต้นด้วยคือ SPA เดียว ส่วนใหญ่เพราะมันมีวิธีการแบ่งแนวตั้ง ทำให้ง่ายต่อการหยิบขึ้นมาและ คุณสามารถเริ่มเข้าใจถึงประโยชน์ของสถาปัตยกรรมนี้ แล้วมีอีกมากมายที่สามารถใช้ได้ Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.