مونولیت یا Micro-Frontend؟ چطور معماری مناسب فرانت‌اند را در سال ۲۰۲۶ انتخاب کنیم

بحث معماری فرانت‌اند اغلب به انتخابی ساده‌شده بین «یک اپلیکیشن بزرگ» و «Micro-Frontend» تبدیل می‌شود. اما سؤال اصلی این نیست. سؤال این است: کدام مرزبندی کمک می‌کند تیم با اطمینان و استقلال بیشتری تغییرات محصول را منتشر کند، بدون اینکه پیچیدگی عملیاتی بیشتری از مشکلات قبلی ایجاد شود؟

مونولیت الزاماً کد شلوغ و به‌هم‌ریخته نیست و Micro-Frontend هم خودبه‌خود مقیاس‌پذیری ایجاد نمی‌کند. هر دو می‌توانند معماری خوبی داشته باشند یا به منبع دردسر تبدیل شوند. انتخاب مناسب به ساختار تیم، مرزهای دامنه، استقلال انتشار، بودجه عملکرد و هزینه نگهداری بستگی دارد.

فرانت‌اند مونولیت چیست؟

در یک فرانت‌اند مونولیت، رابط کاربری معمولاً به‌صورت یک اپلیکیشن توسعه داده، تست و منتشر می‌شود. قابلیت‌ها از سیستم مسیریابی، design system، گراف وابستگی‌ها و فرایند انتشار مشترک استفاده می‌کنند. یک اپلیکیشن React یا Next.js که ماژول‌های داخلی منظم دارد، همچنان می‌تواند مونولیت باشد.

مونولیت چه زمانی انتخاب خوبی است؟

• یک تیم یا چند تیم نزدیک به هم مالک محصول هستند.
• قابلیت‌ها رابط کاربری، state، مسیریابی و جریان‌های کاری مشترک زیادی دارند.
• توسعه محلی، تست، دیباگ و انتشار ساده اهمیت زیادی دارد.
• عملکرد یکپارچه و تجربه کاربری هماهنگ از انتشار مستقل هر بخش مهم‌تر است.

مشکلات رایج مونولیت

مشکل معمولاً خود مونولیت نیست؛ مشکل زمانی شروع می‌شود که مالکیت ماژول‌ها مشخص نباشد، وابستگی‌ها در همه جهت جریان داشته باشند، state مشترک به‌صورت پیش‌فرض global شود یا هر تغییر کوچک به هماهنگی افراد زیادی نیاز پیدا کند. با از بین رفتن مرزهای داخلی، زمان build و ریسک regression هم بیشتر می‌شود.

Micro-Frontend چیست؟

در معماری Micro-Frontend، فرانت‌اند به بخش‌هایی تقسیم می‌شود که تیم‌های مختلف می‌توانند آن‌ها را مستقل توسعه دهند و در صورت پشتیبانی معماری، جداگانه منتشر کنند. اتصال این بخش‌ها می‌تواند از طریق route، اپلیکیشن shell، Web Components، iframe یا بارگذاری ماژول در زمان اجرا انجام شود. این روش‌ها یکسان نیستند و از نظر isolation، تجربه کاربری، عملکرد و انتشار تفاوت دارند.

چه زمانی Micro-Frontend ارزش دارد؟

• چند تیم مالک دامنه‌های تجاری متمایز هستند و به استقلال واقعی در انتشار نیاز دارند.
• بخش‌های مختلف چرخه انتشار یا محدودیت‌های legacy متفاوتی دارند.
• هماهنگی تیم‌ها و وابستگی انتشارها به یکدیگر، گلوگاه قابل‌اندازه‌گیری است.
• سازمان منابع لازم برای ابزارهای پلتفرم، مانیتورینگ، قراردادهای integration و استانداردهای تجربه کاربری را دارد.

هزینه‌هایی که نباید دست‌کم گرفت

• عملکرد و runtime: تکرار dependencyها، درخواست‌های بیشتر و کندشدن navigation در صورت طراحی ضعیف.
• یکپارچگی تجربه: تفاوت در design system، دسترس‌پذیری، loading و error state.
• اتصال بخش‌ها: routing، احراز هویت، analytics، منوی مشترک و جریان‌های کاری بین دامنه‌ها به قرارداد مشخص نیاز دارند.
• عملیات: pipelineهای بیشتر، مدیریت نسخه، مانیتورینگ و سناریوهای خرابی پیچیده‌تر.
• تست: تست واحد کافی نیست؛ integration test و تست end-to-end باید محصول نهایی را هم بررسی کنند.

استقلال در انتشار یک قابلیت است، نه نتیجه رایگان تقسیم اپلیکیشن. اگر هر انتشار همچنان به هماهنگی هم‌زمان همه تیم‌های فرانت‌اند نیاز دارد، ممکن است پیچیدگی یک سیستم توزیع‌شده را اضافه کرده باشید، بدون اینکه استقلال واقعی به دست آورید.

اول Modular Monolith را بررسی کنید

Modular Monolith یک اپلیکیشن قابل‌انتشار دارد، اما مرزهای داخلی آن قوی و مشخص هستند. برای بسیاری از محصولات، این نقطه تعادل مناسبی است: نگهداری ساده‌تر از یک فرانت‌اند توزیع‌شده و توسعه‌پذیرتر از یک کدبیس به‌شدت به‌هم‌وابسته.

در React یا Next.js بهتر است کد را بر اساس دامنه تجاری سازمان‌دهی کنید، نه صرفاً نوع فایل:

src/
  app/                 # routing و ترکیب صفحات
  features/
    billing/
      components/
      api/
      model/
      tests/
    claims/
      components/
      api/
      model/
      tests/
  shared/
    ui/
    lib/
    types/

کد مختص هر دامنه را داخل همان feature نگه دارید. import بین featureها باید آگاهانه باشد. کامپوننت واقعاً مشترک را در لایه design system قرار دهید، نه اینکه هر کدی را صرفاً به‌خاطر استفاده در دو محل به پوشه عمومی shared منتقل کنید. قراردادهای API را در مرزها تعریف کنید و اجازه ندهید هر feature مستقیماً state داخلی feature دیگر را تغییر دهد.

چک‌لیست تصمیم‌گیری

• مونولیت را انتخاب کنید اگر یک تیم می‌تواند تغییرات را هماهنگ کند و محصول از جریان‌های کاری مشترک سود می‌برد.
• Modular Monolith را انتخاب کنید اگر کدبیس در حال رشد است اما هنوز نیاز اثبات‌شده‌ای به انتشار مستقل ندارید.
• Micro-Frontend را بررسی کنید اگر تیم‌های مستقل به مرزهای دامنه پایدار نیاز دارند و سازمان می‌تواند هزینه پلتفرم را بپردازد.

قبل از جداکردن اپلیکیشن، با شواهد به این پرسش‌ها پاسخ دهید:

1. تیم‌ها چند بار به‌دلیل یکدیگر در انتشار متوقف می‌شوند؟
2. کدام دامنه‌ها مالک مشخص و جریان کاری مشترک کمی دارند؟
3. آیا هر فرانت‌اند پیشنهادی بدون هماهنگی انتشار سراسری قابل تست و انتشار است؟
4. بودجه JavaScript، تعداد درخواست‌ها، زمان شروع و navigation چقدر است؟
5. مسئول احراز هویت مشترک، منو، design tokenها، telemetry و دسترس‌پذیری چه کسی است؟
6. اگر یکی از فرانت‌اندها از کار افتاد، برنامه rollback و حالت محدودشده چیست؟

اگر Micro-Frontend را انتخاب کردید

با یک دامنه کم‌ریسک و مشخص شروع کنید، نه با بازنویسی یک‌باره کل سیستم. پیش از انتقال ترافیک production، مالکیت، قراردادهای اتصال، قوانین نسخه‌بندی، سیاست design system، مانیتورینگ و rollback را تعریف کنید. نتیجه را با معیارهایی مثل زمان تحویل، استقلال انتشار، نرخ رخداد، عملکرد صفحه و میزان هماهنگی تیم بسنجید؛ نه با تعداد bundleهای مستقل.

Monorepo چه نقشی دارد؟

Monorepo یک راهبرد مدیریت repository است، نه معماری فرانت‌اند. می‌توانید هم یک اپلیکیشن مونولیت و هم چند Micro-Frontend را در یک repository نگه دارید. ابزارهای workspace و task runner می‌توانند مدیریت dependency و cache ساخت را بهتر کنند، اما به‌تنهایی مرزهای دامنه درست ایجاد نمی‌کنند.

جمع‌بندی

با ساده‌ترین معماری‌ای شروع کنید که با مرزهای فعلی تیم شما سازگار است. یک Modular Monolith با مالکیت روشن و قوانین وابستگی بسازید. فقط وقتی به Micro-Frontend بروید که استقلال انتشار یک نیاز واقعی سازمانی باشد و منفعت آن از هزینه runtime و عملیات بیشتر شود. معماری باید گلوگاه‌ها را حذف کند، نه اینکه آن‌ها را از کد به زیرساخت منتقل کند.