Native Federation – Deep Dive – Part 1/8 – مدل ذهنی، چرا فدراسیون بومی وجود دارد و چه چیزی در نسخه 4 تغییر کرده است

قسمت 1 از یک سری 8 قسمتی در Native Federation – Deep Dive.

🤖 توجه در مورد این مقاله: من از Claude برای قالب بندی مجدد و ساختار محتوا استفاده کردم تا آن را برای ارسال واضح تر و قابل ارائه تر کنم.

اگر یک سیستم میکرو فرانت‌اند تولیدی را به فدراسیون ماژول وب پک ارسال کرده‌اید، از قبل مدل ذهنی آن را می‌شناسید: میزبان یک برنامه با تنبلی کدی را که هرگز در زمان کامپایل ندیده است از a بارگیری می کند از راه دور مالک نیست و هر دو مذاکره می کنند وابستگی های مشترک در زمان اجرا، بنابراین سه نسخه از React را از طریق سیم ارسال نکنید. فدراسیون بومی این مدل را اختراع نکرد، بلکه آگاهانه آن را به ارث برد، زیرا این مدل هرگز مشکل ساز نبود. را عملکرد بود.

این مقاله به شما یاد نمی دهد که ریموت چیست. این توضیح خواهد داد که چرا ارزش ساخت یک اجرای کامل دوم از همان مدل ذهنی را دارد، چه بدهی ساختاری را پرداخت کرد، و چه چیزی را بازنویسی v4 در مورد اینکه پروژه و مدل به کجا می‌برد به ما می‌گوید. هر چیزی که در این مجموعه دنبال می‌شود (هسته، آداپتورها، ارکستراتور، دریفت نسخه، مهاجرت) در پایین‌دست استدلال این مقاله است، بنابراین ارزش آن را دارد که قبل از پرداختن به هر زیرسیستم، توضیح داده شود.

مصالحه ای که هیچ کس از آن صحبت نمی کند

فدراسیون ماژول Webpack از نظر فنی قابل توجه است. پیوند پویا برنامه های مختلف را در ابزاری که هرگز برای آن طراحی نشده بود، حل کرد و هر ماژول فدرال را در یک کانتینر زمان اجرا و یک لایه مذاکره قرار داد که پک وب از طرف شما مدیریت می کند. کار می کند. هزاران سیستم تولید ثابت می کنند که کار می کند.

اما کار می کند در جهان وب پک. هر کنترل از راه دور، هر میزبان، هر مرحله ساخت در این معماری توسط زمان اجرا ماژول بسته وب خودش – منطق رزولوشن خودش، لودر تکه‌ای خودش، قالب کانتینر خودش، واسطه می‌شود. این انتقادی به اجرا نیست. این تاییدی است بر مشکلی که پک وب در هنگام معرفی Module Federation در حال حل آن بود: چگونه بارگذاری پویا، از راه دور و زمان اجرا را در بسته ای مدرن کنیم که ارزش کلی آن عبارت است از ایستا تجزیه و تحلیل وابستگی زمان ساخت؟ مدل ظرف یک مصالحه ضروری است.

مصالحه بهایی دارد و اگر فدراسیون ماژول را در مقیاس بزرگ اجرا کرده باشید، آن را پرداخت کرده اید:

• قاب لایه ابزار را قفل کنید. میزبان شما و هر کنترل از راه دور به طور ضمنی به عنوان قرارداد پیاده سازی به وب پک (یا بسته سازگار با وب پک) در طول عمر سیستم فدرال متصل هستند. است قرارداد اجرای وب پک
• یک سیستم مدولار موازی که در کنار سیستم واقعی زندگی می کند. این مرورگر سیستم ماژول مخصوص به خود را دارد – ES Modules – که در سال‌های اخیر به شدت تکامل یافته است. فدراسیون ماژول از آن استفاده نمی کند. وضوح و منطق بارگذاری خود را در بالای بسته وب ایجاد می کند.
• اصطکاک مهاجرت که پیچیده می شود. انتقال هاست به خارج از بسته وب – به Vite، esbuild، به هر نوع ارسال بعدی – به معنای کشیدن زمان اجرای Module Federation به عنوان وابستگی به ابزاری است که می‌خواهید آن را ترک کنید، یا معماری مجدد لایه فدراسیون خود را به عنوان بخشی از مهاجرت بسته. دو مشکل دشوار مرتبط

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

چه «مرورگر بومی» واقعاً شما را می خرد.

شرط اصلی فدراسیون بومی ساختاری است: به جای ساختن یک پروتکل کانتینر در بالای زمان اجرای بسته، مستقیماً روی ماژول های ECMAScript و وارد کردن نقشه ها – هر دو استانداردهای وب هستند که مرورگر قبلاً آنها را پیاده‌سازی کرده است، بدون اینکه زمان اجرا بسته‌ای واسطه بارگذاری شود.

به طور خاص، این به این معنی است:

• ماژول کنترل از راه دور در معرض یک ماژول ES اصلی است که به عنوان اصلی ارائه می شود .js فایل قابل واردات با دینامیک واقعی import().
• تفکیک وابستگی مشترک از طریق مرورگر انجام می شود یک نقشه وارد کنید مکانیزم – یک ساختار JSON که به مرورگر می‌گوید «زمانی که کد درخواست می‌کند react، آن را حل کنید این URL’ – به جای یک محیط اشتراک گذاری ایجاد شده توسط بسته.
• کار ابزار ساخت به کاری خلاصه می شود که یک ابزار ساخت باید انجام دهد: تولید خروجی مطابق با استانداردها و آشکار (remoteEntry.json، توصیف آنچه در معرض دید و آنچه به اشتراک گذاشته می شود. مسئولیت آن متوقف می شود چگونه مرورگر ماژول ها را در زمان اجرا حل می کند، زیرا مرورگر از قبل می داند که چگونه این کار را انجام دهد.

این قسمتی است که به راحتی به عنوان “فقط یک جزئیات پیاده سازی” فروخته می شود، اما برای یک تیم معماری، این موضوع اصلی است: بسته قابل تعویض می شود. Native Federation یک آداپتور esbuild مرجع و – بیشتر از همه – یک آداپتور Angular ارائه می‌کند که مستقیماً به Application Builder مبتنی بر esbuild خود Angular متصل می‌شود، اما قرارداد اصلی (ESM + نقشه‌های واردات + مانیفست JSON) به هیچ یک از این موارد نیاز ندارد. ابزار ساخت را تعویض کنید، قرارداد فدراسیون را حفظ کنید. این در مورد فدراسیون مدولار مبتنی بر کانتینر صادق نیست، و تنها بزرگترین دلیل برای در نظر گرفتن این راه حل به عنوان یک راه حل زیرساخت، صرف نظر از چارچوب فعلی و انتخاب بسته شما است – نه فقط یک راحتی برای اکوسیستم Angular.

چرا این در نسخه 4 مهمتر از نسخه 3 است

Native Federation خیلی قبل از نسخه 4 وجود داشت، تا حد زیادی به عنوان یکی از ویژگی‌های اکوسیستم پلاگین Angular CLI – واقعاً مفید است، اما از نظر سازمانی همچنان به عنوان “چیزی هوشمند ساخته شده توسط تیم Angular Architects برای کاربران Angular”. v3 ثابت کرد که مدل ESM/import-map در تولید کار می کند.

v4 بازنویسی است که این ادعا را معتبر می کند، و شواهد یک آیتم فهرست تغییر نیستند – بلکه سازمانی هستند. پروژه از اصل بیرون آمد angular-architects/module-federation-plugin monorepo به طور کامل و اکنون تحت سازمان GitHub خود زندگی می کند، که به مخازن نسخه مستقل تقسیم شده است: چارچوب و بسته آگنوستیک هسته، اختصاص داده شده است آداپتور esbuild، اختصاص داده شده است آداپتور زاویه، و به طور جداگانه نگهداری می شود ارکستراتور برای مصرف در حین کار

این یک تغییر ساختار آرایشی نیست. این تفاوت بین “پلاگین با ماژول های داخلی” و “پلتفرم با قراردادهای منتشر شده بین لایه های آن” است. هنگامی که یک ابزار ساخت، یک آداپتور چارچوب و یک مصرف کننده زمان اجرا سه مصنوع با نسخه های جداگانه به جای سه فایل در یک بسته هستند، باید یک سوال معماری بسیار واضح تر در مورد هر بخش معینی از سیستم بپرسید: این لایه چه چیزی را به لایه بالای آن وعده می دهد و چه چیزی را می توانم بدون شکستن آن معامله کنم؟ در دو مقاله بعدی به طور خاص برای هر لایه به این سوال پاسخ خواهیم داد.

سیگنال ساختاری دیگری در نسخه 4 که اکنون قابل ذکر است زیرا در این سری تکرار می شود: این پروژه به صراحت خود را به سمت پشتیبانی درجه یک برای چارچوب های فراتر از Angular و مصرف زمان اجرا توسط محیط هایی که اصلاً برنامه های تک صفحه ای نیستند قاب بندی می کند – صفحات HTML ساده و میزبان های رندر شده توسط سرور در اکوسیستم متفاوتی که دارای قرارداد هستند. Angular امروز با اختلاف زیادی بالغ‌ترین آداپتور باقی مانده است، و این سری به بررسی آن می‌پردازد زیرا ابزارهایی برای تولید آماده هستند – اما سقف معماری دیگر یک “چیز زاویه ای” نیست. این سقف زمانی مهم است که روی یک پلتفرم شرط بندی پنج ساله انجام می دهید، نه فقط تصمیم برای تحویل سه ماهه بعدی.

سری نقشه راه

این یک سری 8 قسمتی است و هر مقاله بر اساس موارد قبل است. در اینجا طرح کامل و جایگاه ما در حال حاضر آمده است:

1. مدل ذهنی مورد بازبینی قرار گرفت – چرا فدراسیون بومی وجود دارد و چه چیزی در نسخه 4 تغییر کرده است (این مقاله)
2. آناتومی گرافیک بسته v4 – هسته، آداپتورها، زمان اجرا، و ارکستراتور به عنوان لایه‌های مستقل
3. زمان ساختن، پایان به پایان – کتابخانه Core و آداپتورهای آن و آنچه که در واقع با کد شما انجام می دهند
4. زمان اجرا کلاسیک – او چه کاری را درست انجام می دهد و کجا به سقف خود می زند
5. ارکستر – وضوح Semver-aware و حافظه پنهان مداوم، در زیر هود
6. استراتژی برای جابجایی نسخه ها و حل مشکلات – مشکل مدیریتی که هیچ کس در ساخت خط لوله متوجه آن نمی شود
7. نسخه 3 در مقابل 4 – مقایسه سیستماتیک و کتاب واقعی در مورد مهاجرت
8. معماری مرجع – اجرای Native Federation v4 در یک شرکت تحت نظارت

ماده 2 بعدی است: بازسازی سازمانی شرح داده شده در بالا را جدی می گیرد و نمودار دسته ای واقعی را ترسیم می کند تا بدانید دقیقاً کدام لایه را لمس می کنید و چه وعده هایی را به لایه های اطراف خود می دهد قبل از اینکه ما به هر کدام بپردازیم.

بعدی در این سری: **آناتومی گرافیک بسته v4* — نقشه برداری از هسته، آداپتورها، زمان اجرا کلاسیک، و ارکستراتور به عنوان لایه های مستقل و با قراردادهای صریح بین آنها.