دل کندن از یک سیستم یکپارچه قدیمی شبیه به باز کردن کلاف سردرگمی است که سال‌ها پیچیده شده است. وقتی یک نرم‌افزار به دلیل رشد روزافزون کسب‌وکار از ساختار سنتی خود بزرگ‌تر می‌شود، هزینه‌های هماهنگی میان تیم‌های توسعه به‌شدت افزایش می‌یابد و اینجاست که نیاز به تغییر معماری خودنمایی می‌کند. این فصل با بررسی یک مطالعه موردی واقعی نشان می‌دهد که چگونه یک پلتفرم بزرگ توانسته است از یک اپلیکیشن تک‌صفحه‌ای مونولیت به دنیای میکروفرانت‌اند مهاجرت کند بدون اینکه چرخ دنده‌های کسب‌وکار متوقف شوند. مهاجرت از مونولیت هرگز یک پروژه از پیش‌ساخته نیست؛ بلکه نیازمند استراتژی دقیقی است که میان جاه‌طلبی فنی و ثبات محیط پروداکشن تعادل برقرار کند. بدون یک نقشه راه مشخص، تیم‌ها در چرخه‌ای از بازنویسی‌های بی‌پایان گرفتار می‌شوند در حالی که انتشار ویژگی‌های جدید متوقف شده است. بررسی زمینه پلتفرم نشان می‌دهد که تیم‌ها به دلیل وابستگی‌های شدید به یک پایگاه کد واحد، سرعت خود را از دست داده‌اند. برای رفع این مشکل، گروه کاری مهندسی اهداف فنی خود را روی خودمختاری تیم‌ها و قابلیت دیپلوی مستقل متمرکز کرد و در نهایت تصمیم گرفت معماری میکروفرانت‌اند را بر اساس مرزهای دامنه کسب‌وکار پیاده‌سازی کند. شکستن SPA قدیمی نیازمند تحلیل داده‌های واقعی رفتار کاربران است تا اطمینان حاصل شود که مرزهای زیردامنه بر اساس نیاز واقعی شکل می‌گیرند نه فرضیات ذهنی. انتخاب تکنولوژی مناسب شامل گذار از الگوهای قدیمی به رویکرد برنامه‌نویسی واکنشی با استفاده از ری‌اکت بود که ترکیب وضعیت را در یک محدوده مشخص تسهیل می‌کند. استراتژی پیاده‌سازی بر اساس برش عمودی استوار است؛ یعنی اپلیکیشن شل در هر لحظه فقط یک میکروفرانت‌اند را بارگذاری می‌کند و نیاز به توافقات پیچیده نام‌گذاری میان تیم‌ها را از بین می‌برد. راه‌اندازی اپلیکیشن و مسیریابی به صورت سمت کاربر توسط اپلیکیشن شل مدیریت می‌شود که باز کردن عمیق لینک‌ها و نگاشت مسیرها را به شکلی روان هندل می‌کند. ارتباط میان بخش‌های مختلف از طریق فضای ذخیره‌سازی مرورگر و با واسطه‌های مشخص انجام می‌شود. برای یکپارچه‌سازی بک‌اند و احراز هویت، سیستم از جریان‌های موجود استفاده می‌کند، هرچند ذخیره توکن‌ها در حافظه محلی خطرات حملات اسکریپت‌نویسی بین سایت‌ها را به همراه دارد که باید مدیریت شوند. تصمیمات زیرساختی با استفاده از شبکه تحویل محتوا و توابع لبه اجرا می‌شوند تا الگوی خفه کننده برای هدایت تدریجی ترافیک پیاده‌سازی گردد. مدیریت وابستگی‌ها، سیستم طراحی و اشتراک‌گذاری کامپوننت‌ها مستلزم برقراری تعادل میان استقلال تیم‌ها و ثبات بصری است. علاوه بر این، پیاده‌سازی انتشار قناری در لبه شبکه به تیم‌های مهندسی اجازه می‌دهد نسخه‌های جدید را روی بخش کوچکی از ترافیک کاربران به صورت امن آزمایش کنند، در حالی که سرویس‌های تخصصی بومی‌سازی مدیریت زبان‌های مختلف را به عهده دارند. بده‌بستان‌های معماری | بعد فنی | رویکرد مونولیت | رویکرد میکروفرانت‌اند | | --- | --- | --- | | دیپلوی | چرخه انتشار وابسته و یکپارچه | انتشار مستقل برای هر زیردامنه | | استقلال تیم | سربار هماهنگی بسیار بالا | دامنه‌های ایزوله و سرعت مستقل | | حجم اولیه | یک فایل بهینه‌شده واحد | احتمال تکرار کدهای کتابخانه‌های مشترک | [ ] طراحی یک اپلیکیشن شل سمت کاربر با قابلیت مسیریابی پویا و بارگذاری قطعات [ ] پیاده‌سازی الگوی خفه کننده در لبه زیرساخت با استفاده از توابع بدون سرور [ ] ایجاد یک سیستم طراحی سبک برای حفظ ثبات بصری در میان تیم‌های مستقل [ ] پیکربندی منطق انتشار قناری با استفاده از تقسیم ترافیک و کوکی‌های کاربر [ ] مهاجرت امن توکن‌های احراز هویت و رفع خطرات امنیتی فضای ذخیره‌سازی محلی
