תוכן העניינים[להתחבא][הופעה]
הרעיון של מיקרו חזיתות מיישם מיקרו-שירותים לפיתוח חזיתי.
הרעיון הוא לחלק את האפליקציה או האתר לחלקים קטנים יותר, שפותחו באופן עצמאי, שמתחברים לאחר מכן במהלך זמן הריצה, בניגוד ליצירתם כמונוליט יחיד ומלוכד.
השיטה מאפשרת ליצור רכיבים נוספים של האפליקציה באמצעות טכנולוגיות אחרות ועם צוותים עצמאיים.
הרעיון הוא להפחית את הוצאות התחזוקה הקשורות במונוליט טיפוסי על ידי פילוח פיתוח בצורה זו.
בכך שהוא מאפשר להם להתרכז באזור מסוים של אפליקציה כצוות קוהרנטי, זה גם מאפשר צורות חדשות של שיתוף פעולה בין מפתחי קצה וחזית קצה.
לדוגמה, ייתכן שיהיה לך צוות שאחראי הבלעדי ליכולת החיפוש או להיבט אחר של מוצר מפתח שהוא חיוני לעסק.
הודות לפדרציה של המודולים, יש לך מספיק פונקציונליות להתמודד עם זרימת העבודה חזית מיקרו מנדטים לגישה.
פוסט זה יבחן לעומק את הארכיטקטורה של פדרציית המודולים, כמו גם את התכונות העיקריות שלה ואת דפוסי היישום שלה.
אז מה זה פדרציית המודולים?
עיצוב הפדרציה של מודול Javascript עושה שימוש בחלקים בשימוש חוזר ביישומים רבים.
זה ז'רגון בסיסי למדי, אבל פשוט גרמתי לזה להיראות ככה כבריזה.
כפי שכולנו מכירים את שיתוף רכיבים בתוך אפליקציית React, Module Federation משיגה למעשה את אותה מטרה בפועל, למעט העובדה שהיא חושפת באופן דינמי מודולי יישומים לצריכה על ידי יישומים אחרים.
פדרציית המודולים מבקשת להתגבר על בעיית שיתוף המודולים במערכת מבוזרת על ידי אספקת רכיבי מפתח משותפים כמאקרו או מיקרו לפי הצורך.
זה מושג על ידי הסרתם מהאפליקציות שלך ומזרימת העבודה של הבנייה.
למה פדרציית מודולים?
להלן כמה גורמים שאיתם פדרציית המודולים יכולה להתמודד בקלות:
- רכיבים חיצוניים ו-DLL (ספריות קישור דינמיות) היו כל מה שהיה לנו מדי פעם לשיתוף פונקציונליות בין אפליקציות. כל אלה הפכו את שיתוף הקוד בקנה מידה למאתגר ביותר.
- NPM איטית.
- כאשר שתי תוכנות נפרדות חולקות קוד חיוני, הן חייבות להיות דינמיות וגמישות.
על מנת שאפליקציות עצמאיות יהיו לגמרי במאגר משלהן, יפרסו בנפרד ויפעלו כ-SPA עצמאי משלהן, נוצרה Module Federation.
רכיבי הליבה של פדרציה של מודול
לפני שצולל לעומק, חשוב לדון בקצרה בכמה מושגים חדשים שהפדרציה של המודולים מביאה.
- מארח: כאשר דף נטען, ה-build או המודול שאותחל בתחילה נקרא מארח. ספק יכול להיחשב כמארח.
- מרחוק: שלט הוא מבנה שונה שמשתמש בחלק מהמארח. הם מכונים גם לקוחות.
- מארח דו-כיווני: מבנה Webpack שמתפקד גם כשלט שמארחים אחרים צורכים וגם כמארח שצורך שלטים.
- פדרציית ספקים: מאפשרת שיתוף בזמן ריצה משותף באופן הצהרתי של תלות של מודול npm עבור מארח או מרחוק, ללא קשר למיקום שממנו הם נטענים. אחת מבעיות הביצועים העיקריות עם חזיתות מיקרו נפתרת בדרך זו.
דפוסי יישום פדרציה
מערכת עיצוב אוורגרין
אחת הצורות הבסיסיות ביותר של יישומים מאוחדים היא "רחוק ירוק עד", שהוא שלט משותף כמו "מערכת עיצוב" או "ספריית רכיבים" המופץ ומתעדכן באופן עצמאי עבור כל המשתמשים.
מבלי שכל צוות אפליקציות יצטרך להשקיע זמן בתיקונים, זה עשוי להיות מועיל כדי להבטיח שכל האתרים המקוונים דבקים בזהות הארגונית העדכנית ביותר.
על מנת לתכנן ולהציב את המגבלות והנהלים הדרושים להבטחת עדכונים שוטפים מאובטחים, זה עשוי להיות מקום שימושי לעסקים להתחיל כאשר שוקלים ארכיטקטורת יישומים מאוחדת.
להלן כמה מקרי שימוש שבהם שלטים משותפים בפריסה עצמאית עשויים להתאים:
- עיצוב מערכות
- קליפות יישום
- ספריות רכיבים
- צרכנים
- ערכות כלים משותפות
- מודלים חלופיים להפצה עבור ווידג'טים בשימוש פנימי או חיצוני
שיתוף מודול ריבוי SPA
השתמש מחדש בתכונות שכבר יצאו, כגון רכיבים, ביישומים עצמאיים שונים של עמוד בודד. ההטבות כוללות:
- צרכנים מקבלים עדכונים אוטומטיים
- המומחיות בתחום נשארת בצוות שאחראי עליה.
- מייעל את הליך הפריסה מכיוון שאין צורך במהדורות נפרדות של מודול.
פדרציה מונעת על ידי פגז
הפדרציה מונעת הפגז כוללת:
- בעת יצירת גרסת מוצר חדשה, צוות המוצר אינו ממתין עד שצוות Checkout ישלים את עבודתו.
- בעת החלפת שלטים, אין טעינת עמוד מחדש.
- בעת הצורך, Shell מציעה טעינה איטית מרחוק וניתוב (ברמה עליונה).
- ניתוב בין שלטים מתאפשר באמצעות פדרציית ספקים, המאפשרת שימוש חוזר בחבילות npm בשימוש תכוף.
- Shell מציעה את המסגרת ותלות נפוצה אחרות שבהן נעשה שימוש חוזר בשלטים הטעונים בעצלתיים.
פדרציה מרובת פגזים
דומה לפדרציה מונעת קונכיות שתוארה לעיל, אך השתמשה בקונכיות שונות.
זה מכיל:
- מספר פגזים
- תיוג לבן
- לא כל השלטים נדרשים על ידי Shell B או שיש להם יישומים עצמאיים.
תכונות הליבה של הפדרציה של מודול
ביצועי אינטרנט מעולים
הבעיה עם הרכב מודול NPM הרגיל היא שככל שמספר התלויים עולה, גודל האפליקציה בדרך כלל גדל.
על מנת להימנע מטעינת חבילות כאשר האפליקציה שלך נטענת ולטעון אותן רק בעת הצורך, Module Federation מציעה לך את היכולת לטעון חבילות בעצלתיים.
זה מונע את הצורך להוריד מודולים לפני שהם נדרשים בפועל, מה שמשפר את מהירות האתר.
פיתוח יעיל
כל פרויקט יכול להיות מיוצר ומועבר במנותק וניתן לבצע אותו על ידי צוותים שונים מכיוון ש-Module Federation מעודד אותך לארגן את היישום שלך בפרויקטים דיסקרטיים כך שתוכל לבנות ולפרוס אותם בנפרד (ומכאן במקביל).
יכולת ריפוי עצמי ויתירות
תלות משותפת מאפשרת ל-Module Federation לעקוב אחר כל התלות של התוכנית שלך במקום אחד.
כך, גם כאשר אפליקציה אינה מצהירה על תלות או כאשר יש בעיות ברשת, היא עדיין יודעת מה היא צריכה ויכולה לטפל בהורדה לפי הצורך.
טיפול יעיל בתלות נפוצה
בנוסף, Module Federation מציע ניהול תלות מעולה, פתרון יעיל של דרישות ספקים וצד שלישי, כך שהאפליקציה שלך לעולם לא תטען יותר מגרסה אחת של ספרייה.
במקום צורך לפרוס מחדש את הצרכנים, פרוס קוד עצמאי.
המפתח מעוניין מאוד בפונקציונליות ירוקת עד. ברגע שהפונקציונליות התלויה החשופה השתנתה, לא יהיה צורך להתקין מחדש את הצרכנים יותר.
אני חייב להודות שזו תכונה חזקה מאוד בפני עצמה, כזו שתצטרך בדיקה קפדנית כדי למנוע תוצאות בלתי צפויות.
בעת הפעלה, ייבא קוד מ-builds אחרים.
בעת אימוץ מודל החבילה של NPM, אנו עשויים לשקול אפליקציות המשתמשות ב-Module Federation בדומה לממשקי API במקום לשתף קוד ולחשוב על "ספרייה".
באותו אופן שהם יכולים לקבל פונקציונליות גם מיישומים אחרים, יישומי אינטרנט יכולים כעת לספק את הפונקציונליות ליישומים אחרים.
חווית מפתח משופרת תוך שמירה על חווית הלקוח
כל מפתח JavaScript יהיה די נוח עם Module Federation מכיוון שזהו תוסף Webpack שנגיש החל מגרסה 5 של Webpack.
זה למעשה די חזק ומסקרן אם נקדיש לזה מחשבה.
על ידי שימוש במעמיסי Webpack של צד שלישי, שקול את כל הרכיבים ש Webpack חבילות, כולל סקריפטים, נכסים, סגנונות, תמונות, סימון סימון ועוד.
על ידי שימוש ב-Module Federation, ניתן לשתף ולאחד את כל אלה.
מיקרו-חזיתות פועלות בצורה מונוליטית.
זה די קל להוסיף פונקציונליות משותפת ליישום שלך; פשוט ייבא את החבילה כרגיל או השתמש בטעינה סינכרונית.
לחלופין, ניתן להשתמש בטעינה אסינכרונית לטעינת תלות רק בעת הצורך על ידי שימוש בטעינה עצלה.
סיכום
בפוסט זה, דנו ב-Module Federation כבחירה פנטסטית לפיתוח יישום המיקרו-חזית שלך.
מתן אפשרות לאפליקציות להחליף ולצרוך פונקציונליות בזמן ריצה מעודדת מדרגיות בכך שהיא מאפשרת לצוותים שונים לעבוד על יישומים עצמאיים.
כאשר הפונקציונליות הנפוצה משתנה, לא תצטרך לעצב ולפרוס את הצרכנים שלך מכיוון שהיא תומכת בפונקציונליות ירוקת עד.
התוכנית שלך תפעל כמו מונוליט לאחר הגדרתה, וזה פנטסטי.
תלויות שניתנות לשיתוף משמשות להקטנת גודל האפליקציות. מכיוון שמפתחים רבים כבר מכירים את סביבת Webpack, חווית המפתחים מצוינת.
השאירו תגובה