JavaScript Module Federation: פתיחת כוח השיתוף בזמן ריצה לאפליקציות גלובליות

בנוף הדיגיטלי המתפתח במהירות של ימינו, בניית אפליקציות ווב סקיילביליות, ניתנות לתחזוקה ושיתופיות היא בעלת חשיבות עליונה. ככל שצוותי הפיתוח גדלים והאפליקציות הופכות מורכבות יותר, הצורך בשיתוף קוד יעיל ובהפרדת רכיבים (decoupling) הופך קריטי יותר ויותר. JavaScript Module Federation, תכונה פורצת דרך שהוצגה עם Webpack 5, מציעה פתרון רב-עוצמה על ידי כך שהיא מאפשרת שיתוף קוד בזמן ריצה בין אפליקציות שנפרסו באופן עצמאי. פוסט זה צולל לתוך מושגי הליבה של Module Federation, מתמקד ביכולות שיתוף זמן הריצה שלו, ובוחן כיצד הוא יכול לחולל מהפכה בדרך שבה צוותים גלובליים בונים ומנהלים את אפליקציות הווב שלהם.

הנוף המתפתח של פיתוח ווב והצורך בשיתוף

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

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

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

Module Federation נותן מענה ישיר לאתגרים אלה על ידי הצגת מנגנון לשיתוף קוד אמיתי בזמן ריצה.

מהו JavaScript Module Federation?

JavaScript Module Federation, המיושם בעיקר באמצעות Webpack 5, הוא תכונה של כלי בנייה המאפשרת לאפליקציות JavaScript לטעון קוד באופן דינמי מאפליקציות אחרות בזמן ריצה. הוא מאפשר יצירה של מספר אפליקציות עצמאיות שיכולות לחלוק קוד ותלויות ללא צורך ב-monorepo או בתהליך אינטגרציה מורכב בזמן בנייה.

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

הבנת שיתוף בזמן ריצה: ליבת Module Federation

שיתוף בזמן ריצה הוא אבן הפינה של העוצמה של Module Federation. בניגוד לטכניקות מסורתיות של פיצול קוד (code-splitting) או ניהול תלויות משותפות המתרחשות לעיתים קרובות בזמן בנייה, Module Federation מאפשר לאפליקציות לגלות ולטעון מודולים מאפליקציות אחרות ישירות בדפדפן של המשתמש. משמעות הדבר היא שספרייה נפוצה, ספריית רכיבי UI משותפת, או אפילו מודול תכונה (feature module) יכולים להיטען פעם אחת על ידי אפליקציה אחת ולאחר מכן להיות זמינים לאפליקציות אחרות הזקוקות לו.

בואו נפרט כיצד זה עובד:

מושגי מפתח:

• Exposes (חושף): אפליקציה יכולה 'לחשוף' מודולים מסוימים (למשל, רכיב React, פונקציית עזר) שאפליקציות אחרות יכולות לצרוך. מודולים חשופים אלה נארזים לתוך קונטיינר שניתן לטעון מרחוק.
• Remotes (מרוחקים): אפליקציה החושפת מודולים נחשבת 'remote'. היא חושפת את המודולים שלה באמצעות תצורה משותפת.
• Consumes (צורך): אפליקציה שצריכה להשתמש במודולים מ-remote היא 'consumer' או 'host'. היא מגדירה את עצמה לדעת היכן למצוא את האפליקציות המרוחקות ואילו מודולים לטעון.
• Shared Modules (מודולים משותפים): Module Federation מאפשר להגדיר מודולים משותפים. כאשר מספר אפליקציות צורכות את אותו מודול משותף, רק מופע אחד של אותו מודול נטען ומשותף ביניהן. זהו היבט קריטי באופטימיזציה של גדלי bundle ומניעת התנגשויות תלויות.

המנגנון:

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

היתרונות של Module Federation לפיתוח גלובלי

היתרונות באימוץ Module Federation לבניית אפליקציות גלובליות הם משמעותיים ורחבי היקף:

1. סקיילביליות ותחזוקתיות משופרות:

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

2. גדלי Bundle וביצועים אופטימליים:

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

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

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

3. אוטונומיה ושיתוף פעולה מוגברים בצוות:

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

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

4. אגנוסטיות טכנולוגית (עם הסתייגויות):

אף על פי ש-Module Federation בנוי על Webpack, הוא מאפשר מידה של אגנוסטיות טכנולוגית בין מיקרו-פרונטאנדים שונים. מיקרו-פרונטאנד אחד יכול להיות בנוי עם React, אחר עם Vue.js, ושלישי עם Angular, כל עוד הם מסכימים כיצד לחשוף ולצרוך מודולים. עם זאת, לשיתוף אמיתי בזמן ריצה של פריימוורקים מורכבים כמו React או Vue, יש להקדיש תשומת לב מיוחדת לאופן שבו פריימוורקים אלה מאותחלים ומשותפים כדי למנוע טעינה של מופעים מרובים וגרימת התנגשויות.

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

5. ניהול גרסאות קל יותר:

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

יישום Module Federation: דוגמאות ואסטרטגיות מעשיות

בואו נבחן כיצד להגדיר ולמנף את Module Federation בפועל. נשתמש בתצורות Webpack פשוטות כדי להמחיש את מושגי הליבה.

תרחיש: שיתוף ספריית רכיבי UI

נניח שיש לנו שתי אפליקציות: 'קטלוג מוצרים' (remote) ו-'לוח מחוונים למשתמש' (host). שתיהן צריכות להשתמש ברכיב 'Button' משותף מספריית 'Shared UI' ייעודית.

1. ספריית 'Shared UI' (Remote):

אפליקציה זו תחשוף את רכיב ה-'Button' שלה.

            
const { ModuleFederationPlugin } = require('webpack');
const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'remoteEntry.js',
    path: path.resolve(__dirname, 'dist'),
    publicPath: 'http://localhost:3001/dist/', // URL where the remote will be served
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'sharedUI',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button.js', // Expose Button component
      },
      shared: {
        // Define shared dependencies
        react: {
          singleton: true, // Ensure only one instance of React is loaded
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... other webpack configurations (babel, devServer, etc.)
};

            

              
                Copy
              
            
          

src/components/Button.js:

            
import React from 'react';

const Button = ({ onClick, children }) => (
  
    {children}
  
);

export default Button;

            

              
                Copy
              
            
          

בהגדרה זו, 'Shared UI' חושף את רכיב ה-Button שלו ומכריז על react ו-react-dom כתלויות משותפות עם singleton: true כדי להבטיח שהם יטופלו כמופעים בודדים על פני האפליקציות הצורכות.

2. אפליקציית 'קטלוג המוצרים' (Remote):

אפליקציה זו תצטרך גם היא לצרוך את רכיב ה-Button המשותף ולשתף את התלויות שלה.

            
const { ModuleFederationPlugin } = require('webpack');
const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'remoteEntry.js',
    path: path.resolve(__dirname, 'dist'),
    publicPath: 'http://localhost:3002/dist/', // URL where this remote will be served
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'productCatalog',
      filename: 'remoteEntry.js',
      exposes: {
        './ProductList': './src/components/ProductList.js', // Expose ProductList
      },
      remotes: {
        // Define a remote it needs to consume from
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
      },
      shared: {
        // Shared dependencies with the same version and singleton: true
        react: {
          singleton: true,
        },
        'react-dom': {
          singleton: true,
        },
      },
    }),
  ],
  // ... other webpack configurations
};

            

              
                Copy
              
            
          

'קטלוג המוצרים' חושף כעת את רכיב ה-ProductList שלו ומכריז על ה-remotes שלו, תוך שהוא מצביע באופן ספציפי לאפליקציית 'Shared UI'. הוא גם מכריז על אותן תלויות משותפות.

3. אפליקציית 'לוח מחוונים למשתמש' (Host):

אפליקציה זו תצרוך את רכיב ה-Button מ-'Shared UI' ואת ה-ProductList מ-'קטלוג מוצרים'.

            
const { ModuleFederationPlugin } = require('webpack');
const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, 'dist'),
    publicPath: 'http://localhost:3000/dist/', // URL where this app's bundles are served
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'userDashboard',
      remotes: {
        // Define the remotes this host application needs
        sharedUI: 'sharedUI@http://localhost:3001/dist/remoteEntry.js',
        productCatalog: 'productCatalog@http://localhost:3002/dist/remoteEntry.js',
      },
      shared: {
        // Shared dependencies that must match the remotes
        react: {
          singleton: true,
          import: 'react', // Specify the module name for import
        },
        'react-dom': {
          singleton: true,
          import: 'react-dom',
        },
      },
    }),
  ],
  // ... other webpack configurations
};

            

              
                Copy
              
            
          

src/index.js עבור 'לוח מחוונים למשתמש':

            
import React, { Suspense } from 'react';
import ReactDOM from 'react-dom';

// Dynamically import the shared Button component
const RemoteButton = React.lazy(() => import('sharedUI/Button'));

// Dynamically import the ProductList component
const RemoteProductList = React.lazy(() => import('productCatalog/ProductList'));

const App = () => {
  const handleClick = () => {
    alert('Button clicked from shared UI!');
  };

  return (
    

      
User Dashboard
      Loading Button...
}>
        Click Me
      

      
Products
      Loading Products...