کاوشی عمیق در فدراسیون ماژول برای میکروافرانتاندها. بیاموزید چگونه کد و وابستگیها را در زمان اجرا به اشتراک بگذارید، حجم باندل را کاهش دهید و استقرار مستقل را فعال کنید.
فدراسیون ماژول: راهنمای قطعی برای اشتراکگذاری ماژول در زمان اجرا در میکروافرانتاندها
در چشمانداز همیشه در حال تحول توسعه وب، ما شاهد یک تغییر معماری قابل توجه بودهایم. ما از معماریهای یکپارچه (monolithic) به میکروسرویسهای بکاند سفر کردیم تا به مقیاسپذیری و استقلال تیمها دست یابیم. اکنون، همان انقلاب در حال دگرگون کردن فرانتاند است. عصر میکروافرانتاندها فرا رسیده است و در قلب آن، یک فناوری قدرتمند قرار دارد که همه اینها را عملی میکند: فدراسیون ماژول (Module Federation).
چالش اصلی میکروافرانتاندها همیشه بیانش ساده اما حل آن دشوار بوده است: چگونه میتوان یک تجربه کاربری واحد و منسجم را از چندین اپلیکیشن که به طور مستقل مستقر شدهاند، ساخت، بدون اینکه یک آشفتگی کند، حجیم و غیرقابل مدیریت ایجاد شود؟ چگونه میتوانیم کدهای مشترک، مانند کتابخانههای کامپوننت یا فریمورکهایی مانند ریاکت را به اشتراک بگذاریم، بدون اینکه کابوسهای نسخهبندی ایجاد کنیم یا مجبور به انتشار هماهنگ شویم؟
این مشکلی است که فدراسیون ماژول به زیبایی آن را حل میکند. این ویژگی که در وبپک ۵ معرفی شد، فقط یک قابلیت دیگر نیست؛ بلکه یک تغییر پارادایم در نحوه تفکر ما در مورد ساخت و استقرار اپلیکیشنهای وب است. این راهنمای جامع به بررسی چیستی، چرایی و چگونگی فدراسیون ماژول میپردازد و بر تحولآفرینترین قابلیت آن تمرکز دارد: اشتراکگذاری ماژول در زمان اجرا.
یک یادآوری سریع: میکروافرانتاندها چه هستند؟
قبل از پرداختن به مکانیک فدراسیون ماژول، بیایید در مورد منظورمان از میکروافرانتاندها به توافق برسیم. یک وبسایت بزرگ تجارت الکترونیک را تصور کنید. در دنیای یکپارچه، کل فرانتاند - جستجوی محصول، جزئیات محصول، سبد خرید و تسویهحساب - یک اپلیکیشن بزرگ و واحد است. تغییری در دکمه تسویهحساب ممکن است نیاز به تست و استقرار مجدد کل اپلیکیشن داشته باشد.
یک معماری میکروافرانتاند این یکپارچگی را بر اساس حوزههای کسبوکار میشکند. شما ممکن است داشته باشید:
- یک تیم جستجو که مالک نوار جستجو و صفحه نتایج است.
- یک تیم محصول که مالک جزئیات محصول و پیشنهادات است.
- یک تیم تسویهحساب که مالک سبد خرید و فرآیند پرداخت است.
هر تیم میتواند بخش خود از اپلیکیشن را به طور مستقل بسازد، تست کند و مستقر نماید. این امر منجر به چندین مزیت کلیدی میشود:
- تیمهای مستقل: تیمها میتوانند بر اساس برنامهزمانی خود کار کرده و منتشر کنند، که این امر توسعه را تسریع میبخشد.
- استقرارهای مستقل: یک باگ در موتور پیشنهادات، یک بهروزرسانی حیاتی در جریان پرداخت را مسدود نمیکند.
- انعطافپذیری فناوری: تیم جستجو میتواند از Vue.js استفاده کند در حالی که تیم محصول از ریاکت استفاده میکند، که به تیمها اجازه میدهد بهترین ابزار را برای حوزه خاص خود انتخاب کنند (اگرچه این امر نیازمند مدیریت دقیق است).
با این حال، این رویکرد چالشهای خاص خود را نیز به همراه دارد، عمدتاً در زمینه اشتراکگذاری و ثبات، که ما را به روشهای قدیمی انجام کارها میرساند.
روشهای قدیمی اشتراکگذاری کد (و چرا آنها ناکارآمد هستند)
در طول تاریخ، تیمها چندین روش را برای اشتراکگذاری کد بین اپلیکیشنهای فرانتاند مختلف امتحان کردهاند که هر کدام در زمینه میکروافرانتاندها معایب قابل توجهی دارند.
بستههای NPM
رایجترین رویکرد، انتشار کامپوننتها یا ابزارهای مشترک به عنوان یک بسته NPM نسخهبندی شده است. یک کتابخانه کامپوننت مشترک یک مثال کلاسیک است.
- مشکل: این یک وابستگی در زمان ساخت (build-time) است. اگر تیم A کامپوننت مشترک `Button` را در `my-ui-library` از نسخه ۱.۱ به ۱.۲ بهروزرسانی کند، تیم B و تیم C آن بهروزرسانی را دریافت نخواهند کرد تا زمانی که به صورت دستی `package.json` خود را بهروز کنند، `npm install` را اجرا کنند و کل میکروافرانتاند خود را مجدداً مستقر نمایند. این امر باعث ایجاد وابستگی شدید شده و هدف استقرارهای مستقل را از بین میبرد. همچنین منجر به بارگذاری چندین نسخه از یک کامپوننت در مرورگر میشود که حجم نهایی باندل را افزایش میدهد.
Monorepos با Workspaces مشترک
Monorepoها (با استفاده از ابزارهایی مانند Lerna یا Yarn/NPM workspaces) همه میکروافرانتاندها را در یک ریپازیتوری واحد نگه میدارند. این کار مدیریت بستههای مشترک را ساده میکند.
- مشکل: در حالی که monorepoها به تجربه توسعهدهنده کمک میکنند، اما مشکل اصلی زمان اجرا را حل نمیکنند. شما هنوز به وابستگیهای زمان ساخت متکی هستید. تغییری در یک کتابخانه مشترک هنوز هم نیازمند بازسازی و استقرار مجدد تمام اپلیکیشنهای مصرفکننده است تا تغییر را منعکس کنند.