פיתוח ארכיטקטורת מיקרו-פרונטאנד לאפליקציית ווב

מיקרופרונטנדים: מדוע המונוליט מעכב שחרורים

כאשר הפרונטנד חי בבסיס קוד אחד, כל צוות נאלץ להמתין לאחרים. זמן הבנייה של אפליקציית ווב מונוליטית גדל יחד עם מספר המודולים: מה שנבנה בדקות מתחיל לארוך עשרות דקות, וזמן זה מוכפל במספר העריכות ביום. מפתח מתקן כפתור אחד — כל הפרויקט נבנה מחדש, כולל חלקים שהוא לא נגע בהם.

לאחר מכן נכנס הקונפליקט בין התלויות. שני צוותים רוצים גרסאות מאג'וריות שונות של אותה ספרייה, אך package.json משותף סובל רק אחת.

מישהו מקבע גרסה "כמו של השכן", מישהו עוקף את הבעיה על ידי העתקת קוד — וכעבור כמה חודשים בפרויקט יש שלוש מימושים של אותו רכיב, כל אחד עם העריכות שלו. עדכון תלות משותפת הופך לפרויקט נפרד עם בדיקה ידנית של כל המסכים.

ההשפעה היקרה ביותר — שחרורים מקושרים. כל עוד הפיצ'ר של צוות אחד לא מוכן, ענף השחרור ממתין, והשינויים המוכנים של צוותים אחרים לא מגיעים לפרודקשן.

מודול אחד שבור מפיל את כל האפליקציה כולה: באנדל משותף — נקודת כשל משותפת, ואי אפשר להחזיר אחורה רק את החלק הבעייתי, יש להחזיר את השחרור כולו.

מיקרופרונטנדים מנתקים את הקשר הזה: כל צוות בונה, בודק ומשחרר את החלק שלו באופן עצמאי, עם התלויות שלו והקצב שלו. מעטפת האפליקציה מרכיבה את החלקים בזמן ריצה, ולכן נפילה של מדור אחד לא גוררת את האחרים, והשחרור מפסיק להיות אירוע משותף לכל החברה. להלן נבחן כיצד זה בנוי ומה נדרש כדי שהמעבר לא יהפוך לצורה חדשה של תלות הדדית.

מה נותנת ארכיטקטורת מיקרופרונטנד

שחרורים עצמאיים במקום צינור משותף

כאשר כל האפליקציה נבנית כמקשה אחת, כל שינוי — תיקון טקסט בדף הנחיתה או פילטר חדש בקטלוג — גורר אחריו בנייה מחדש מלאה ורגרסיה של כל המוצר. מחזור השחרור נמתח לימים, והתור של הצוותים מצטבר.

מיקרופרונטנד מפרקים את המוצר למודולים אוטונומיים עם מאגר קוד, בנייה וצינור משל עצמם: הצוות מוציא לאוויר את החלק שלו בלי להמתין לאחרים. בפועל, המחזור "שינוי → פרודקשן" מתקצר מימים לשעות, ומספר השחרורים בשבוע גדל פי כמה.

בידוד כשלים

כשל של מודול אחד לא מפיל את כל האפליקציה: גבולות המודולים מתוכננים כך שהשגיאה תישאר בפנים ולא תגרור את המודולים השכנים. בלוק תקול של השלמת הזמנה לא גורר איתו את הקטלוג ואת האזור האישי — המשתמש ממשיך לעבוד, והצוות מתקן נקודתית.

זה מעביר תקלות מסוג "כל המוצר מושבת" לסוג "דגרדציה של פונקציה אחת", וזמן ההתאוששות יורד משעות לדקות.

מהירות בנייה ואוטונומיה של צוותים

בנייה של מודול בודד אורכת דקות במקום עשרות דקות במונוליט — המהנדס מקבל משוב מהר יותר ופחות שוהה בהמתנה. הצוותים בוחרים בעצמם את הכלים בתוך המודול שלהם, ומתאמים ביניהם רק את החוזים בנקודות החיבור.

זה מסיר חסימות בין התחומים: הפרונטנד, הקטלוג והתשלומים מתקדמים במקביל, ולא ממתינים זה לזה בחלון שחרור משותף.

מה זה נותן לעסק

האפקט המצטבר — קצב אספקה צפוי ומחיר נמוך יותר של השבתה. המוצר מתפתח בחלקים, בלי "הקפאה" של כל השחרור בגלל שיפור אחד, והתקלות ממוקמות עד לפונקציה ספציפית. מפרקים כיצד ארכיטקטורה כזו מתוכננת ואילו חוזים בין המודולים צריך לקבע כבר בהתחלה.

גישות להרכבה: השוואת אפשרויות

ישנן שלוש דרכים עקרוניות ושונות לחבר חלקים של אפליקציה שנבנו בנפרד, והבחירה ביניהן קובעת עד כמה מהר הצוותים יוכלו לשחרר שינויים בלי לפגוע בשכנים. להלן השוואה לפי מתי האפשרות מתאימה ואיפה היא מתחילה להפריע.

בפועל אפשרות טהורה נדירה: לעתים קרובות משלבים — ניתוב עבור מדורים ברמה העליונה, הרכבה בזמן ריצה עבור בלוקים משותפים בתוך העמוד. אנו מקבעים חוזים בין החלקים ומגרסאים אותם, כדי שעדכון של צוות אחד לא ישבור את הצוות השכן.

שלבי הטמעת מיקרופרונטנדים

הטמעת מיקרופרונטנדים מתחילה לא מהקוד, אלא ממלאי של מה שכבר עובד בפרודקשן. המהנדסים שלנו מנתחים את המונוליט הנוכחי או את מערך האפליקציות המחוברות: היכן עוברים גבולות הדומיינים, אילו מודולים משתנים לעתים קרובות יותר מאחרים, והיכן הצוותים חוסמים זה את זה בשחרורים.

לאחר audit הארכיטקטורה אנו מתעדים מפת תלויות ומחליטים אילו חלקים מוציאים ראשונים — בדרך כלל אלו אזורים עם תדירות שינויים גבוהה ומספר מינימלי של מצבים משותפים.

1. Audit ארכיטקטורה. אוספים מפה של מודולים, קשרים ונקודות נתונים משותפים, מעריכים את תדירות השחרורים לפי צוותים. בפלט — רשימת מועמדים להפרדה וסדר העבודה.
2. סכמת אינטגרציה. קובעים כיצד מעטפת האפליקציה טוענת מודולים מרוחקים, כיצד מועברים תלויות ומצב משותפים, והיכן עוברת הניתוב. מתעדים חוזים בין הצוותים בכתב, כדי שמודולים לא ימשכו את הפנימיות של זה.
3. הגדרת סביבה. פורסים builds ו-deploy עצמאיים לכל מודול, מגדירים registry משותף של ארטיפקטים ו-versioning. הצוות מקבל אפשרות לשחרר את החלק שלו בלי לבנות מחדש את כל האפליקציה.
4. הפרדה פיילוטית. מעבירים מודול אחד בשלמותו, בודקים שהוא עובד במעטפת כמו האחרים, ומודדים את זמן הבנייה לפני ואחרי.
5. בדיקת בידוד. בודקים עמידות בתקלות: נפילה של מודול אחד לא צריכה להפיל את האפליקציה, ותלויות משותפות לא צריכות להתנגש בגרסאות. מריצים תרחישי rollback לגרסה קודמת של המודול.
6. מסירת תיעוד. מוסרים לצוות הלקוח את סכמת האינטגרציה, תקנון השחרורים של המודולים, הוראות להרצה מקומית וצ'ק-ליסט להוספת מיקרופרונטנד חדש.

לאחר הפיילוט מרחיבים את הגישה לשאר המודולים באיטרציות — כל צוות עוקב מצטרף כבר לסכמה עובדת, ולא לניסוי. סדר כזה מפחית סיכון: אם בשלב בדיקת הבידוד עולים קונפליקטים, אנו רואים אותם על מודול אחד, ולא על כל האפליקציה.

ארטיפקטים: קונפיגורציות, סכמות, נהלים

אנחנו מעבירים את הפרויקט לא "גישה לריפוזיטורי", אלא כמערכת מלאה שלפיה צוות הלקוח יוכל לפתח מיקרופרונטאנדים בלעדינו. להלן מה שמתועד במסמכים ובקונפיגורציה עד לרגע המסירה.

• קונפיגורציות בנייה ורנטיים. מניפסטים של כל מיקרופרונטאנד, כללים להפרדת תלויות משותפות, הגדרות ניתוב וטעינת מודולים מרוחקים. בנפרד — קונפיגורציה של סביבות: מקומית, בדיקות ופרודקשן, עם תיאור משתני הסביבה.
• סכמות אינטגרציה. מפת האינטראקציה בין המעטפות למודולים: מי מרכיב את מי, דרך אילו חוזים, כיצד מועברים אירועים ומצב משותף. דיאגרמת התלויות מראה אילו מודולים ניתן לבנות ולהעלות באופן עצמאי.
• מדיניות גישה. מטריצת תפקידים ברמת הריפוזיטוריז, הענפים, הסביבות ולוחות הניטור. כללי ריוויו ובדיקות חובה לפני מיזוג — כדי שהאיכות לא תהיה תלויה באדם אחד.
• נהלי שחרור. סדר הבנייה, הוורסיונינג והחזרה לאחור של מודולים, תנאי תאימות בין גרסאות המעטפת למיקרופרונטאנד. בנוסף הוראות מה לעשות בעת אי-התאמה בחוזים.
• תיעוד. תיאור הארכיטקטורה וגבולות המודולים, מוסכמות קוד ושמות, קטלוג ספריות משותפות. פרק נפרד — כיצד להוסיף מיקרופרונטאנד חדש במעבר אחד.
• חומרי תפעול. ניטור מוגדר של בנייה וטעינת מודולים, סכמת לוגינג, צ'ק-ליסט לאבחון תקלות אינטגרציה אופייניות.

המערכת מיועדת לכך שמהנדס חדש נכנס לפרויקט דרך התיעוד, ולא דרך התכתבות. אם במהלך התמיכה משתנים חוזים או גבולות מודולים — נעדכן את הסכמות והנהלים יחד עם הקוד, אחרת הם מאבדים מערכם.

קייס: האצת שחרורים פי 4

הגיעה אלינו צוות עם מונוליט קלאסי: חנות מקוונת עם אזור אישי, קטלוג וביצוע הזמנה באפליקציה אחת. כל שינוי — מתיקון בסל ועד באנר חדש בדף הבית — גרר אחריו בנייה מלאה ושחרור משותף. הבנייה ארכה כ-40 דקות, השחרורים יצאו אחת לשבועיים, ונפילה של כל מודול הפילה את כל האתר כולו.

פירקנו את האפליקציה למיקרופרונטנדים בלתי תלויים לפי דומיינים עסקיים: קטלוג, סל וביצוע הזמנה, אזור אישי, דפי תוכן. כל דומיין קיבל בנייה משלו ומסלול פריסה משלו, ואת הקשר ביניהם בנינו דרך שכבת ניתוב משותפת וחוזים בגבולות המודולים. הצוותים הפסיקו לחכות זה לזה: תיקונים בקטלוג כבר לא נחסמו על ידי עבודות על האזור האישי.

מיקרופרונטנדים הניבו אפקט מדיד כבר בחודשים הראשונים. הבנייה של דומיין בודד הצטמצמה ל-6-8 דקות במקום 40, השחרורים עברו לכמה פעמים בשבוע במקום פעם אחת בשבועיים — האצה בתדירות ההוצאה פי 4 בערך.

בנפרד סגרנו סוג כשל שפעם פגע בכל האתר: תקלה במודול ביצוע ההזמנה כעת מבודדת ואינה משפיעה על הקטלוג והאזור האישי.

מדדים לפני ואחרי

מה תוקן בעמידות בפני תקלות

בעבר שגיאה במודול אחד הובילה לנפילה של כל האפליקציה ולחזרה אחורה של השחרור המשותף — זה עצר את העבודה של כל הצוותים בבת אחת. לאחר הפיצול, התקלה מתוחמת לגבולות הדומיין, שאר החלקים ממשיכים לעבוד, והחזרה אחורה נוגעת רק למודול הבעייתי. זה הפחית את מספר הזמני ההשבתה והסיר את המצב שבו צוות אחד מחכה לתיקון מצוות אחר.

במה נבדלים מיקרופרונטנדים ממונוליט?

מונוליט הוא אפליקציה אחת שנבנית, נבדקת ומועלית כיחידה שלמה. כל שינוי בעגלת ההזמנה גורר אחריו בנייה מחדש של כל המוצר, מכיוון שהקוד קשור בתלויות משותפות ובגרף בנייה אחיד. מיקרופרונטנדים מפצלים את הממשק לחלקים בלתי תלויים לפי משמעות עסקית: קטלוג, עגלה, אזור אישי, ביצוע הזמנה.

כל חלק הוא אפליקציה נפרדת עם מאגר קוד משלו, בנייה משלו ומחזור שחרור משלו, ובעמוד הם מתאחדים לממשק אחד.

ההבדל המרכזי הוא בשחרורים. בארכיטקטורה מונוליטית הצוותים מתאמים חלון העלאה אחיד וממתינים זה לזה: משימה אחת שלא הושלמה חוסמת את השחרור של כל המוצר. בגישה של מיקרופרונטנדים צוות הקטלוג מעלה את החלק שלו כשהוא מוכן, בלי לשאול את האחרים.

תדירות השחרורים עולה, וגודל השינוי יורד — ניתן להחזיר חלק אחד למצבו הקודם תוך דקות, בלי לגעת בשאר המוצר.

ההבדל השני הוא בידוד כשלים. במונוליט שגיאה במודול אחד מפילה את כל העמוד: המשתמש מאבד גם את הקטלוג, גם את העגלה וגם את ביצוע ההזמנה. במיקרופרונטנדים החלקים מבודדים — אם צומת התשלום אינו מגיב, שאר הממשק ממשיך לעבוד, והאזור התקול מדרדר באופן מקומי. זה משנה את סוג התקריות: במקום "האתר למטה" מקבלים "בלוק אחד אינו זמין".

השלישי — גבולות הצוותים והבעלות. מונוליט הופך עם הזמן לקוד משותף, שבו אף אחד אינו אחראי על קטע מסוים בשלמותו. מיקרופרונטנדים מקבעים לכל צוות את החלק שלו: סטאק משלו, מחזור משלו, אחריות משלו לאיכות.

המחיר — תקורה על המעטפת המשותפת, על הסגנון האחיד ועל האימות הרוחבי: יש לתכנן אותם מראש, אחרת החלקים יתחילו לסטות ויזואלית ובהתנהגות.

הבחירה אינה בינארית. מוצר קטן עם צוות אחד מהיר וזול יותר לנהל כמונוליט, ופיצול מוצדק כאשר על הממשק עובדים כמה צוותים והשחרורים מפריעים זה לזה. אנחנו מנתחים את המקרה שלכם ואומרים ישירות היכן מיקרופרונטנדים מניבים יתרון, והיכן יוסיפו מורכבות בלי תועלת.

ספקות טכניים נפוצים

מיקרו-פרונטאנדים הם לא "תוספת אופנתית", אלא החלטה ארכיטקטונית עם פשרות קונקרטיות. להלן ניתוח של הספקות שעולים לרוב בשלב התכנון, מנקודת מבט הנדסית.

איך לא לקבל כפילות תלויות וקונפליקטים בין גרסאות?

באמצעות חוזה מפורש: גרסה אחידה של ספריות משותפות מוצהרת ברמת הפלטפורמה, ולא נבחרת על ידי כל צוות בנפרד. אנחנו בודקים זאת אוטומטית בבנייה — אם אפליקציה הביאה עותק משלה של תלות משותפת, הבנייה נכשלת. זה מסיר את הבעיה הקלאסית שבה בעמוד מופיעות שתי גרסאות של אותה ספרייה וההתנהגות הופכת לבלתי צפויה.

עד כמה מסובך יותר דיבאג ואיתור שגיאות?

מסובך יותר מאשר במונוליט, אבל בשליטה. אנחנו מגדירים tracing מקצה לקצה: בקשה שעברה דרך מספר אפליקציות נראית כשרשרת אחת עם קישור למודול ספציפי. שגיאות נאספות במקום אחד עם ציון המקור. זה הופך את הדיבאג מ"מי מהצוותים שבר" למשימה ממוקדת עם בעלים ברור.

האם ארכיטקטורה כזו לא יוצרת פרצות באבטחה?

גבולות האפליקציות הם גם גבולות האמון. אנחנו מבודדים מודולים כך שלא תהיה להם גישה ישירה לנתונים ולמצב של אחרים, והחלפה מתבצעת דרך ממשק מבוקר. אימות ובדיקת הרשאות מועברים לרמה משותפת, ולא משוכפלים בכל אפליקציה — זה מפחית את הסיכון שצוות אחד ישכח בדיקה.

אם הספקות נותרו — נדון במשימה שלכם ונחזור עם הערכה ותוכנית.

בואו נדון במשימה שלכם

כדי לחזור עם הערכה ותוכנית להטמעת מיקרו-פרונטאנדים, אנחנו צריכים להבין את ההקשר שלכם: כמה צוותים ומחזורי שחרור, אילו פריימוורקים כבר בפרודקשן, ואיך בנויים תהליכי הבנייה והפריסה היום. תארו את המשימה בצורה חופשית — זה מספיק כדי לדון באופן ענייני בארכיטקטורה ובגבולות השינויים.

בשלב הבא ננתח את המצב הנוכחי של האפליקציה ונציע תוכנית לחלוקה למודולים אוטונומיים: היכן למתוח את הגבולות, איך לארגן מעטפת משותפת, ניתוב ותלויות משותפות, כך שהצוותים לא יחסמו זה את זה. בנפרד נדון באסטרטגיית המעבר — הוצאה הדרגתית של חלקים ללא עצירת המוצר, ולא כתיבה מחדש מאפס.

מה תקבלו בסוף:

• מפת פירוק: אילו דומיינים הופכים למודולים נפרדים ומדוע דווקא כך;
• תרשים אינטגרציה — מעטפת משותפת, בידוד סגנונות, ניהול גרסאות של חוזים בין צוותים;
• תוכנית הגירה בשלבים עם נקודות rollback בכל שלב;
• קונפיגורציית בנייה ופריסה עצמאית לכל מודול;
• מדיניות תלויות משותפות, כדי לא ליצור כפילויות וקונפליקטים בין גרסאות;
• מערך בדיקות: בדיקות חוזה, ניטור טעינה ושגיאות בנקודות החיבור;
• תיעוד לעבודה של הצוותים במודל החדש ותקנון שחרורים.

ההערכה מבוססת על היקף אמיתי: מספר המודולים, בגרות הקוד הנוכחי ודרישות התאימות. אנחנו לא מבטיחים עבודה ללא התחייבות — קודם מנתחים את המשימה, ואז חוזרים עם לוחות זמנים, הרכב השלבים ותחומי אחריות. תארו מה צריך לעשות — ואנחנו נחזור עם הערכה ותוכנית.