תוכן העניינים[להתחבא][הופעה]
הרעיון של מיקרו-שירותים זכה לתשומת לב רבה לאחרונה, וחברות רבות משתמשות בו כדי לבטל את הקצה האחורי הגדול ומונוליטי.
ללכת באותו מסלול עם ה-frontend הוא עדיין אתגר עבור עסקים רבים, גם אם הדרך המבוזרת הזו של בניית צד השרת של אפליקציות אינטרנט היא פחות או יותר מהימנה מבחינת מחקר וביצוע.
בשל התלות ההדוקה שלו, המונוליט בצד הלקוח מקשה בדרך כלל על שילוב תכונות חדשות, אימוץ טכנולוגיות חדשות וקנה מידה של רכיבים בודדים.
אתגרים אלו ואחרים הניעו מפתחי קצה לחקור שימוש בשירותי מיקרו.
כתוצאה מכך, פותחה אסטרטגיה ארכיטקטונית חדשה לגמרי המכונה מיקרו חזית ליצירת השכבה הקדמית של אתרי אינטרנט ויישומים מבוססי אינטרנט.
המונח שימש לראשונה בשנת 2016, ומאז הוא זכה לתשומת לב רבה למען מטרה טובה.
מאמר זה ייתן הבנה כללית של מה הם מיקרו-חזיתות והבעיות בהן הם מטפלים. זה עובד, כמו גם יתרונות וחסרונות.
מבוא לארכיטקטורת חזית מיקרו
שיטה עכשווית לפיתוח חזיתי הנקראת ארכיטקטורת מיקרו חזית מחלקת את א יישום אינטרנט לחלקים קטנים ועצמאיים.
למשתמש הקצה, חלקים אלה נראים כיחידה אחת גם אם הם נבנו באופן עצמאי ואז חברו יחד.
עם ההבדל שחזיתות מיקרו נוגעות לצד הלקוח, לא לצד השרת, של פתרונות מקוונים, הרציונל שבבסיסם זהה לזה של שירותי מיקרו.
יצירת מוצרים מבוססי אינטרנט מתוחכמים היא ההגיונית ביותר בעת שימוש בגישת מיקרו חזיתית.
חזיתות מיקרו, בניגוד למונוליט קדמי קונבנציונלי יותר, מאפשרים לצוותים רבים לשתף פעולה בנפרד בפרויקטי תוכנה שונים.
מתכנתים יכולים ליצור אפליקציות אינטרנט במהירות רבה יותר ועם יכולת מדרגיות ותחזוקה רבה יותר באמצעות עיצוב ארכיטקטוני זה.
במילים פשוטות, כל חזית מיקרו היא רק פיסת קוד עבור רכיב נפרד של דף האינטרנט.
תכונות אלו נשלטות על ידי צוותים נפרדים, שכל אחד מהם מתמחה בתעשייה או מטרה מסוימת.
ארכיטקטורת חזית מונוליתית לעומת מיקרו-שירותים מול מיקרו
תחשוב על מעבר דירה. האם יהיה לך פשוט יותר לארגן הכל למספר קופסאות קטנות עם תווית מומחית ולהעביר כל אחת מהן בנפרד או לארוז את כל הצוות בקופסה אחת ענקית ולהעביר אותה למקום חדש?
הפתרון הברור נמצא שם.
אנלוגיה זו משווה את שתי ארכיטקטורות אפליקציות האינטרנט הנבדלות, מונוליטים ומיקרו-שירותים (הידועים גם כ-Micro frontends).
אדריכלות מונוליטית
אולי תוכל להיזכר ב"ימים הטובים" כאשר אפליקציה שלמה נוצרה כישות אחת ומגובשת. שיטה כזו נקראת מונוליט, שהוא כינוי ישן לבלוק אבן גדול.
זה הגיוני.
למערכות מונוליטיות יש אלמנטים התלויים זה בזה. לכן, אם ברצונך לשנות משהו או להוסיף תכונה חדשה, ייתכן שהמערכת כולה עלולה להישבר.
למרות שהוא מיושן, הוא עדיין קיים מדי פעם. כן, אנו מודעים לביטוי הנוכחי שלך.
החלוקה הרעיונית של בסיס הקוד לשני רכיבים שונים - חזית (צד לקוח) וקצה עורפי (צד שרת) - הפכה לבלתי נמנעת ככל שטכנולוגיות חדשות פותחו ומוצרי תוכנה הסתבכו יותר.
שיטת הפעולה הפופולרית ביותר היא כיום הפרדת חששות בין שכבת המצגת שמשתמש קצה מתקשר איתה לבין כל מה שמתרחש ברקע.
הוא זקוק לשני צוותי הנדסת תוכנה, כאשר צוות החזית בונה את הרכיבים החזותיים וצוות הקצה האחורי בונה את שירותי האינטרנט, ההיגיון העסקי, הגישה לנתונים, האינטגרציות וכו'.
עם זאת, למרות הפרדה זו, אסטרטגיה זו עדיין נותרה מונוליטית מטבעה.
השינוי העיקרי הוא שכעת יש לנו שני בלוקים גדולים של קוד - החזית והקצה האחורי - במקום יישום עצום אחד. ארכיטקטורות מונוליטיות לא חייבות להיות נוראיות; יש להם כמה יתרונות, כולל
- פיתוח פשוט ומהיר ליישומים זעירים עם בסיס קוד מקור יחיד ועיצוב פשוט מאוד;
- בדיקה וניפוי באגים פשוטים מאוד מכיוון שכל הקוד נמצא במיקום אחד, מה שמקל על צוות לעקוב אחר זרימת הבקשה ולזהות באגים;
- בשלב מוקדם בפיתוח של אפליקציה, ההוצאות זולות יותר מכיוון שלא עלויות תשתית או עלויות פיתוח נוצרות עד להוספת תכונות חדשות.
החסרונות של אסטרטגיה זו באים לידי ביטוי
- גמישות הפריסה מוגבלת - צוותים חייבים להמתין אם יש רק קומץ מהם שעובד על הפרויקט ונדרשת פריסה חדשה בכל פעם שאתה מעדכן את הקוד;
- אימוץ טכנולוגיות חדשות הוא מאתגר שכן פעולה זו מחייבת שכתוב חלק ניכר, אם לא את כל הפרויקט.
- כאשר מספר המפתחים גדל, מערכת קוד הופכת להיות מחוברת, מסובכת וקשה לניהול והבנה.
- בעיות ארגוניות - כל חבר צוות חייב להשתמש באותה גרסה של ספריות ולדווח על כל שינוי אם צוותים רבים עובדים על פרויקט מונוליטי.
- דאגות לגבי מדרגיות – מכיוון שמרכיבי הפרויקט קשורים זה בזה, התרחבותם בנפרד מציבה קשיים שגורמים להשבתה משמעותית ולהוצאות גבוהות יותר.
- הלוגיקה המורכבת של הפרויקט עשויה להיות קשה לחברי צוות חדשים להבין, במיוחד אם המהנדסים שעבדו עליו במקור אינם מועסקים יותר.
הפיתוח של מיקרו-שירותים וקרוביהם הקרובים, ומיקרו-חזיתות, טיפלו בבעיות העיקריות במערכות מונוליטיות.
ארכיטקטורת שירותי מיקרו
השיטה הארכיטקטונית המכונה microservices מאפשרת יצירת רכיבים קטנים יותר, או שירותים, רבים המקושרים באופן רופף וניתנים לפריסה עצמאית, המרכיבים קצה אחורי של יישומים.
לכל שירות יש בסיס קוד משלו, צינורות CI/CD, נהלי DevOps ותהליכים להפעלתם.
אתה יכול לראות שצוות הקצה המונוליטי מחולק לצוותים נפרדים על ידי התבוננות בתמונה למעלה.
כל אחד מהם מתמקד בנפרד בהיבט אחר של האפליקציה (כגון שירות המוצר, שירות החיפוש ושירות התשלומים).
התקשורת בין השירותים מתרחשת באמצעות פרוטוקולים מבוססים המכונים APIs, כגון פרוטוקול REST API קל משקל המשתמש בדפוסי תשובה סינכרוניים לבקשות.
אפשרות נוספת היא להשתמש בתקשורת אסינכרונית באמצעות תוכנה כמו קפקא, המציעה מבני תקשורת ואירועים לפרסום/הרשמה.
שירותי מיקרו משתלבים עם ה-frontend באמצעות קצה אחורי עבור שירות ה-frontend (BFF) או שער API דרך הרשת. BFF מציע API מותאם אישית לכל לקוח, בעוד ששערי API מעניקים נקודת גישה אחת לאוסף של שירותי מיקרו.
אבל אפילו עם רכיבי קצה אוטונומיים וכל היתרונות שהם מספקים, הקצה הקדמי הוא עדיין מונוליט.
לכן, זה המקום שבו חזיתות מיקרו שימושיות.
ארכיטקטורת חזיתות מיקרו
בדומה לשירותי מיקרו, שבהם רכיבים מקושרים רופפים מנוהלים על ידי מספר צוותים, ארכיטקטורת ה-Micro Frontend מיישמת את הרעיון על הדפדפן.
ממשקי המשתמש של אפליקציות אינטרנט אלה עוקבים אחר המבנה הזה, המורכב ממרכיבים אוטונומיים במידה מסוימת.
צוותים נוצרים גם לפי צרכי הלקוח או מקרי שימוש במקום מומחיות או טכנולוגיה מסוימת.
כתוצאה מכך, צוותים מעורבים במיקרו-שירותים ובפרויקטים של מיקרו-חזית.
- פרוס אנכית - מכיוון שיש מפתחי קצה, מומחי נתונים, מהנדסי קצה, מהנדסי QA וכו' שעובדים גם על אותו פרויקט, הם יוצרים את התכונות שלהם מה- ממשק משתמש למאגרי מידע; ו
- תכליתי - כל חבר צוות תורם את המומחיות שלו לקבוצה.
צוותים יכולים גם לבחור את ערימת הטכנולוגיה המתאימה ביותר לתחום העסקים הספציפי שלהם.
צוות אחד יכול להשתמש ב-React כדי לתכנת את הפרגמנט שלו. צוות אחר יוצר גרסה חדשה של Angular. Vue.js היא דוגמה כזו.
משתמשים בממשקי מיקרו בשילוב עם שירותי מיקרו קשורים כדי לטפל בבעיות שיש לצוותי פיתוח בדרך כלל עם מונוליטים. האסטרטגיה מציעה את היתרונות הבאים.
- חופש טכנולוגי: מהנדסי Frontend יכולים לבחור מסגרות JavaScript חלופיות, סביבות זמן ריצה וערימות טכנולוגיה שלמות בהתאם לצרכי החברה. נוסף על הארכיטקטורה המיושנת, עשויה להחיל מסגרת חדשה.
- רמה גבוהה יותר של גמישות אפשרית מכיוון שכל חזית מיקרו מוגברת וניתנת לפיתוח, בדיקה, פריסה ושדרוג בנפרד. כתוצאה מכך, אם צוות אחד עובד על תכונה ודחף תיקון באג, וצוות אחר צריך להוסיף תכונה משלו, הם לא צריכים לחכות שהצוות הראשון ישלים את המשימה שלו.
- צוותים ומערכות אוטונומיות: כל צוות מוצר, וכתוצאה מכך כל פיצ'ר, יכול לתפקד עם מעט תלות באחרים, מה שמאפשר לו להמשיך לעבוד גם כאשר הרכיבים הסמוכים אינם זמינים.
- מסדי קוד מרובים וקטנים יותר: לכל אחד מממשקי המיקרו יהיה בסיס קוד משלו, ניתן לניהול וקטן יותר. פחות אנשים יתמקדו ברכיב ממשק משתמש ספציפי, יפשטו את ביקורות הקוד וישפרו את הארגון הכללי.
- קנה מידה פשוט של אפליקציה: יתרון נוסף של מיקרו-חזיתות הוא היכולת לשנות את קנה המידה של כל תכונה בנפרד. בניגוד למונוליטים, שבהם יש להתאים את התוכנית כולה בכל פעם שמתווסף תכונה חדשה, זה הופך את התהליך כולו ליעיל יותר מבחינת זמן וכסף.
איך עובד ה-Micro Frontend?
כפי שציינו בעבר, צוותים מאורגנים אנכית בתוך ארכיטקטורת ה-Micro Frontend, מה שאומר שהם מופרדים על ידי ידע או מטרה בתחום ואחראים מההתחלה ועד הסוף למוצר ספציפי.
זה יכול לכלול מיקרו-שירותים אחורי אחד או שניים כמו גם חזית קצה קטנה. בפירוט רב יותר, הבה נבחן את המאפיינים של אלמנט חזותי זה, אינטראקציות עם רכיבי ממשק משתמש אחרים והשילוב בדף הבית.
חזית מיקרו יכולה להיות
- עמוד שלם (למשל, דף פרטי מוצר) או
- חלקים של הדף שיכולים לשמש צוותים אחרים, כגון כותרות עליונות, כותרות תחתונות וסרגלי חיפוש.
אתה יכול לחלק אתר גדול לכמה סוגי דפים ולתת כל סוג לצוות ספציפי לעבוד עליו.
עם זאת, מספר מרכיבים מופיעים לעתים קרובות בדפים רבים, כגון כותרות עליונות, כותרות תחתונות, בלוקים של הצעות וכו'. בלוק הצעות, למשל, יכול להיכלל בדף הבית, בדף פרטי המוצר או אפילו בדף התשלום.
למעשה, צוותים יכולים ליצור חלקים שצוותים אחרים יכולים להשתמש בהם בדפים שלהם.
עם זאת, ניתן לפרוס את חזיתות המיקרו בנפרד כפרויקטים שונים בניגוד לרכיבים הניתנים לשימוש חוזר.
כל זה נשמע פנטסטי, אבל כדי ליצור ממשק מאוחד, יש לשלב איכשהו דפים ושברים.
זה מצריך שילוב חזיתי, שניתן להשיג באמצעות מגוון אסטרטגיות, כולל ניתוב, קומפוזיציה ותקשורת (ראה את הגרפיקה למעלה).
ניתוב
כאשר נדרש שירות מדף שנשלט על ידי צוות אחד כדי לגשת לדף שבבעלות צוות אחר, ניתוב שימושי לאינטגרציה ברמת העמוד.
כל חזית מיקרו מטופלת כאפליקציה של עמוד אחד. ניתן להשתמש בקישורי HTML פשוטים כדי לספק ניתוב.
משתמש יכול לאלץ את הדפדפן להוריד את סימון היעד משרת ולהחליף את הדף הנוכחי בחדש על ידי לחיצה על היפר-קישורים.
מעטפת האפליקציה היא המינימום ההכרחי של HTML, CSS ו-JavaScript המניע את ממשק המשתמש. גם אם נתוני התוכן המבוקש מהשרת עדיין ממתינים, המשתמש מקבל דף סטטי המוצג מיד. מעטפת האפליקציה המרכזית משמשת כאפליקציית אב לאפליקציות בעמוד בודד שנוצרו על ידי הצוותים השונים.
לא משנה הספרייה או המסגרת שבה נעשה שימוש, מטא-frameworks מאפשרות מיזוג של עמודים שונים לאחד.
רכב
קומפוזיציה היא תהליך של סידור החלקים כך שיתאימו לרווחים המתאימים בדף. ברוב המקרים, הצוות שפורס את הדף לא מביא מיד את תוכן הפרגמנט.
במקום זאת, הוא מציב מציין מיקום או סמן היכן שהקטע צריך להיות בסימון.
באמצעות תהליך חיבור שונה, ההרכבה הסופית מתבצעת. ניתן לחלק את ההרכב לשתי קטגוריות בסיסיות: צד הלקוח וצד השרת.
הרכב צד הלקוח: דפדפן האינטרנט משמש ליצירה ועריכה של סימון HTML. לכל חזית מיקרו יש את היכולת לשנות ולהציג את הסימון שלו בנפרד משאר העמוד.
Web Components, למשל, מאפשרים לך לבצע סוג זה של בנייה.
התכנון הוא להפוך כל פרגמנט לרכיב אינטרנט שניתן להתקין באופן עצמאי כקובץ a.js, ולאחר מכן האפליקציות יכולות לטעון ולעבד אותן בחללים המיועדים להן בפריסת הנושא.
רכיבי האינטרנט תלויים ב-HTML ו-DOM API, אשר מסגרות קצה אחרות יכולות להשתמש בהן, כמו גם בשיטה סטנדרטית של שליחת וקבלת נתונים באמצעות אביזרים ואירועים.
הרכב בצד השרת: עם עיצוב זה, חלקי ממשק המשתמש משולבים בשרת, מה שמביא לכך שדף מעוצב לחלוטין נשלח לצד הלקוח, ומאיץ את הטעינה.
ההרכבה מתבצעת לרוב על ידי שירות נפרד שנמצא בין דפדפן האינטרנט לשרתי האינטרנט. CDN הוא מופע אחד של השירות (רשת מסירת תוכן).
אתה יכול לבחור אחד או שילוב של השניים, בהתאם לצרכים שלך.
דפוסי תקשורת בחזית מיקרו
ארכיטקטורת המיקרו-חזית עובדת בצורה הטובה ביותר כאשר אין אינטראקציה בין הרכיבים השונים. חזיתות מיקרו צריכים מדי פעם לדבר אחד עם השני ולשתף מידע. הנה כמה דפוסים פוטנציאליים שעשויים להוביל לכך.
- עובדי אינטרנט: עובד מקוון הוא מנגנון המאפשר לתוכן אינטרנט להריץ JavaScript ברקע, ללא תלות בסקריפטים אחרים, ומבלי להשפיע על מהירות הדף. יסופק ממשק API ייחודי לעבודה עבור כל אפליקציה מיקרו. היתרון הזה הוא שאפשר לעשות עבודה שגוזלת זמן בשרשור אחר, מה שמאפשר לשרשור ממשק המשתמש להמשיך בלי להאט או לעצור.
- פולט אירועים: במקרה זה, רכיבים רבים מתקשרים זה עם זה על ידי האזנה ופעולה לכל שינויי מצב ברכיבים שאליהם הם מנויים. מיקרו חזיתות אחרים שנרשמו לאותו אירוע ספציפי מגיבים כאשר מיקרו חזית מפעילה את האירוע הזה. פולט אירועים שהוכנס לכל מיקרו-חזית הופך את זה לאפשרי.
- התקשרויות ואביזרים: בסעיף זה, אתה מגדיר רכיב אב ורכיבי צאצא. התקשורת מאורגנת למבנה דמוי עץ. רכיבי אב משתמשים באביזרים כדי להעביר את הנתונים כפונקציות לאורך עץ הרכיבים לרכיבי הצאצא. בתורו, הילד יכול להזהיר את ההורה ביעילות כאשר משהו מתרחש במצבו על ידי תגובה לשיחות חוזרות. React משתמש במצב זה.
יתרונות של חזית מיקרו
פיתוח בצוותים אוטונומיים במהירות
צוות עצמאי יכול ליצור כל חלק באפליקציית אינטרנט או אתר בעת שימוש בשיטת מיקרו חזיתית.
כל צוות הוא אוטונומי לחלוטין, מה שאומר שהוא אחראי על כל מחזור הפיתוח של הרכיבים, מהרעיון ועד לשחרור ופוסט-פרודקשן.
בנוסף, זה מרמז שצוותים שונים יכולים לשתף פעולה בצורה חלקה ובו זמנית לעבוד על אותו פרויקט.
לכן, מחזורי השחרור מהירים משמעותית ממה שהם יהיו עם מונוליטים קדמיים.
בסיסי קוד קטנים יותר של ממשקי מיקרו בודדים מובילים לקוד נקי יותר
לחזיתות מונוליטיות יש בסיסי קוד גדולים ומסורבלים שהופכים להיות יותר ויותר כאוטיים ומאתגרים לניהול עם הזמן.
חזיתות מיקרו מטפלות בבעיה זו. קוד המקור של כל חזית מיקרו ניתנת לניהול מכיוון שהוא קטן יותר, פשוט יותר וקומפקטי יותר.
פתרון האינטרנט הכולל נהנה מקוד נקי יותר כתוצאה מכך.
יציבות אפליקציה משופרת בגלל צימוד רופף
לעתים נדירות ניתן לחלק פתרון אינטרנט לחלקים עצמאיים לחלוטין. כתוצאה מכך, ממשקי חזית מיקרו אכן מדברים אחד עם השני.
עם זאת, כל קישור בין הרכיבים הוא משמעותי למרות הקישוריות הרופפת.
לכשל של רכיב אחד אין השפעה מועטה עד לא על פעולת כל הרכיבים האחרים, מה שמספק את היציבות המשופרת של פתרון אינטרנט.
בדיקת תכונות בודדות הופכת לפשוטה יותר
תועלת זו נובעת מהמאפיינים של חזיתות מיקרו. בהתבסס על עיצוב אדריכלי זה, צד הלקוח של פתרון אינטרנט הוא מודולרי וכל מודול הוא אוטונומי.
כתוצאה מכך, הערכה של חלק קטן ממשק המשתמש בפני עצמו קלה יותר לצוות מאשר בדיקת מונוליט ענק.
גודל חבילה מופחת מוביל לטעינת עמודים מהירה יותר
אחד הגורמים העיקריים לעיכוב זמני טעינה במערכות אינטרנט מונוליטיות עשירות בתכונות הוא הגודל של חבילת JavaScript. מצד שני, גישת מיקרו-חזית מקלה על צמצום זמן טעינת העמודים.
דפדפן לא חייב להוריד קוד מיותר שוב ושוב מכיוון שדף אינטרנט מורכב מכמה חבילות זעירות. כתוצאה מכך, ביצועי הדף וזמני הטעינה מוגברים.
עצמאות טכנולוגית
מְרוּבֶּה מסגרות חזיתיות יכול לשמש מפתחים ליצירת פתרון מקוון יחיד עם ארכיטקטורת מיקרו-חזית.
מכיוון שכל רכיב הוא אוטונומי, ניתן לבנות אותו באמצעות הטכנולוגיה המתאימה ביותר למשימות הצוות.
מטבע הדברים, מתכנתים צריכים לנקוט משנה זהירות בבחירת מסגרות לפרויקט התוכנה שעליו הם מופקדים, ועדיין מומלץ בחום להתייעץ עם צוותים אחרים.
עם זאת, קיים סיכוי אפסי שתיאלץ להשתמש במסגרת מדור קודם למשך כל אורך החיים של האפליקציה.
חסרונות של Micro Frontend
בדיקת פתרונות אינטרנט מורכבים בשלמותה
קל לבדוק את המודולים השונים של פתרון אינטרנט כאשר הוא משתמש בארכיטקטורת מיקרו-חזית. עם זאת, זה שונה מהערכת יישום אינטרנט כמכלול.
ודא שכל החלקים פועלים כמתוכנן לפני שתמשיך. זה עשוי להיות קשה מכיוון ש-Micro frontends פועלים באופן עצמאי ויש להם תהליכי משלוח נפרדים.
השקעות ראשוניות יקרות
פיתוחי מיקרו-חזית דורשים בדרך כלל הוצאות כספיות משמעותיות. זה יקר להרכיב ולשמור על צוותים קדמיים רבים.
בנוסף, תזדקק לאנשי ניהול כדי לארגן את העבודה, לוודא שהכל מתואם ולהבטיח תקשורת מצוינת בצוות.
המורכבות של פיתוח ופריסה
הליכי הפיתוח והפריסה יכולים להיות מסובכים יותר כתוצאה מתכנון מיקרו-חזיתי.
פתרון עלול להיות עמוס ביותר מדי רכיבים על ידי צוותי פיתוח עצמאיים העובדים על אותו פרויקט, למשל, מה שעלול לגרום לבעיות בשלב הפריסה.
גם ההרכבה הנכונה של כל המודולים והשילוב החלק שלהם בסכימה הכוללת אינה תמיד פשוטה; עבודה זו מחייבת בדרך כלל הבנה מעמיקה של כל התלות.
בעיות בשמירה על קוהרנטיות בחוויית המשתמש
שמירה על ממשק משתמש עקבי היא מאתגרת כאשר צוותים עובדים בנפרד על מספר חלקים של התוכנה.
פתרון האינטרנט צריך להיות משותף לכל מפתחי הפרויקט. אחרת, יכולות להיות הרבה סתירות לאורך הדרך.
סיכום
Micro frontends, עיצוב ארכיטקטוני עכשווי, יכול לשפר מאוד את הביצועים של פרויקטי פיתוח אינטרנט מבוססי מיקרו-שירותים בקנה מידה גדול.
זה מאפשר למתכנתים לחלק את הפתרון השלם לחלקים נפרדים שניתן ליצור על ידי מספר צוותים אוטונומיים. יתרונות רבים נובעים מכך, כולל השקת תכונות מהירה יותר, בדיקה קלה יותר של מודולים בודדים ושדרוגים חלקים יותר.
אבל יש כמה קשיים גם עם חזיתות מיקרו.
בדיקה מקיפה של אפליקציה, למשל, עשויה להיות מאתגרת.
בנוסף, מכיוון שדרוש צוות גדול של מהנדסים ומנהלים, פרויקטים של מיקרו-חזית הם יקרים מאוד.
כתוצאה מכך, לפני קבלת החלטה, עליך לקחת בחשבון את כל מרכיבי המקרה העסקי שלך.
ולדימיר צ'מאג'
איכשהו לא הבנתי על איזה עיקרון פועלת התקשורת בין רכיבים בודדים בחזית. אני לא מבין איך אתה רוצה לחבר רכיבים שנוצרים במסגרות שונות. אין על זה שום דבר בכתבה. מערכת האירועים והמאזינים נראית לי כמו גיהינום עלי אדמות. איך עלינו לדמיין את זה?