من اخیراً در مورد پنج دلیل نوشتم که چرا ارزش پذیرش معماری میکرو پیشانی را دارد. البته هر چیزی مزایا و معایبی دارد. Micro frontend یک رویکرد معماری جدید است و احتمالاً آینده توسعه وب را نشان می دهد. در عین حال، آنها با چند دام مواجه هستند و دانستن آنها برای مقابله یا اجتناب کامل از آنها ضروری است.
در این مقاله، مهم‌ترین درس‌هایی را که من و تیمم هنگام استفاده از میکرو فرانتاند آموختیم، یاد می‌گیرید. در طول یک دوره دو ساله، ما مسائل بسیاری را در مورد این معماری شناسایی کردیم و به همان اندازه اشتباه کردیم. بنابراین، وقت آن است که آنها را به اشتراک بگذارید تا به شما در مقابله یا اجتناب از آنها کمک کند.
بیایید ابتدا به یاد بیاوریم که معماری micro frontend چیست و سپس به مشکلات آنها و نحوه اجتناب از هر یک از آنها بپردازیم.
به طور خلاصه Micro Frontends
مارتین فاولر رویکرد میکرو فرانتاند به توسعه را اینگونه تعریف می کند:
یک سبک معماری که در آن برنامه های کاربردی مستقل قابل تحویل در یک کل بزرگتر ترکیب می شوند.
هنگامی که برای توسعه وب اعمال می شود، به این معنی است که بسیاری از برنامه های کاربردی کوچک مستقل که بخشی از همان وب سایت یا برنامه وب هستند. همانطور که قبلاً در اینجا ذکر شد، تیم من از این روش با موفقیت استفاده کرده بود. به ویژه، ما این فرصت را داشتیم که از تمام مزایای آن مانند مقیاس پذیری، استقلال فناوری و قابلیت نگهداری استفاده کنیم. از سوی دیگر، در بلندمدت متوجه برخی مسائل جدی شدیم. بنابراین، ما تصمیم گرفتیم که این رویکرد معماری را کنار بگذاریم تا به معماری یکپارچه سنتی تر برگردیم.
این بدان معنی است که ما نه تنها چیزهای خوبی را که با فرانت‌اندهای میکرو همراه است، بلکه معایب عمده آنها را نیز یاد گرفتیم. بیایید اکنون به آنها بپردازیم و ببینیم برای اجتناب از آنها یا رسیدگی به آنها چه کاری باید انجام می دادیم.
1. وابستگی های زائد
هر اپلیکیشن micro frontend طبق تعریف مستقل از بقیه است. به عبارت دیگر، یک معماری micro-frontend شامل بیش از یک برنامه frontend است که باید بتواند بدون سایرین نیز کار کند. برای اجازه دادن به این امر، هر یک از آنها وابستگی های خاص خود را دارند. بنابراین، با نگاه کردن به کل، مزایای استفاده از یک مدیر بسته را از دست می دهید. در واقع، کل برنامه شما احتمالاً شامل بسیاری از نسخه‌های کتابخانه‌های مشابه است که در قسمت‌های کوچک پراکنده هستند.
این بدون شک یک مشکل است، زیرا برنامه وب شما را به طور غیر ضروری بزرگتر از همتای یکپارچه خود می کند. این بر عهده کاربران نهایی است که مجبور به دانلود داده های بیشتری هستند. علاوه بر این، این بر زمان رندر و در نتیجه تاثیر می گذارد Google Web Vitals نمرات، همچنین بر سئوی وب سایت شما تأثیر می گذارد.
چگونه به این موضوع رسیدگی کنیم
یک راه حل ممکن شامل سه مرحله است. ابتدا مجموعه ای از کتابخانه های مشترک را در تمامی بخش های کوچک شناسایی کنید. دوم، یک فرانت اند میکرو ایجاد کنید که شامل تمام کتابخانه های مشترک است. سپس، micro frontendهای خود را به‌روزرسانی کنید تا بسته ساخته شده آنها کتابخانه‌های مورد نیاز را از این پروژه مشترک وارد کنند.
همانطور که در نسخه اصلی مارتین فاولر توضیح داده شده است پست وبلاگ از آنجایی که این ایده از آن سرچشمه می گیرد، به اشتراک گذاری وابستگی ها بین برنامه ها موانع زیادی را ایجاد می کند و نمی توان آن را کار آسانی در نظر گرفت. بنابراین هنگام تلاش برای رسیدن به این هدف، این را در نظر داشته باشید.
2. سبک های متضاد و همپوشانی
باز هم تکنولوژی و استقلال تیمی عالی است، اما می تواند مسائلی را نیز مطرح کند. این امر به ویژه در هنگام برخورد با یک ظاهر طراحی صادق است. در واقع، هر فروند کوچک نمی تواند سبک خاص خود را از دیدگاه تجاری داشته باشد. این به این دلیل است که قطعاً نمی‌خواهید برنامه‌های شما متشکل از وصله‌های متعدد به نظر برسند. همه چیز باید از نظر سبک، UI و UX یکدست به نظر برسد.
یکی دیگر از مشکلات ناشی از داشتن چند فرانت اند که بخشی از یک برنامه است این است که می توانید با نادیده گرفتن قوانین CSS ناخواسته مواجه شوید. همپوشانی‌های نامطلوب از نظر CSS هنگام برخورد با فرانت‌اندهای میکرو رایج می‌شوند، و ممکن است پس از استقرار برنامه‌تان از آنها مطلع شوید. دلیل آن این است که هر تیم معمولاً فقط بر روی برنامه خود کار می کند و قبل از استقرار تصویر کامل را نمی بیند.
این مسائل می تواند بر شهرت برند شما تأثیر منفی بگذارد. همچنین کاربران نهایی بهای این ناهماهنگی ها را به خصوص از نظر رابط کاربری پرداخت خواهند کرد.
چگونه به این موضوع رسیدگی کنیم
تنها راه حل ممکن در مورد UI و UX این است که مطمئن شوید که هر تیم با دیگری صحبت می کند و نتیجه یکسانی در ذهن دارد. همچنین، افزودن مولفه‌های سبک‌دهی‌شده در پروژه میکرو پیشانی مشترک فوق‌الذکر می‌تواند در اینجا کمک کند. با این وجود، این امر باعث می‌شود که هر اپلیکیشن جانبی میکرو به آن وابسته باشد و در نتیجه استقلال زیربنایی را از بین ببرد. اما حداقل از ناهمگن به نظر رسیدن برنامه شما به عنوان یک کل جلوگیری می کند.
اگر می خواهید از همپوشانی CSS جلوگیری کنید، یک راه حل شامل اضافه کردن یک شناسه به کانتینر frontend است <div>. سپس، بسته وب را طوری پیکربندی کنید که این شناسه را قبل از هر قانون CSS وارد کند. در غیر این صورت، می توانید تصمیم بگیرید که یک متدولوژی CSS مانند BEM (Block-Element-Modifier) اتخاذ کنید. این شما را تشویق می‌کند که وب‌سایت را مجموعه‌ای از بلوک‌های اجزای قابل استفاده مجدد در نظر بگیرید که نام کلاس آن باید در پروژه شما منحصر به فرد باشد. مقدمه BEM را بخوانید تا درباره نحوه عملکرد این سیستم بیشتر بدانید.
3. عملکرد ضعیف
در نتیجه اجرای بیش از یک برنامه JavaScript frontend در یک صفحه، کل برنامه را کند می کند. این به این دلیل است که هر نمونه چارچوب به منابعی از نظر CPU، RAM و پهنای باند شبکه نیاز دارد.
همچنین، به خاطر داشته باشید که هنگام آزمایش micro frontend خود جدا از دیگران، ممکن است متوجه این موضوع نشوید. مشکلات زمانی شروع می شوند که بیش از یک نمونه از یک فریم ورک به طور همزمان در حال اجرا باشد. این به این دلیل است که، اگر آنها به طور مستقل اجرا شوند، مجبور نیستند منابع ماشین زیربنایی را همانطور که باید در هنگام استقرار به اشتراک بگذارند.
چگونه به این موضوع رسیدگی کنیم
ایده ای برای حل این مشکل تقویت ارتباطات تیمی برای جلوگیری از تماس ها و توضیحات مشابه است. سپس، نتایج آنها را در مکانی ذخیره کنید که هر میکرو فرانت اند به آن دسترسی دارد، یا به آنها اجازه دهید قبل از انجام یک عملیات سنگین با هم ارتباط برقرار کنند تا بررسی کنند که آیا همان داده ها قبلاً بازیابی یا تولید شده اند یا خیر.
همچنین، در مورد عملکرد، باید برنامه را با همه میکرو فرانت‌اندهای آن تست کنید و به آزمایش‌هایی که روی هر میکرو فرانتاند به تنهایی انجام می‌شود، اعتماد نکنید.
4. ارتباط بین Frontends
در ابتدا، به جز در موارد نادر، نیازی به برقراری ارتباط میان فرونت های کوچک خود نخواهید داشت. این ممکن است شما را فریب دهد که فکر کنید همیشه اینطور خواهد بود. همچنین، اگرچه الگوی معماری میکرو پیشانی در مورد استقلال است، اما این با ارتباطات مخالف است.
هنگامی که برنامه به طور کلی رشد می کند، ایجاد ارتباط بی دردسر با یکدیگر، احتمالاً در اولویت قرار می گیرد. مهم‌تر از همه، اگر می‌خواهید همان عملیات را بارها و بارها تکرار کنید، به‌خصوص اگر ضعیف نباشند.
همچنین، همانطور که در بالا توضیح داده شد، برای دستیابی به عملکرد بالاتر، ارتباط ضروری است. به عنوان مثال، شما نمی خواهید برنامه شما یک تماس API را دو بار انجام دهد تا داده های یکسانی را بازیابی کند و سرور شما را بی جهت کند کند.
چگونه به این موضوع رسیدگی کنیم
راه حل این است که یک لایه پیام رسانی سفارشی بر اساس یک حالت اشتراکی ذخیره شده در یک کوکی یا محل ذخیره سازی، یا در رویدادهای سفارشی تعریف شده. همانطور که می توانید تصور کنید، اجرای این کار هزینه ای دارد و می تواند به سرعت پیچیده و دست و پا گیر شود. همچنین، در نظر بگیرید که ارتباطات سربار را معرفی می کند. بنابراین، باید مطمئن باشید که چیزی که می‌سازید، مزایای واقعی را به همراه خواهد داشت و سرعت برنامه‌تان را بیش از این کاهش نمی‌دهد.
5. مسائل ارتباطی بین تیم ها
ارتباط در یک تیم بزرگ می تواند مشکل ساز باشد، اما هیچ چیز بدتر از ارتباط بین چندین تیم نیست. این به این دلیل است که وجود تیم‌های متعددی که روی پایگاه‌های کد مختلف کار می‌کنند به این معنی است که یافتن ویژگی‌ها، توابع و ابزارهای قابل استفاده مجدد دشوارتر می‌شود. این از نظر قابلیت کشف کد و در نتیجه قابلیت استفاده مجدد بد است. به عبارت دیگر، ممکن است به راحتی با پیاده‌سازی‌های تکراری از اجزای یکسان در میکرو فرانت‌اندهای مختلف مواجه شوید.
چگونه به این موضوع رسیدگی کنیم
راه حل این است که از ابتدا منطق ارتباط بین تیم ها را پشتیبانی کنید. همانطور که در بالا ذکر شد، این شامل داشتن یک پروژه با منابع قابل استفاده مجدد برای هر فناوری اتخاذ شده است. اما داشتن چنین پروژه ای بدون به روز نگه داشتن آن، آن را بی فایده می کند.
بنابراین، باید به هر تیم اجازه دهید تا اجزا و کتابخانه ها را به آن اضافه کند. همچنین، داشتن یک تیم اختصاص داده شده به این امر می تواند کل فرآیند را آسان تر کند. در واقع، ممکن است برای یک تیم مستقل و منزوی آسان نباشد که بفهمد کدام عناصر توسط بیش از یک فروند میکرو به اشتراک گذاشته می شود.
علاوه بر این، استقلال فناوری را چندین تیم منزوی تصور نکنید. برعکس، داشتن تیم هایی که با یکدیگر صحبت می کنند و خود را به روز نگه می دارند برای موفقیت پروژه بسیار مهم است. بنابراین، پرورش فرهنگ ارتباطات باید یکی از عناصر کلیدی در هنگام اتخاذ یک معماری فرانت اند میکرو باشد.
نتیجه
در این مقاله، ما به پنج مشکل بزرگ رویکرد معماری micro frontend، با پشتوانه تجربه‌ای که تیم من در حین کار روزانه با آن به مدت دو سال جمع‌آوری کرده‌اند، نگاه کردیم. اگرچه رویکرد micro frontend به توسعه دهندگان این امکان را می دهد که یک برنامه frontend را به بخش های مستقل کوچکتر تقسیم کنند، اما این بدان معنا نیست که هر تیم نیز باید ایزوله باشد. برعکس، به اشتراک گذاری راه حل ها، مؤلفه ها، منابع و دانش کلید موفقیت است.
متأسفانه ما این را به عنوان یک تیم نمی دانستیم. بنابراین، ما مجبور شدیم که سفر میکرو فرانتند خود را رها کنیم. اما ما از این ماجراجویی چیزهای زیادی یاد گرفتیم، و امیدوارم برای به اشتراک گذاشتن دلایل اصلی که ما را به شکست سوق داده و نحوه اجتناب از آنها یا مقابله با آنها مفید باشد.
با تشکر برای خواندن! در صورت تمایل به به من برس با هرگونه سوال، نظر یا پیشنهاد
