میکروفرانت، انقلابی در توسعه سمت کاربر

هرروز که میگذره، شاهد گسترده‌تر شدن و پیچیده‌تر شدن سیستم‌ها هستیم. سیستم‌های تحت وب هم از این قاعده مستثنی نیستن. یک فروشگاه تحت وب رو در نظر بگیرید (البته با دید فرانت اند!). شاید ساده‌ترین قسمت این فروشگاه، صفحاتی مثل درباره ما باشه که صرفا از چند متن و عکس ساده تشکیل شدن. صفحات همینطور پیچیده و پیچیده‌تر میشن، تا به غول‌هایی مثل صفحه جست و جوی پیشرفته یا پنل کاربری برای هر مشتری یا فروشنده می‌رسن! اون اوایل طبیعی بود که بیایم و تمامی این مجموعه رو، هرچقدرم که پیچیده باشه، تحت یک سیستم بالا بیاریم. ولی خب این مسئله باعث کاهش شدید قابلیت مقیاس‌پذیری (scalability) و افزایش شدید هزینه‌های مربوطه میشد (چه مالی و چه زمانی).اینجا بود که یک معماری خاص به نام معماری میکرو-فرانت یا Micro-Front به وجود اومد. این معماری، برگرفته از مفهوم کلی‌تر معماری میکروسرویس هست، معماری‌ای که بر طبق اون، یک سیستم نرم‌افزاری به قسمت‌های کوچیک، مقیاس‌پذیر و قابل مدیریتی به نام سرویس یا Service تقسیم میشه.بنابراین معماری میکروفرانت، میگه آقا! اون سیستم غولی رو که داری میسازی، حتما و حتما به اجزای کوچک‌تر و تا حد امکان مستقل تقسیمش کن.حالا بررسی کنیم و ببینیم معماری میکروفرانت چه فوایدی برای ما داره؟فرض کنید که یک وب‌سایت شامل دو سرویس main و dashboard داریم. تو سرویس main، ساختار اصلی سایت رو میبینیم، چیزی که در نتایج گوگل نمایش داده میشه. سرویس dashboard، همونطور که از اسمش پیداست، پنل مدیریت وب‌سایت رو در برمیگیره. چیزی که فقط مدیران سایت یا کاربران ثبت‌نام شده باهاش سر و کار دارن.این دو سرویس کاملا به شکل جداگونه‌ای توسعه پیدا می‌کنن و در نهایت توسط روش‌های مخصوص به خودشون، به هم متصل میشن.استقلال تیم‌های فعال بر پروژهافراد و تیم‌های فعال بر پروژه، دارای آزادی مناسبی تو انجام کارشون هستن. ازونجایی که dashboard و main، کمترین وابستگی رو به هم دارن، دیگه لازم نیست تیم توسعه dashboard، بابت هر تغییر یا مسئله کوچیکی مزاحم تیم توسعه main بشه. ارتباط این دو تیم صرفا بابت تغییرات گسترده در تمام سایت خواهد بود. برای مثال، ممکنه مدیر پروژه درخواست کنه که بخش فروشگاه از سایت حذف شه. در این صورت، دو تیم باید یه صحبت کوچیک داشته باشن تا صرفا سر یک سری مسائل فنی، استانداردهای ساده‌ای رو تعیین کنن.این استقلال به حدی بالاست، که ما می‌تونیم در یک سیستم فرانت-اند، از تکنولوژی‌های متفاوتی استفاده کنیم. تیم‌ها آزادی زیادی در انتخاب تکنولوژی مورد استفادشون دارن. ما در میکرو-فرانت، می‌‌تونیم main رو با React، و dashboard رو با Vue بنویسیم. مشکلی پیش نمیاد!وابسته نبودن کتابخونه‌ها!کتابخونه‌ها (اصطلاح تخصصی‌تر، dependencyها یا وابستگی‌ها) نقش مهمی رو در اضافه کردن قابلیت‌های پیشرفته در فرانت-اند ما بازی می‌کنن. ممکنه فرانت-اندی که داریم می‌نویسیم، دارای ۱۰ها کتابخونه مختلف باشه. این ۱۰ها کتابخونه، باید از نظر نسخه باهم خوانایی داشته باشن.فرض کنید در هردو سرویس dashboard و main، کتابخونه X با ورژن ۱۰ رو داریم. بنا به دلایلی، مجبوریم ورژن این کتابخونه در main رو از ۱۰ به ۶ کاهش بدیم. در معماری میکروفرانت، بخش dashboard میتونه همواره با همون ورژن ۱۰ کار کنه، بدون اینکه نگران تغییر ورژن X در بخش main و در نتیجه نگران ناخوانی ورژن کتابخونه‌ها با هم باشه.سرعت بالا در توسعهاستقلال تیم‌های فعال در پروژه، متناسبا باعث سرعت بالاتر در توسعه نرم افزار میشه، چرا که نیاز ما به برگزاری جلسات فنی زیاد رو کم می‌کنه.قابلیت نگهداری بسیار بالا (maintainability)مستقل بودن اجزای یک سیستم، فرآیند نگهداری و باگیابی در اون‌هارو بسیار ساده می‌کنه. بارزترین مثال این امر، در تست‌نویسی ظاهر میشه، جایی که سرویس‌های مورد نظر به شکل کاملا جداگانه و در محیط ایزوله تست می‌شن. main به تست خود و dashboard هم به تست خود! هیچکدوم با اون یکی قاطی نمی‌شه.میکروفرانت چطور کار می‌کنه؟همونطور که گفتیم، میکروفرانت، میاد و فرانت-اند ما رو به اجزای کوچک‌تری به نام سرویس تقسیم می‌کنه. این سرویس‌ها که هرکدوم یک نرم‌افزار کوچیک به حساب میان، تحت یک نرم‌افزار بزرگ‌تر کار می‌کنن.نرم‌افزار کانتینر ما (همون نرم‌افزار بزرگ‌تره !) می‌تونه به شکل‌های متفاوتی پیاده‌سازی شه:سمت کاربر یا client-sideدر این روش، تمام سرویس‌های ما به شکل همزمان build گرفته شده و تحت عنوان یک build کلی روی سرور قرار می‌گیرن. اگه بخوایم سرویس جدیدتری اضافه کنیم، نیاز داریم که مجدد تمام سرویس‌هارو build بگیریم.سمت سرور یا server-sideدر روش سمت سرور، سرویس‌های ما به شکل جداگونه build گرفته شده و روی سرور قرار می‌گیرن. اینطوری دیگه با یک build گنده و سنگین سر و کله نمی‌زنیم، هر سرویس فقط زمانی لود می‌شه که صدا زده شه و این مسئله باعث بهبود عملکرد (Performance) نرم‌افزار ما می‌شه.سمت مرزی یا Edge-sideاین روش، برگرفته از حوزه رایانش مرزی هست. در این روش، سرویس‌های ما در لایه Edge باهم ترکیب میشن، مثل CDN.نتیجه‌گیریبه انتهای این مقاله می‌رسیم. در این مقاله راجب معماری Micro-Frontend صحبت کردیم و بررسی کردیم که شکستن نرم‌افزار بزرگ به نرم‌افزارهای کوچیک، چه فوایدی می‌تونه داشته باشه.امیدوارم این نوشته براتون مفید بوده باشه، اگه جایی حس کردید مطلب اشتباه نوشته شده یا ایرادی وجود داره، در کامنت‌ها پذیرای شما هستم.منبع: MicroFrontend on Dev.to