فرانت‌اندهای خرد
دنیای مهندسی سعی می کند عناصر بزرگ را ساده کرده و به قطعات جدا از هم تجزیه کند. کلاس های بزرگ را می توان با استفاده از مفاهیم مختلف مانند SOLID و موارد دیگر به عناصر اختصاصی تجزیه کرد. برنامه ها می توانند از کتابخانه ها استفاده کنند. خدمات Backend را می توان به ماژول ها یا میکرو سرویس ها تقسیم کرد.
در حوزه فرانت اند بیشتر در مورد مفهوم تجزیه برنامه بزرگ صفحه تک (SPA) به ماژول هایی که به عنوان خدمات میکرو کار می کنند می شنویم، آنها نام “Micro-Frontends” را گرفتند. ما یک ارکستراتور داریم که خدمات را مدیریت و پخش می کند – برنامه های میکرو با کمک به راه اندازی و اتصال آنها به یکدیگر.
یکی از حیاتی ترین جنبه های میکرو فرانتندها این است لایه ارتباطی.
چالش های ارتباطی
بیایید سناریویی را در نظر بگیریم که در آن کاربر می‌خواهد از یک برنامه اینستاگرام مانند با آلبوم‌ها، عکس‌ها و عملکردهای مرتبط استفاده کند.
کاربر URL دامنه اصلی را باز می کند و مرورگر ارکستراتور را بارگیری می کند که سپس فرآیند بارگیری وابستگی های باقی مانده را آغاز می کند.
برنامه را می توان به فریم یا بر اساس منطق تجاری تقسیم کرد. روش دوم برای ایجاد یک سیستم قابل اتصال کارآمدتر است. همانطور که کاربر اولین برنامه میکرو را با صفحه اصلی باز می کند، کاربر می تواند نمایه خود را با یک آلبوم خالی ببیند. با کلیک کردن روی دکمه «آپلود عکس»، سیستم از ارکستراتور می‌خواهد تا یک میکروبرنامه جدید مانند یک پنجره آپلودکننده با پیش نیازها یا زمینه را نصب کند.
بیایید صف اول سؤالات را در نظر داشته باشیم: چگونه از ارکستراتور بخواهیم این پیش نیازها مانند موقعیت بازشو، زمینه کاربر را ارائه دهد؟
هنگامی که کاربر یک عکس را از طریق پنجره بازشو آپلود کرد، سیستم باید پنجره بازشو را جدا کند، عکس‌های نمایه را تازه‌سازی کند و شمارنده‌های آلبوم را روی صفحه به‌روزرسانی کند.
بدون یک مکانیسم طولانی نظرسنجی یا سوکت‌های وب، این سوال باقی می‌ماند: چگونه می‌توانیم رویدادی درباره یک عکس جدید از یک میکرواپلیکیشن جدا شده به دیگری ارائه کنیم؟
اگرچه این یک سناریوی ساده است، اما انتخاب مفهوم مناسب برای تبادل رویدادها بین ریز برنامه‌ها یا طراحی ورودی/خروجی‌های آنها چالش است.
هیچ راه حل گلوله نقره ای وجود ندارد، اما معماری های مختلف می توانند به حل این سؤالات مانند ماژول های ابزار و مدیر رویداد متمرکز کمک کنند.
ماژول های کاربردی
در زمینه ماژول آپلودکننده عکس، می‌توانیم چندین API و رویداد مانند باز کردن برنامه، آپلود عکس و بستن برنامه را شناسایی کنیم. با استفاده از چارچوب های موجود MFE مانند single-spa، ما می توانیم مسائل مربوط به نصب و جداسازی را انجام دهیم. چالش اصلی برقراری ارتباط بین ریز برنامه‌ها برای اطلاع از رویدادی مانند آپلود عکس است.
یک مکانیسم قابل مشاهده می تواند در این سناریو سودمند باشد. ما می‌توانیم یک کلاس ساده ایجاد کنیم که یک قابل مشاهده را محصور می‌کند و به ما امکان می‌دهد رویدادهای مشخص‌شده توسط یک رابط را منتشر کنیم و در آنها مشترک شویم.
export class UploaderManagerUtils {
private static newPhotoSbj = new Subject<Photo>();
public static get newPhoto$(): Observable<Photo> {
return UploaderManagerUtils.newPhotoSbj.asObservable();
}
public static createPhoto(photo: Photo): void {
UploaderManagerUtils.newPhotoSbj.next(photo);
}
}
یک جزء بصری دیگر می تواند این ماژول را از lib من وارد کند و به روز رسانی ها را مدیریت کند:
UploaderManagerUtils.newPhoto$.subscribe((photo) => {
this.collection.add(photo);
});
و مؤلفه دیگری می تواند این رویداد را راه اندازی کند:
UploaderManagerUtils.createPhoto({ id: 1, blob: ... });
در نتیجه، می‌توانیم رویدادهای بارگذاری را با بارگذاری بدون هیچ گونه سیستم مدیریت رویداد ارسال کنیم و همه مصرف‌کنندگان می‌توانند بدون محدودیت از آنها استفاده کنند. برای اهداف تحویل، UploaderManagerUtils باید در یک بسته npm مستقل پیچیده شود تا از webpack درخواست شود تا یک نمونه کلاس واحد را برای همه برنامه‌های میکرو وارد کند. این رویکرد نام داردماژول های کاربردی“.
طرفداران:
- راه حل چارچوب-آگنوستیک.
- از اجرای هر رویداد در زیر هود پشتیبانی می کند. ماژول ابزار باید از دو اینترفیس پشتیبانی کند: یکی برای انتشار و دیگری برای اشتراک بارگذاری.
- تست آسان با ماژول های تمسخر آمیز.
معایب:
- هر ریز برنامه به یک کتابخانه اضافی برای مدیریت رویدادها نیاز دارد که منجر به مشکلات لجستیکی مانند نگهداری چندین کتابخانه، به‌روزرسانی آنها برای همه برنامه‌های کوچک و رسیدگی به مشکلات تحویل می‌شود.
- بدون مشخصات از نظر تئوری می توان از راه حل های متفاوت و ناکارآمد زیر کاپوت استفاده کرد.
مدیر رویداد متمرکز
مفهوم میکرو برنامه ها بر جداسازی تأکید دارد، اما در عین حال، ما می توانیم مشخصات یا API خود را برای آنها تصور کنیم. ما می‌توانیم یک پوشش ساده برای برنامه‌های میکرو خود ایجاد کنیم، که تمام زمینه‌های خارجی را در بر می‌گیرد و از کتابخانه‌ها و API ما برای ادغام رویدادهای داخلی با دنیای بیرونی استفاده می‌کند و بالعکس. این با تصویب یک نمونه مدیریت رویداد که رویدادها را انتقال می دهد و به صورت اختیاری به مدیریت حالت کمک می کند، به دست می آید.
در حالی که ما مقداری انزوا را از دست می دهیم زیرا برنامه میکرو ما کاملاً به پارامترهای خارجی متکی است، یک لایه ارتباطی قوی به دست می آوریم. به عنوان مثال، اگر می خواهید ارتباط برقرار کنید که کاربر یک عکس را آپلود می کند، نیازی به ایجاد یک ابزار جدید ندارید. شما فقط می توانید دستور خود را با بارگذاری به کانال ارسال کنید و همه مصرف کنندگان خارجی می توانند رویداد شما را واکشی کنند. علاوه بر این، برنامه شما می‌تواند مشترک اقدامات خارجی (مثلاً خروج) شود تا آپلود به درستی متوقف شود.
یکی از محبوب ترین سیستمی که به سازماندهی آن کمک می کند – Redux. این به طور جدی توسط هر چارچوب SPA توصیه شده است، دارای جامعه بزرگ، مواد، راه حل ها است. رسمی single-spa راهنمایی را به اشتراک می گذارد تا اگر می خواهیم برنامه خود را ساده کنیم، از آن استفاده کنیم.
بنابراین برنامه ما نیازی به کلاس و کلاس اضافی ندارد، می توانم شرکت کنم dispatch برای فروشگاه جهانی عمل کنید یا به صورت دستی از store API استفاده کنید:
Redux یکی از محبوب ترین سیستم هایی است که می تواند به سازماندهی این مدیر رویداد متمرکز کمک کند. این به طور گسترده توسط بسیاری از چارچوب های SPA توصیه می شود و دارای یک جامعه، مواد و راه حل های بزرگ است. رسمی single-spa راهنما پیشنهاد می کند اگر می خواهید برنامه خود را ساده کنید، از Redux استفاده کنید. بنابراین برنامه شما به هیچ کتابخانه و کلاس اضافی نیاز ندارد و می توانید از تابع اعزام برای فروشگاه جهانی استفاده کنید یا از API فروشگاه به صورت دستی استفاده کنید:
this.store.dispatch({
action: UPLOADER__NEW_PHOTO,
payload: {id: 1, blob: ... },
});
بعد از آن می توانم مشترک شوم this.store و اقدامات را فیلتر کنید یا از کاهش دهنده ها استفاده کنید و با حالات من کار کنید.
طرفداران:
- راه حل محبوب با مقالات بسیاری از دنیای React.
- به راحتی با هر سیستمی قابل ادغام است.
- محیطی مستحکم و سازگار برای همه ریز برنامه ها فراهم می کند.
- اجتناب از بسیاری از وابستگی های خارجی
- به راحتی می توان رویدادهای تمسخر آمیز من یا با استفاده از چارچوب های تست redux موجود را آزمایش کرد.
معایب:
- اپلیکیشن میکرو با استفاده از یک جریان ارتباطی، تنگنا و روابط سختی خواهد داشت.
خلاصه
Micro-frontends به عنوان یک رویکرد محبوب برای ساده سازی برنامه های پیچیده با تجزیه آنها به ماژول های کوچکتر و قابل مدیریت تر ظاهر شده اند. هنگام پیاده سازی میکرو فرانت اند، لایه ارتباطی سنگ بنای تعامل یکپارچه بین برنامه های کوچک است.
راه حل های زیر را برای برقراری ارتباط موثر بین ریز برنامه ها در نظر بگیرید:
- ماژول های Utility یک راه حل چارچوب-آگنوستیک را ارائه می دهند که از انتشار و اشتراک در محموله ها پشتیبانی می کند. با این حال، آنها ممکن است به کتابخانه های اضافی برای هر برنامه میکرو نیاز داشته باشند که منجر به چالش های لجستیکی می شود. ماژول های ابزار زمانی ایده آل هستند که در مورد توسعه آینده محصول خود نامطمئن هستید و به انعطاف پذیری نیاز دارید تا نیازها و نیازها را متعادل کنید.
- مدیران رویداد متمرکز، مانند Redux، یک محیط سازگار برای همه برنامه‌های کوچک فراهم می‌کنند و ارتباطات را ساده می‌کنند. با این حال، آنها ممکن است یک تنگنا و روابط سخت بین برنامه های میکرو ایجاد کنند. مدیران رویداد متمرکز زمانی مناسب هستند که می‌خواهید روی یک پایه تمرکز کنید و محصول خود را با افزودن عملکردهای جدید، ارائه ماژول‌ها و ارائه به‌روزرسانی‌های مداوم رشد دهید.
در نهایت، انتخاب بین ماژول های ابزار و مدیران رویداد متمرکز به الزامات و محدودیت های خاص پروژه شما بستگی دارد. نیازهای پروژه خود را به دقت ارزیابی کنید تا مناسب ترین راه حل را برای ارتباط کارآمد بین برنامه های میکرو در معماری micro-frontend خود تعیین کنید.
