รหัสซ้ำซ้อนส่งไปป์ที่มีส่วนหน้าแบบไมโคร


12

ความเข้าใจของฉันเกี่ยวกับ Micro-frontends คือปัญหาสำคัญที่พวกเขาแก้ปัญหาคือการช่วยให้องค์กรมีทีมที่แตกต่างกันหลายทีมที่เป็นไปได้ทำงานกับแต่ละองค์ประกอบ / แอพขนาดเล็กที่จะใช้ในการเขียนเว็บแอปพลิเคชันขนาดใหญ่

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

เป็นความจริงหรือไม่ว่าหากเรามีแอปขนาดเล็กหลายตัวที่ใช้ในการเขียนแอปพลิเคชันเว็บขนาดใหญ่เราอาจมีแอพขนาดเล็กหลายตัวที่ส่งไลบรารี่ Javascript เดียวกัน ( เช่น Lodash ) ลงไปยังเบราว์เซอร์ของผู้ใช้ปลายทาง การรวมกลุ่มของผู้จัดจำหน่ายแต่ละรายซึ่งนำไปสู่รหัสซ้ำซ้อน / ซ้ำซ้อนจำนวนหนึ่งที่ถูกส่งไปยังผู้ใช้

นี่ไม่ใช่ความกังวลที่เราควรกังวลในขณะที่ออกแบบแอปพลิเคชันส่วนหน้าใช่ไหม


2
ฉันคิดว่ามันเป็นอย่างกังวลคุณต้องบัญชี น่าเสียดายที่ฉันไม่ทราบว่าคนจะไปเกี่ยวกับเรื่องนี้ได้อย่างไร คำถามที่ดี!
RubberDuck

คำตอบ:


12

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

เช่นฉันคิดว่า Spotify ใช้วิธีการนี้เพื่อแยก UI ของพวกเขาเป็นส่วนประกอบแยก ( แหล่งที่มา ) แต่ละวิดเจ็ตอาศัยอยู่ใน iframe และสามารถมีชุดไลบรารีเป็นของตัวเอง ฯลฯ พวกเขามีข้อ จำกัด ขององค์กรที่ไม่เหมือนใครที่ทำงานโดยทีมอิสระ (ทีมข้ามสายงาน) สิ่งนี้ทำให้ยากที่จะเห็นด้วยกับมาตรฐานทั่วทั้ง บริษัท และเปลี่ยนมาตรฐานเหล่านี้ในภายหลัง ดังนั้นสำหรับพวกเขาส่วนหน้าขนาดเล็กช่วยรักษาความยืดหยุ่นบางอย่าง แต่หากไม่มีวิธีนี้อาจเป็นแอปเดสก์ท็อปของพวกเขาอาจจะมีหน่วยความจำน้อยกว่า

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

โดยส่วนตัวแล้วฉันคิดว่าส่วนหน้าขนาดเล็กนั้นอาจเป็นสถาปัตยกรรมที่ถูกต้อง แต่ก็ไม่อาจมองข้ามได้เว้นแต่

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

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

Micro-frontends ดูเหมือนจะเป็นหนึ่งในสิ่งเหล่านี้ที่เจ๋งจริงๆ แต่คุณไม่จำเป็นต้องใช้จนกว่าคุณจะทำงานในระดับหนึ่ง


3
ฉันคิดว่าการปักหลักในเฟรมเวิร์กเวอร์ชันเดียวตลอดทั้งแอปพลิเคชันของคุณน่าจะคุ้มค่ากับความพยายาม
Robert Harvey
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.