מה זה Micro-Frontends¶
מיקרוסרביסים (Microservices) הם רעיון מוכר בצד שרת - במקום שרת ענק אחד, מפצלים למספר שירותים עצמאיים קטנים. Micro-Frontends לוקח את אותו רעיון בדיוק ומיישם אותו בצד הלקוח: במקום אפליקציית פרונטאנד ענקית אחת, מפצלים אותה לכמה חלקים עצמאיים שכל אחד מפותח, נבנה, ואפילו נפרס (deploy) בנפרד.
מתי בכלל מגיעים לשם¶
תארו לעצמכם אתר גדול עם כמה צוותים - צוות אחד אחראי על עמוד המוצר, צוות שני על עגלת הקניות, צוות שלישי על אזור החשבון האישי. אם כל האתר הזה הוא פרויקט פרונטאנד אחד ענק, כל שינוי קטן דורש תיאום בין הצוותים, כל דיפלוי משפיע על כולם, וקוד ישן מצוות אחד יכול לתקוע את כל השאר. Micro-Frontends פותרים בעיה ארגונית הרבה יותר מאשר בעיה טכנית.
איך זה עובד בפועל¶
יש כמה גישות למימוש, אבל הרעיון המרכזי דומה: כל צד לקוח (frontend) עצמאי נבנה ונפרס בנפרד, ואז הם "מתחברים" יחד בדפדפן של המשתמש או בשרת. הטכניקה הפופולרית ביותר היום נקראת Module Federation, שמאפשרת לאפליקציית ריאקט אחת לטעון קוד של אפליקציה אחרת בזמן ריצה, כאילו הוא חלק ממנה, בלי לבנות הכל יחד מראש.
גישות נוספות כוללות שילוב ברמת iframe, או "עטיפת" כל micro-frontend כרכיב עצמאי בדף מארח (shell application) שאחראי רק על ניתוב וחיבור בין החלקים.
היתרונות האמיתיים¶
- עצמאות צוותים. כל צוות בוחר את הקצב שלו, ואפילו לפעמים ערימת טכנולוגיה (stack) שונה במקצת, בלי לחכות לצוותים אחרים.
- דיפלוי עצמאי. צוות יכול לשחרר עדכון לחלק שלו בלי לתאם עם כל שאר האתר ובלי לסכן חלקים אחרים.
- קוד ישן מבודד. אם חלק אחד באתר עדיין רץ על גרסה ישנה של הטכנולוגיה, זה לא מונע מחלקים אחרים להתקדם.
החסרונות שכדאי לקחת בחשבון¶
- מורכבות תשתית. צריך לבנות ולתחזק מנגנון שמחבר בין כל החלקים, וזה עבודה בפני עצמה.
- כפילות קוד. אם כל micro-frontend טוען את הספריות שלו בנפרד, המשתמש עלול להוריד את אותה ספרייה כמה פעמים.
- חוסר עקביות. בלי משמעת ברורה, קל שכל חלק באתר ייראה ויתנהג קצת אחרת, מה שפוגע בחוויית המשתמש.
- ניפוי שגיאות (debugging) מסובך יותר. באג שחוצה כמה חלקים עצמאיים קשה יותר לאתר מבאג בקוד בסיס אחד.
מתי זה פשוט מיותר¶
Micro-Frontends נועדו לפתור בעיה של ארגונים גדולים עם הרבה צוותים שעובדים על אותו מוצר במקביל. בפרויקט קטן, סטארטאפ בתחילת דרכו, או אתר שנבנה על ידי צוות אחד או שניים, הארכיטקטורה הזו כמעט תמיד תוסיף מורכבות בלי לפתור בעיה אמיתית שיש לכם. שם, פרויקט פרונטאנד רגיל ומאורגן היטב עדיף בהרבה.
איך יודעים אם הגיע הזמן לשקול את זה¶
סימן טוב לכך שהארכיטקטורה הזו עשויה להתאים הוא כשכמה צוותים נפרדים כבר עובדים על אותה אפליקציית פרונטאנד ומתחילים לחסום זה את זה בקביעות - דיפלוי אחד ממתין לדיפלוי אחר, ושינוי קטן בקוד משותף גורר בדיקות רגרסיה בכל האתר. אם זה לא קורה אצלכם, כנראה שמוקדם מדי לחשוב על הפיצול הזה.
מאיפה מתחילים ללמוד¶
לפני שמתעסקים בארכיטקטורות מתקדמות כמו Micro-Frontends, חשוב בסיס חזק בבניית אפליקציית פרונטאנד רגילה אחת. אם אתם בתחילת הדרך, יש לנו קורס צד לקוח בחינם שמלמד את היסודות האלה צעד אחר צעד.
לסיכום¶
Micro-Frontends הם פתרון ארגוני למקרה ספציפי - כמה צוותים גדולים שצריכים לעבוד באופן עצמאי על אותו מוצר. זו לא שדרוג טכני שכל פרויקט צריך, וההחלטה להשתמש בזה צריכה לבוא מבעיה אמיתית, לא מרצון להשתמש בטכנולוגיה מרשימה.
יש לכם ניסיון עם ארכיטקטורה כזו או שאלה עליה? ספרו בקהילה.