สารบัญ[ซ่อน][แสดง]
แนวคิดของไมโครเซอร์วิสได้รับความสนใจอย่างมากเมื่อเร็วๆ นี้ และบริษัทหลายแห่งกำลังใช้มันเพื่อขจัดแบ็กเอนด์ขนาดใหญ่ที่มีเสาหินขนาดใหญ่
การใช้เส้นทางเดียวกันกับฟรอนท์เอนด์ยังคงเป็นความท้าทายสำหรับธุรกิจจำนวนมาก แม้ว่ารูปแบบการกระจายของการสร้างเว็บแอปฝั่งเซิร์ฟเวอร์จะเชื่อถือได้มากหรือน้อยในแง่ของการวิจัยและการดำเนินการ
เนื่องจากการพึ่งพาอาศัยกันอย่างใกล้ชิด เสาหินฝั่งไคลเอ็นต์มักจะทำให้การผสานรวมคุณลักษณะใหม่ นำเทคโนโลยีใหม่มาใช้ และปรับขนาดส่วนประกอบแต่ละส่วนได้ยาก
ความท้าทายเหล่านี้และอื่นๆ ได้กระตุ้นให้นักพัฒนาส่วนหน้าตรวจสอบโดยใช้ไมโครเซอร์วิส
ด้วยเหตุนี้ กลยุทธ์ด้านสถาปัตยกรรมใหม่ล่าสุดที่เรียกว่าไมโครฟรอนท์เอนด์จึงได้รับการพัฒนาสำหรับการสร้างเลเยอร์ส่วนหน้าของเว็บไซต์และแอปพลิเคชันบนเว็บ
คำนี้ถูกใช้ครั้งแรกในปี 2016 และตั้งแต่นั้นเป็นต้นมา คำนี้ก็ได้รับความสนใจอย่างมากจากสาเหตุที่ดี
บทความนี้จะให้ความเข้าใจทั่วไปเกี่ยวกับส่วนหน้าของไมโครและปัญหาที่พวกเขากล่าวถึง มันใช้งานได้ดีทั้งข้อดีและข้อเสีย
ข้อมูลเบื้องต้นเกี่ยวกับสถาปัตยกรรมไมโครฟรอนต์เอนด์
วิธีร่วมสมัยของการพัฒนา front-end ที่เรียกว่า micro-frontend architecture แบ่ง a โปรแกรมประยุกต์บนเว็บ เป็นส่วนเล็ก ๆ ที่เป็นอิสระ
สำหรับผู้ใช้ปลายทาง ชิ้นส่วนเหล่านี้ดูเหมือนจะเป็นหน่วยเดียว แม้ว่าจะถูกสร้างขึ้นอย่างอิสระแล้วประกอบเข้าด้วยกันก็ตาม
ด้วยความแตกต่างที่ไมโครฟรอนท์เอนด์เกี่ยวข้องกับฝั่งไคลเอ็นต์ ไม่ใช่ฝั่งเซิร์ฟเวอร์ ของโซลูชันออนไลน์ เหตุผลที่อยู่เบื้องหลังนั้นเหมือนกับไมโครเซอร์วิส
การสร้างผลิตภัณฑ์บนเว็บที่ซับซ้อนนั้นเหมาะสมที่สุดเมื่อใช้แนวทางไมโครฟรอนท์เอนด์
ไมโครฟรอนท์เอนด์ ต่างจากฟรอนต์เอนด์โมโนลิธทั่วไป ทำให้หลายทีมทำงานร่วมกันแยกกันในโครงการซอฟต์แวร์ต่างๆ
โปรแกรมเมอร์สามารถสร้างเว็บแอปได้รวดเร็วยิ่งขึ้นพร้อมความสามารถในการปรับขนาดและการบำรุงรักษาที่มากขึ้นโดยใช้การออกแบบสถาปัตยกรรมนี้
พูดง่ายๆ คือ ไมโครฟรอนต์เอนด์แต่ละส่วนเป็นเพียงโค้ดสำหรับส่วนประกอบที่แตกต่างกันของหน้าเว็บ
คุณลักษณะเหล่านี้ควบคุมโดยทีมที่แยกจากกัน ซึ่งแต่ละทีมมีความเชี่ยวชาญในอุตสาหกรรมหรือวัตถุประสงค์เฉพาะ
เสาหินเทียบกับสถาปัตยกรรมไมโครเซอร์วิสเทียบกับสถาปัตยกรรมส่วนหน้าแบบไมโคร
คิดว่าจะย้ายที่อยู่ จะง่ายกว่าไหมสำหรับคุณที่จะจัดระเบียบทุกอย่างลงในกล่องเล็กๆ จำนวนหนึ่งที่มีป้ายกำกับอย่างเชี่ยวชาญ และย้ายแต่ละกล่องแยกกัน หรือบรรจุพนักงานทั้งหมดลงในกล่องขนาดใหญ่เพียงกล่องเดียวแล้วขนส่งไปยังตำแหน่งใหม่
ทางออกที่ชัดเจนอยู่ที่นั่น
การเปรียบเทียบนี้เปรียบเทียบสถาปัตยกรรมเว็บแอปที่แตกต่างกันสองแบบ ได้แก่ โมโนลิธและไมโครเซอร์วิส (หรือที่เรียกว่าไมโครฟรอนต์เอนด์)
สถาปัตยกรรมเสาหิน
คุณอาจจำ "วันเก่า ๆ ที่ดี" ได้เมื่อแอปพลิเคชันที่สมบูรณ์ถูกสร้างขึ้นเป็นเอนทิตีเดียวที่เหนียวแน่น วิธีการดังกล่าวเรียกว่าหินก้อนเดียว ซึ่งเป็นคำที่เก่าแก่สำหรับบล็อกหินขนาดใหญ่
มันสมเหตุสมผลแล้ว
ระบบเสาหินมีองค์ประกอบที่พึ่งพาอาศัยกัน ดังนั้น หากคุณต้องการแก้ไขบางอย่างหรือเพิ่มคุณสมบัติใหม่ อาจเป็นไปได้ว่าทั้งระบบอาจเสียหาย
แม้จะเก่าไปแล้ว แต่ก็ยังมีอยู่บ้าง ใช่ เราทราบถึงการแสดงออกของคุณในปัจจุบัน
การแบ่งแนวคิดของ codebase ออกเป็นสององค์ประกอบที่แตกต่างกัน — ส่วนหน้า (ฝั่งไคลเอ็นต์) และส่วนหลัง (ฝั่งเซิร์ฟเวอร์) — เป็นสิ่งที่หลีกเลี่ยงไม่ได้เนื่องจากเทคโนโลยีใหม่ที่พัฒนาขึ้นและผลิตภัณฑ์ซอฟต์แวร์มีความซับซ้อนมากขึ้น
วิธีดำเนินการที่ได้รับความนิยมมากที่สุดในขณะนี้คือการแยกข้อกังวลระหว่างเลเยอร์การนำเสนอที่ผู้ใช้โต้ตอบด้วยกับทุกอย่างที่เกิดขึ้นในเบื้องหลัง
มันต้องการทีมวิศวกรรมซอฟต์แวร์สองทีม โดยทีมส่วนหน้าสร้างองค์ประกอบภาพ และทีมส่วนหลังสร้างบริการเว็บ ตรรกะทางธุรกิจ การเข้าถึงข้อมูล การผสานรวม ฯลฯ
อย่างไรก็ตาม แม้จะแยกจากกัน แต่กลยุทธ์นี้ยังคงเป็นเสาหินโดยธรรมชาติ
การเปลี่ยนแปลงหลักคือตอนนี้เรามีโค้ดขนาดใหญ่สองบล็อก—ส่วนหน้าและส่วนหลัง—แทนที่จะเป็นแอปพลิเคชั่นขนาดใหญ่เพียงตัวเดียว สถาปัตยกรรมเสาหินไม่จำเป็นต้องน่ากลัว มีประโยชน์บางประการ ได้แก่
- การพัฒนาที่ง่ายและรวดเร็วสำหรับแอปพลิเคชันขนาดเล็กด้วยซอร์สโค้ดเบสเดียวและการออกแบบที่ง่ายมาก
- การทดสอบและการดีบักนั้นตรงไปตรงมามาก เนื่องจากโค้ดทั้งหมดอยู่ในที่เดียว ทำให้ทีมติดตามโฟลว์ของคำขอและระบุจุดบกพร่องได้ง่ายขึ้น
- ในช่วงต้นของการพัฒนาแอปพลิเคชัน ค่าใช้จ่ายจะถูกกว่าเนื่องจากไม่มีต้นทุนด้านโครงสร้างพื้นฐานหรือต้นทุนในการพัฒนาใดๆ เกิดขึ้นจนกว่าจะมีการเพิ่มคุณสมบัติใหม่
ข้อเสียของกลยุทธ์นี้สะท้อนให้เห็นใน
- ความยืดหยุ่นในการปรับใช้ที่จำกัด – ทีมต้องรอหากมีเพียงไม่กี่คนที่ทำงานในโครงการและจำเป็นต้องมีการปรับใช้ใหม่ทุกครั้งที่คุณอัปเดตโค้ด
- การนำเทคโนโลยีใหม่มาใช้เป็นสิ่งที่ท้าทาย เนื่องจากจำเป็นต้องเขียนส่วนสำคัญใหม่ หากไม่ใช่ทั้งโครงการ
- เมื่อจำนวนนักพัฒนาเพิ่มขึ้น ระบบของโค้ดจะเชื่อมต่อกันอย่างใกล้ชิด ซับซ้อน และยากต่อการจัดการและทำความเข้าใจ
- ปัญหาองค์กร – สมาชิกในทีมแต่ละคนต้องใช้ไลบรารีเวอร์ชันเดียวกันและรายงานการเปลี่ยนแปลงใด ๆ หากหลายทีมกำลังทำงานในโครงการเสาหิน
- ความกังวลเกี่ยวกับความสามารถในการปรับขนาด – เนื่องจากองค์ประกอบของโครงการเชื่อมต่อถึงกัน การปรับขนาดแยกกันทำให้เกิดปัญหาที่ส่งผลให้มีการหยุดทำงานอย่างมีนัยสำคัญและมีค่าใช้จ่ายที่สูงขึ้น
- ตรรกะที่ซับซ้อนของโครงการอาจเป็นเรื่องยากสำหรับสมาชิกในทีมใหม่ที่จะเข้าใจ โดยเฉพาะอย่างยิ่งหากวิศวกรที่เดิมทำงานเกี่ยวกับโครงการนี้ไม่มีการจ้างงานอีกต่อไป
การพัฒนาไมโครเซอร์วิสและญาติสนิทของไมโครเซอร์วิส และไมโครฟรอนต์เอนด์ ได้กล่าวถึงปัญหาหลักของระบบเสาหิน
สถาปัตยกรรมไมโครเซอร์วิส
วิธีการทางสถาปัตยกรรมที่เรียกว่า microservices ช่วยให้สามารถสร้างส่วนประกอบหรือบริการขนาดเล็กที่เชื่อมโยงอย่างหลวม ๆ และปรับใช้ได้อย่างอิสระ ซึ่งประกอบเป็นแบ็กเอนด์ของแอปพลิเคชัน
ทุกบริการมี codebase ของตัวเอง ไปป์ไลน์ CI/CD โพรซีเดอร์ DevOps และกระบวนการสำหรับการรัน
คุณจะเห็นได้ว่าทีมแบ็กเอนด์แบบเสาหินแบ่งออกเป็นทีมต่างๆ โดยดูที่ภาพด้านบน
แต่ละรายการจะเน้นที่แง่มุมต่างๆ ของแอปพลิเคชันเป็นรายบุคคล (เช่น บริการผลิตภัณฑ์ บริการค้นหา และบริการชำระเงิน)
การสื่อสารระหว่างบริการต่างๆ เกิดขึ้นผ่านโปรโตคอลที่สร้างขึ้นซึ่งเรียกว่า API เช่น โปรโตคอล REST API แบบเบาที่ใช้รูปแบบการตอบกลับคำขอแบบซิงโครนัส
อีกทางเลือกหนึ่งคือใช้การสื่อสารแบบอะซิงโครนัสโดยใช้ซอฟต์แวร์เช่น Kafka ซึ่งมีโครงสร้างและเหตุการณ์การสื่อสารสำหรับการเผยแพร่/สมัครรับข้อมูล
ไมโครเซอร์วิสผสานรวมกับฟรอนต์เอนด์ผ่านแบ็กเอนด์สำหรับบริการฟรอนต์เอนด์ (BFF) หรือเกตเวย์ API ผ่านเครือข่าย BFF นำเสนอ API ที่กำหนดเองสำหรับไคลเอ็นต์แต่ละราย ในขณะที่ API Gateways ให้จุดเข้าถึงจุดเดียวสำหรับคอลเล็กชันไมโครเซอร์วิส
แต่ถึงแม้จะมีส่วนประกอบแบ็กเอนด์ที่เป็นอิสระและข้อดีทั้งหมดที่มี ส่วนฟรอนท์เอนด์ก็ยังคงเป็นเสาหิน
ดังนั้น นี่คือจุดที่ไมโครฟรอนท์เอนด์มีประโยชน์
สถาปัตยกรรมไมโครฟรอนท์เอนด์
คล้ายกับไมโครเซอร์วิส ซึ่งส่วนประกอบที่เชื่อมโยงแบบหลวมๆ ได้รับการจัดการโดยหลายทีม สถาปัตยกรรมไมโครฟรอนท์เอนด์ใช้แนวคิดนี้กับเบราว์เซอร์
ส่วนต่อประสานผู้ใช้เว็บแอปพลิเคชันเหล่านี้เป็นไปตามโครงสร้างนี้ ซึ่งประกอบด้วยส่วนประกอบที่ค่อนข้างอิสระ
ทีมยังถูกสร้างขึ้นตามความต้องการของลูกค้าหรือกรณีการใช้งานมากกว่าความเชี่ยวชาญหรือเทคโนโลยีเฉพาะ
ดังนั้น ทีมงานจึงมีส่วนร่วมในไมโครเซอร์วิสและโปรเจ็กต์ไมโครฟรอนท์เอนด์
- แบ่งส่วนตามแนวตั้ง — เนื่องจากมีนักพัฒนาส่วนหน้า ผู้เชี่ยวชาญด้านข้อมูล วิศวกรส่วนหลัง วิศวกร QA ฯลฯ ที่ทำงานในโครงการเดียวกันเช่นกัน พวกเขาจึงสร้างคุณลักษณะจาก ส่วนติดต่อผู้ใช้ ไปยังฐานข้อมูล และ
- ข้ามสายงาน – สมาชิกในทีมแต่ละคนจะมอบความเชี่ยวชาญให้กับกลุ่ม
ทีมยังสามารถเลือกกลุ่มเทคโนโลยีที่เหมาะสมกับสายธุรกิจเฉพาะของตนมากที่สุด
ทีมหนึ่งสามารถใช้ React เพื่อตั้งโปรแกรมส่วนย่อยได้ อีกทีมหนึ่งสร้างเวอร์ชันเชิงมุมใหม่ Vue.js เป็นตัวอย่างหนึ่ง
ไมโครฟรอนท์เอนด์ถูกใช้ร่วมกับไมโครเซอร์วิสที่เกี่ยวข้องเพื่อแก้ไขปัญหาที่ทีมพัฒนามักมีเกี่ยวกับเสาหิน กลยุทธ์นี้มีข้อดีดังต่อไปนี้
- เสรีภาพทางเทคโนโลยี: วิศวกรส่วนหน้าสามารถเลือกเฟรมเวิร์ก JavaScript ทางเลือก สภาพแวดล้อมรันไทม์ และสแต็คเทคโนโลยีทั้งหมดได้ขึ้นอยู่กับความต้องการของบริษัท นอกเหนือจากสถาปัตยกรรมที่ล้าสมัยแล้ว อาจมีการนำเฟรมเวิร์กใหม่มาใช้
- ระดับความยืดหยุ่นที่มากขึ้นเป็นไปได้ เนื่องจากไมโครฟรอนต์เอนด์แต่ละส่วนมีในตัวและสามารถพัฒนา ทดสอบ ปรับใช้ และอัปเกรดแยกกันได้ ด้วยเหตุนี้ หากทีมใดทีมหนึ่งกำลังทำงานเกี่ยวกับคุณลักษณะและได้แก้ไขจุดบกพร่อง และอีกทีมหนึ่งต้องเพิ่มคุณลักษณะของตนเอง พวกเขาก็ไม่จำเป็นต้องรอให้ทีมแรกทำงานให้เสร็จ
- ทีมและระบบที่เป็นอิสระ: ทีมผลิตภัณฑ์แต่ละทีมและด้วยเหตุนี้แต่ละคุณลักษณะจึงสามารถทำงานได้โดยไม่ต้องพึ่งพาผู้อื่น ซึ่งช่วยให้ทำงานต่อไปได้แม้ว่าส่วนประกอบใกล้เคียงจะไม่พร้อมใช้งาน
- ฐานโค้ดที่เล็กกว่าหลายอัน: ไมโครฟรอนท์เอนด์แต่ละส่วนจะมีฐานโค้ดที่เล็กกว่า จัดการได้ง่ายขึ้น ผู้คนจำนวนน้อยลงจะมุ่งเน้นไปที่องค์ประกอบ UI ที่เฉพาะเจาะจง ลดความซับซ้อนในการตรวจสอบโค้ด และปรับปรุงองค์กรโดยรวม
- การปรับขนาดแอปอย่างง่าย: ข้อดีอีกประการของไมโครฟรอนต์เอนด์คือความสามารถในการปรับขนาดแต่ละฟีเจอร์แยกกัน ตรงข้ามกับเสาหินขนาดใหญ่ที่ต้องปรับขนาดโปรแกรมทั้งหมดทุกครั้งที่มีการเพิ่มคุณสมบัติใหม่ สิ่งนี้ทำให้กระบวนการทั้งหมดมีประสิทธิภาพมากขึ้นทั้งในแง่ของเวลาและเงิน
ไมโครฟรอนท์เอนด์ทำงานอย่างไร
ตามที่เราได้กล่าวไว้ก่อนหน้านี้ ทีมต่างๆ ได้รับการจัดระเบียบในแนวตั้งภายในสถาปัตยกรรมไมโครฟรอนท์เอนด์ ซึ่งหมายความว่าพวกเขาถูกแยกจากกันโดยความรู้หรือวัตถุประสงค์ของโดเมน และมีความรับผิดชอบตั้งแต่ต้นจนจบสำหรับผลิตภัณฑ์เฉพาะ
มันสามารถมีไมโครเซอร์วิสหนึ่งหรือสองแบ็กเอนด์รวมถึงฟรอนต์เอนด์ขนาดเล็ก ในรายละเอียดเพิ่มเติม มาตรวจสอบลักษณะขององค์ประกอบภาพ การโต้ตอบกับส่วนประกอบ UI อื่นๆ และการรวมเข้ากับหน้าแรก
ไมโครฟรอนต์เอนด์สามารถ
- ทั้งหน้า (เช่น หน้ารายละเอียดสินค้า) หรือ
- ส่วนของเพจที่ทีมอื่นสามารถใช้ได้ เช่น ส่วนหัว ส่วนท้าย และแถบค้นหา
คุณสามารถแบ่งเว็บไซต์ขนาดใหญ่ออกเป็นหน้าต่างๆ ได้หลายแบบ และให้แต่ละประเภทให้เจ้าหน้าที่เฉพาะคนทำงาน
อย่างไรก็ตาม มักมีองค์ประกอบหลายอย่างเกิดขึ้นในหลาย ๆ หน้า เช่น ส่วนหัว ส่วนท้าย บล็อกคำแนะนำ ฯลฯ ตัวอย่างเช่น บล็อกคำแนะนำสามารถรวมไว้ในหน้าแรก หน้ารายละเอียดผลิตภัณฑ์ หรือแม้แต่หน้าชำระเงิน
โดยพื้นฐานแล้ว ทีมสามารถสร้างชิ้นส่วนที่ทีมอื่นสามารถใช้บนเพจของตนได้
อย่างไรก็ตาม ไมโครฟรอนต์เอนด์สามารถนำไปใช้งานแยกกันเป็นโปรเจ็กต์ต่างๆ ได้ ต่างจากส่วนประกอบที่นำกลับมาใช้ใหม่ได้
ทั้งหมดนี้ฟังดูยอดเยี่ยม แต่ในการสร้างอินเทอร์เฟซที่เป็นหนึ่งเดียว หน้าและส่วนย่อยต้องถูกรวมเข้าด้วยกัน
สิ่งนี้ต้องการการรวมส่วนหน้า ซึ่งสามารถทำได้โดยใช้กลยุทธ์ที่หลากหลาย รวมถึงการกำหนดเส้นทาง องค์ประกอบ และการสื่อสาร (ดูรูปภาพด้านบน)
การกำหนดเส้นทาง
เมื่อต้องใช้บริการจากเพจที่ควบคุมโดยทีมหนึ่งเพื่อเข้าถึงเพจที่ทีมอื่นเป็นเจ้าของ การกำหนดเส้นทางจะมีประโยชน์สำหรับการรวมระดับเพจ
ไมโครฟรอนต์เอนด์ทุกตัวได้รับการจัดการเป็นแอปพลิเคชันหน้าเดียว ลิงก์ HTML อย่างง่ายสามารถใช้เพื่อจัดเตรียมเส้นทาง
ผู้ใช้สามารถบังคับให้เบราว์เซอร์ดาวน์โหลดมาร์กอัปเป้าหมายจากเซิร์ฟเวอร์และแทนที่หน้าปัจจุบันด้วยหน้าใหม่โดยคลิกที่ไฮเปอร์ลิงก์
เปลือกแอปเป็น HTML, CSS และ JavaScript ขั้นต่ำที่ขับเคลื่อน UI แม้ว่าข้อมูลเนื้อหาที่ร้องขอจากเซิร์ฟเวอร์จะยังรออยู่ ผู้ใช้จะได้รับหน้าที่แสดงแบบคงที่ทันที เปลือกแอปส่วนกลางทำหน้าที่เป็นแอปพลิเคชันหลักสำหรับแอปหน้าเดียวที่สร้างโดยทีมต่างๆ
ไม่ว่าจะใช้ไลบรารีหรือเฟรมเวิร์ก meta-frameworks จะเปิดใช้งานการรวมหน้าต่างๆ ไว้ในหน้าเดียว
ส่วนประกอบ
องค์ประกอบคือกระบวนการจัดเรียงชิ้นส่วนให้พอดีกับช่องว่างที่เหมาะสมบนหน้า ในกรณีส่วนใหญ่ ทีมที่ปรับใช้เพจจะไม่ดึงเนื้อหาของแฟรกเมนต์ในทันที
แต่จะวางตัวยึดตำแหน่งหรือเครื่องหมายในตำแหน่งที่ชิ้นส่วนควรอยู่ในมาร์กอัป
การประกอบขั้นสุดท้ายทำได้สำเร็จโดยใช้กระบวนการเขียนแบบอื่น องค์ประกอบสามารถแบ่งออกเป็นสองประเภทพื้นฐาน: ฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์
องค์ประกอบฝั่งไคลเอ็นต์: เว็บเบราว์เซอร์ใช้ในการสร้างและแก้ไขมาร์กอัป HTML ไมโครฟรอนท์เอนด์แต่ละรายการมีความสามารถในการเปลี่ยนแปลงและแสดงมาร์กอัปแยกจากส่วนอื่นๆ ของหน้า
ตัวอย่างเช่น Web Components อนุญาตให้คุณดำเนินการก่อสร้างประเภทนี้
แผนคือการเปลี่ยนแต่ละส่วนย่อยเป็นส่วนประกอบเว็บที่สามารถติดตั้งได้อย่างอิสระเป็นไฟล์ a.js หลังจากนั้นแอปสามารถโหลดและแสดงผลในพื้นที่ที่กำหนดสำหรับพวกเขาในเค้าโครงธีม
ส่วนประกอบของเว็บขึ้นอยู่กับ HTML และ DOM API ซึ่งเฟรมเวิร์กส่วนหน้าอื่นๆ สามารถใช้ได้ เช่นเดียวกับวิธีการมาตรฐานในการส่งและรับข้อมูลผ่านอุปกรณ์ประกอบฉากและเหตุการณ์
องค์ประกอบฝั่งเซิร์ฟเวอร์: ด้วยการออกแบบนี้ ชิ้นส่วน UI จะถูกรวมไว้บนเซิร์ฟเวอร์ ส่งผลให้มีการส่งเพจที่มีรูปแบบสมบูรณ์ไปยังฝั่งไคลเอ็นต์ ซึ่งจะทำให้การโหลดเร็วขึ้น
การประกอบมักจะดำเนินการโดยบริการแยกต่างหากซึ่งอยู่ระหว่างเว็บเบราว์เซอร์และเว็บเซิร์ฟเวอร์ CDN เป็นหนึ่งในบริการ (เครือข่ายการจัดส่งเนื้อหา)
คุณสามารถเลือกหนึ่งหรือสองอย่างรวมกัน ขึ้นอยู่กับความต้องการของคุณ
รูปแบบการสื่อสารไมโครฟรอนท์เอนด์
สถาปัตยกรรมไมโครฟรอนท์เอนด์ทำงานได้ดีที่สุดเมื่อมีปฏิสัมพันธ์ระหว่างส่วนประกอบต่างๆ เพียงเล็กน้อยหรือแทบไม่มีเลย ไมโครฟรอนท์เอนด์บางครั้งจำเป็นต้องพูดคุยกันและแบ่งปันข้อมูล ต่อไปนี้คือรูปแบบที่เป็นไปได้บางประการที่อาจนำไปสู่สิ่งนั้น
- พนักงานเว็บ: ผู้ปฏิบัติงานออนไลน์เป็นกลไกที่ช่วยให้เนื้อหาเว็บสามารถเรียกใช้ JavaScript ในพื้นหลัง โดยไม่ขึ้นกับสคริปต์อื่น และไม่ส่งผลต่อความเร็วของหน้า จะมีการจัดเตรียม API ของผู้ปฏิบัติงานเฉพาะสำหรับแต่ละไมโครแอป ประโยชน์นี้คือการทำงานที่ใช้เวลานานสามารถทำได้ในเธรดอื่น ทำให้เธรด UI สามารถดำเนินการต่อโดยไม่ถูกทำให้ช้าลงหรือหยุดทำงาน
- ตัวปล่อยเหตุการณ์: ในกรณีนี้ ส่วนประกอบจำนวนมากจะสื่อสารระหว่างกันโดยรับฟังและดำเนินการตามการเปลี่ยนแปลงสถานะในส่วนประกอบที่สมัครรับข้อมูล ไมโครฟรอนท์เอนด์อื่นๆ ที่สมัครรับข้อมูลจากเหตุการณ์เฉพาะนั้นจะตอบสนองเมื่อไมโครฟรอนต์เอนด์เริ่มการทำงานของเหตุการณ์นั้น ตัวปล่อยเหตุการณ์ที่ได้รับการแนะนำในแต่ละไมโครฟรอนท์เอนด์ทำให้สิ่งนี้เป็นไปได้
- โทรกลับและอุปกรณ์ประกอบฉาก: ในส่วนนี้ คุณกำหนดองค์ประกอบหลักและองค์ประกอบย่อย การสื่อสารถูกจัดเป็นโครงสร้างคล้ายต้นไม้ องค์ประกอบหลักใช้อุปกรณ์ประกอบฉากเพื่อถ่ายทอดข้อมูลเป็นฟังก์ชันลงต้นไม้องค์ประกอบไปยังองค์ประกอบย่อย ในทางกลับกัน เด็กสามารถแจ้งเตือนผู้ปกครองได้อย่างมีประสิทธิภาพเมื่อมีสิ่งใดเกิดขึ้นในสถานะของพวกเขาโดยตอบสนองต่อการโทรกลับ React ใช้โหมดนี้
ข้อดีของไมโครฟรอนท์เอนด์
การพัฒนาในทีมอิสระอย่างรวดเร็ว
ทีมอิสระสามารถสร้างแต่ละส่วนของเว็บแอปหรือเว็บไซต์ได้เมื่อใช้วิธีการไมโครฟรอนท์เอนด์
แต่ละทีมมีอิสระอย่างสมบูรณ์ ซึ่งหมายความว่าจะรับผิดชอบวงจรการพัฒนาส่วนประกอบทั้งหมด ตั้งแต่แนวคิดจนถึงการเปิดตัวและหลังการผลิต
นอกจากนี้ยังบอกเป็นนัยว่าทีมต่างๆ สามารถทำงานร่วมกันได้อย่างราบรื่นในขณะที่ทำงานในโครงการเดียวกันพร้อมกัน
ดังนั้น รอบการปลดปล่อยจึงเร็วกว่าที่เป็นกับเสาหินส่วนหน้าอย่างมาก
Codebases ที่เล็กลงของ Micro Frontends ส่วนบุคคลนำไปสู่ Code ที่สะอาดขึ้น
ส่วนหน้าแบบเสาหินมีฐานรหัสขนาดใหญ่เทอะทะ ซึ่งกลายเป็นเรื่องวุ่นวายและท้าทายมากขึ้นในการจัดการเมื่อเวลาผ่านไป
ฟรอนต์เอนด์ไมโครแก้ไขปัญหานี้ ซอร์สโค้ดของไมโครฟรอนท์เอนด์แต่ละรายการสามารถจัดการได้มากกว่า เนื่องจากมีขนาดเล็กกว่า เรียบง่ายกว่า และกะทัดรัดกว่า
โซลูชันเว็บโดยรวมได้รับประโยชน์จากโค้ดที่สะอาดขึ้นเป็นผลที่ตามมา
ปรับปรุงความเสถียรของแอพเนื่องจาก Loose Coupling
โซลูชันเว็บแทบจะไม่สามารถแบ่งออกเป็นชิ้นส่วนที่แยกจากกันโดยสิ้นเชิง ดังนั้นไมโครฟรอนต์เอนด์จึงพูดคุยกัน
อย่างไรก็ตาม การเชื่อมโยงแต่ละส่วนระหว่างส่วนประกอบต่างๆ มีความสำคัญแม้ว่าจะมีการเชื่อมต่อที่หลวม
ความล้มเหลวขององค์ประกอบหนึ่งมีผลเพียงเล็กน้อยหรือไม่มีเลยต่อการทำงานของส่วนประกอบอื่นๆ ทั้งหมด ซึ่งช่วยเพิ่มความเสถียรของโซลูชันเว็บ
การทดสอบคุณลักษณะแต่ละรายการทำได้ง่ายขึ้น
ประโยชน์นี้เป็นผลมาจากลักษณะของไมโครฟรอนท์เอนด์ จากการออกแบบสถาปัตยกรรมนี้ ฝั่งไคลเอ็นต์ของโซลูชันเว็บเป็นแบบแยกส่วน และแต่ละโมดูลเป็นแบบอิสระ
ด้วยเหตุนี้ การประเมินส่วนต่อประสานผู้ใช้เพียงส่วนเล็กๆ ด้วยตัวมันเองจึงง่ายกว่าสำหรับทีมที่จะทำมากกว่าการทดสอบเสาหินขนาดใหญ่
ขนาดมัดที่ลดลงทำให้โหลดหน้าได้เร็วขึ้น
สาเหตุหลักประการหนึ่งของเวลาในการโหลดที่ล่าช้าในระบบเว็บแบบเสาหินที่มีคุณลักษณะมากมายคือขนาดของบันเดิล JavaScript ในอีกด้านหนึ่ง วิธีการแบบไมโครฟรอนท์เอนด์ทำให้ลดเวลาในการโหลดหน้าเว็บได้ง่ายขึ้น
เบราว์เซอร์ไม่จำเป็นต้องดาวน์โหลดโค้ดที่ไม่จำเป็นซ้ำๆ เนื่องจากหน้าเว็บประกอบด้วยกลุ่มเล็กๆ หลายชุด ส่งผลให้ประสิทธิภาพของหน้าและเวลาในการโหลดเพิ่มขึ้น
เทคโนโลยีอิสระ
แพลตฟอร์มที่หลากหลาย เฟรมเวิร์กส่วนหน้า นักพัฒนาสามารถใช้เพื่อสร้างโซลูชันออนไลน์เดียวด้วยสถาปัตยกรรมไมโครฟรอนท์เอนด์
เนื่องจากแต่ละองค์ประกอบเป็นแบบอิสระ จึงสามารถสร้างขึ้นโดยใช้เทคโนโลยีใดก็ได้ที่เหมาะกับงานของทีมมากที่สุด
โดยปกติ โปรแกรมเมอร์ควรใช้ความระมัดระวังในการเลือกเฟรมเวิร์กสำหรับโครงการซอฟต์แวร์ที่พวกเขารับผิดชอบ และยังคงแนะนำให้ปรึกษากับทีมอื่นๆ
อย่างไรก็ตาม มีโอกาสเป็นศูนย์ที่คุณจะถูกบังคับให้ใช้เฟรมเวิร์กแบบเดิมตลอดช่วงอายุของแอป
จุดด้อยของ Micro Frontend
การทดสอบโซลูชันเว็บที่ซับซ้อนอย่างครบถ้วน
การทดสอบโมดูลต่างๆ ของโซลูชันเว็บทำได้ง่ายเมื่อใช้สถาปัตยกรรมไมโครฟรอนท์เอนด์ มันแตกต่างจากการประเมินเว็บแอปพลิเคชันโดยรวมแม้ว่า
ตรวจสอบว่าชิ้นส่วนทั้งหมดทำงานได้ตามที่ตั้งใจไว้ก่อนที่จะดำเนินการต่อ ซึ่งอาจเป็นเรื่องยากเนื่องจากไมโครฟรอนท์เอนด์ทำงานอย่างอิสระและมีกระบวนการจัดส่งที่แยกจากกัน
การลงทุนเริ่มต้นที่มีราคาแพง
การพัฒนาส่วนหน้าแบบไมโครมักต้องการค่าใช้จ่ายทางการเงินจำนวนมาก การรวบรวมและดูแลทีม front-end จำนวนมากมีค่าใช้จ่ายสูง
นอกจากนี้ คุณจะต้องมีบุคลากรด้านการจัดการเพื่อจัดระเบียบงาน ตรวจสอบให้แน่ใจว่าทุกอย่างมีการประสานงาน และรับประกันการสื่อสารในทีมที่ยอดเยี่ยม
ความซับซ้อนของการพัฒนาและการปรับใช้
ขั้นตอนการพัฒนาและปรับใช้อาจมีความซับซ้อนมากขึ้นอันเป็นผลมาจากการออกแบบไมโครฟรอนท์เอนด์
โซลูชันอาจรกไปด้วยส่วนประกอบมากเกินไปโดยทีมพัฒนาอิสระที่ทำงานในโครงการเดียวกัน เป็นต้น ซึ่งอาจทำให้เกิดปัญหาในขั้นตอนการปรับใช้
การประกอบที่ถูกต้องของโมดูลทั้งหมดและการผสานรวมที่ราบรื่นเข้ากับโครงร่างโดยรวมนั้นไม่ได้ง่ายเสมอไป งานนี้มักจำเป็นต้องมีความเข้าใจอย่างถี่ถ้วนเกี่ยวกับการขึ้นต่อกันทั้งหมด
ปัญหาในการรักษาความสอดคล้องในประสบการณ์ของผู้ใช้
การรักษาอินเทอร์เฟซผู้ใช้ให้สอดคล้องกันนั้นเป็นสิ่งที่ท้าทายเมื่อทีมทำงานแยกกันในส่วนต่างๆ ของซอฟต์แวร์
นักพัฒนาโครงการทุกคนควรแบ่งปันโซลูชันเว็บ มิฉะนั้น อาจมีความขัดแย้งมากมายระหว่างทาง
สรุป
Micro frontends ซึ่งเป็นการออกแบบสถาปัตยกรรมร่วมสมัยสามารถเพิ่มประสิทธิภาพของโครงการพัฒนาเว็บบนไมโครเซอร์วิสขนาดใหญ่ได้อย่างมาก
ช่วยให้โปรแกรมเมอร์สามารถแบ่งโซลูชันทั้งหมดออกเป็นส่วนๆ ที่สามารถสร้างโดยทีมอิสระหลายทีมได้ ประโยชน์มากมายตามมาจากสิ่งนี้ รวมถึงการเปิดตัวฟีเจอร์ที่รวดเร็วขึ้น การทดสอบแต่ละโมดูลที่ง่ายขึ้น และการอัปเกรดที่ราบรื่นยิ่งขึ้น
แต่มีปัญหาบางอย่างกับไมโครฟรอนท์เอนด์เช่นกัน
ตัวอย่างเช่น การทดสอบที่ครอบคลุมของแอปพลิเคชันอาจเป็นสิ่งที่ท้าทาย
นอกจากนี้ เนื่องจากจำเป็นต้องมีทีมวิศวกรและผู้ดูแลระบบจำนวนมาก โครงการไมโครฟรอนท์เอนด์จึงมีราคาแพงมาก
ดังนั้น ก่อนตัดสินใจ คุณต้องคำนึงถึงองค์ประกอบทั้งหมดของกรณีธุรกิจของคุณด้วย
วลาดิมีร์ ชามาจ
ฉันไม่เข้าใจว่าหลักการสื่อสารระหว่างส่วนประกอบแต่ละส่วนในส่วนหน้าทำงานอย่างไร ฉันไม่เข้าใจว่าคุณต้องการเชื่อมต่อส่วนประกอบที่สร้างขึ้นในกรอบงานที่แตกต่างกันอย่างไร ไม่มีอะไรในบทความเกี่ยวกับเรื่องนี้ ระบบเหตุการณ์และผู้ฟังดูเหมือนนรกบนดินสำหรับฉัน เราควรจินตนาการอย่างไร?