فهرست مندرجات[پنهان شدن][نمایش]
ایده ریزسرویس ها اخیراً توجه زیادی را به خود جلب کرده است و بسیاری از شرکت ها از آن برای حذف باطن های بزرگ و یکپارچه استفاده می کنند.
رفتن به همان مسیر با فرانت اند هنوز برای بسیاری از مشاغل چالش برانگیز است، حتی اگر این شیوه توزیع شده ساخت سمت سرور برنامه های وب کم و بیش از نظر تحقیق و اجرا قابل اعتماد باشد.
به دلیل وابستگی نزدیک آن، یکپارچه سمت مشتری معمولاً ادغام ویژگیهای جدید، پذیرش فناوریهای جدید و مقیاسبندی اجزای جداگانه را دشوار میکند.
این چالشها و چالشهای دیگر، توسعهدهندگان فرانتاند را بر آن داشته است تا با استفاده از میکروسرویسها، تحقیق کنند.
در نتیجه، یک استراتژی معماری کاملاً جدید به نام micro frontend برای ایجاد لایه جلویی وب سایت ها و برنامه های کاربردی مبتنی بر وب توسعه داده شد.
این اصطلاح برای اولین بار در سال 2016 مورد استفاده قرار گرفت و از آن زمان تاکنون توجه زیادی را به یک دلیل خوب به خود جلب کرده است.
این مقاله یک درک کلی از چیستی فرانتاندهای کوچک و مسائلی که به آنها میپردازد ارائه میکند. آن کار می کند، و همچنین جوانب مثبت و منفی.
مقدمه ای بر معماری micro front-end
یک روش معاصر توسعه front-end به نام معماری micro-frontend a برنامه های تحت وب به قطعات کوچک و مستقل
برای کاربر نهایی، این قطعات به نظر یک واحد هستند حتی اگر به طور مستقل ساخته شده و سپس در کنار هم قرار گیرند.
با این تفاوت که فرانتاندهای میکرو به سمت مشتری مربوط میشوند، نه سمت سرور، راهحلهای آنلاین، منطق زیربنای آنها با خرد سرویسها یکسان است.
ساخت محصولات پیچیده مبتنی بر وب در هنگام استفاده از رویکرد micro frontend بسیار منطقی است.
Micro frontends، برخلاف یک front-end یکپارچه معمولی تر، بسیاری از تیم ها را قادر می سازد تا به طور جداگانه در پروژه های نرم افزاری مختلف با یکدیگر همکاری کنند.
برنامه نویسان می توانند با استفاده از این طرح معماری سریعتر و با مقیاس پذیری و نگهداری بیشتر برنامه های وب ایجاد کنند.
به بیان ساده، هر micro frontend فقط یک قطعه کد برای یک جزء مجزا از صفحه وب است.
این ویژگی ها توسط تیم های جداگانه ای کنترل می شوند که هر کدام در یک صنعت یا هدف خاص تخصص دارند.
معماری Monolithic در مقابل Microservices در مقابل Micro Frontend
به نقل مکان فکر کنید. آیا برای شما ساده تر خواهد بود که همه چیز را در تعدادی جعبه کوچک با برچسب ماهرانه سازماندهی کنید و هر کدام را به صورت جداگانه جابجا کنید یا کل کارکنان را در یک جعبه عظیم جمع کنید و به مکان جدیدی منتقل کنید؟
راه حل واضح وجود دارد.
این قیاس دو معماری متمایز اپلیکیشن وب، یکپارچهها و ریزسرویسها (همچنین به عنوان micro frontends شناخته میشوند) را مقایسه میکند.
معماری یکپارچه
ممکن است بتوانید «روزهای خوب قدیمی» را به یاد بیاورید، زمانی که یک برنامه کامل به عنوان یک موجودیت واحد و منسجم ایجاد شد. چنین روشی یکپارچه نامیده می شود که یک اصطلاح قدیمی برای یک بلوک سنگی بزرگ است.
این منطقی است.
سیستم های یکپارچه دارای عناصر وابسته به یکدیگر هستند. بنابراین، اگر میخواهید چیزی را تغییر دهید یا یک ویژگی جدید اضافه کنید، ممکن است کل سیستم خراب شود.
اگرچه منسوخ شده است، اما گاهی اوقات هنوز وجود دارد. بله، ما از بیان فعلی شما آگاه هستیم.
با توسعه فناوریهای جدید و پیچیدهتر شدن محصولات نرمافزاری، تقسیم مفهومی پایگاه کد به دو جزء مختلف - جلویی (سمت مشتری) و باطن (سمت سرور) - اجتنابناپذیر شد.
محبوبترین روش کار اکنون جداسازی نگرانیها بین لایه ارائهای است که کاربر نهایی با آن تعامل دارد و هر چیزی که در پسزمینه اتفاق میافتد.
به دو تیم مهندسی نرمافزار نیاز دارد که تیم جلویی سازنده اجزای بصری و تیم پشتیبان ساخت سرویسهای وب، منطق تجاری، دسترسی به دادهها، ادغام و غیره است.
با این حال، با وجود این جدایی، این استراتژی همچنان ذاتاً یکپارچه باقی مانده است.
تغییر اصلی این است که ما اکنون به جای یک برنامه عظیم، دو بلوک کد قابل توجه داریم - فرانت اند و باطن. معماری های یکپارچه نباید وحشتناک باشند. آنها چند مزیت دارند، از جمله
- توسعه ساده و سریع برای برنامه های کاربردی کوچک با یک کد منبع واحد و طراحی بسیار ساده.
- آزمایش و اشکال زدایی بسیار ساده است زیرا همه کدها در یک مکان قرار دارند و ردیابی جریان درخواست و شناسایی اشکالات را برای یک تیم آسان تر می کند.
- در اوایل توسعه یک برنامه، هزینه ها ارزان تر می شوند زیرا نه هزینه های زیرساختی و نه هزینه های توسعه تا زمانی که ویژگی های جدید اضافه شوند متحمل نمی شوند.
اشکالات این استراتژی در منعکس شده است
- انعطاف پذیری استقرار محدود - تیم ها باید منتظر بمانند اگر تعداد انگشت شماری از آنها روی پروژه کار می کنند و هر بار که کد را به روز می کنید، به استقرار جدید نیاز است.
- پذیرش فناوری های جدید چالش برانگیز است زیرا انجام این کار مستلزم بازنویسی بخش قابل توجهی، اگر نه کل پروژه است.
- هنگامی که تعداد توسعه دهندگان افزایش می یابد، یک سیستم کد ارتباط نزدیک، پیچیده، و مدیریت و درک آن دشوار می شود.
- مسائل سازمانی - هر یک از اعضای تیم باید از نسخه مشابهی از کتابخانه ها استفاده کند و اگر تیم های زیادی روی یک پروژه یکپارچه کار می کنند، هرگونه تغییر را گزارش کنند.
- نگرانی های مربوط به مقیاس پذیری - از آنجایی که اجزای پروژه به هم مرتبط هستند، مقیاس بندی آنها به طور جداگانه مشکلاتی را ایجاد می کند که منجر به خرابی قابل توجه و هزینه های بالاتر می شود.
- درک منطق پیچیده پروژه برای اعضای تیم جدید دشوار است، به خصوص اگر مهندسانی که در ابتدا روی آن کار می کردند دیگر استخدام نشوند.
توسعه میکروسرویس ها و خویشاوندان نزدیک آنها، و فرانت اندهای خرد، به مشکلات اولیه سیستم های یکپارچه پرداختند.
معماری میکروسرویس ها
روش معماری که به عنوان میکروسرویس شناخته میشود، امکان ایجاد بسیاری از مؤلفهها یا سرویسهای کوچکتر با پیوند آزاد و مستقل را فراهم میکند که یک برنامه کاربردی را تشکیل میدهند.
هر سرویسی پایگاه کد، خطوط لوله CI/CD، رویههای DevOps و فرآیندهایی برای اجرای آنها دارد.
با مشاهده تصویر بالا می توانید ببینید که تیم باطن یکپارچه به تیم های جداگانه تقسیم شده است.
هر کدام به صورت جداگانه بر روی جنبه های مختلف برنامه (مانند خدمات محصول، سرویس جستجو و خدمات پرداخت) تمرکز می کنند.
ارتباط بین سرویسها از طریق پروتکلهای ایجاد شده به نام API، مانند پروتکل سبک REST API که از الگوهای درخواست-پاسخ همزمان استفاده میکند، انجام میشود.
گزینه دیگر استفاده از ارتباطات ناهمزمان با استفاده از نرم افزارهایی مانند کافکا است که ساختارها و رویدادهای ارتباطی انتشار/اشتراک را ارائه می دهد.
میکروسرویس ها از طریق یک Backend برای سرویس Frontend (BFF) یا یک API Gateway از طریق شبکه با frontend یکپارچه می شوند. BFF یک API سفارشی برای هر مشتری ارائه می دهد، در حالی که API Gateways یک نقطه دسترسی واحد را برای مجموعه ای از میکروسرویس ها ارائه می دهد.
اما حتی با وجود اجزای بکاند مستقل و تمام مزیتهایی که ارائه میکنند، فرانتاند همچنان یکپارچه است.
بنابراین، این جایی است که micro frontends مفید هستند.
معماری Micro Frontends
مشابه میکروسرویسها، که در آن اجزای با پیوند آزاد توسط چندین تیم مدیریت میشوند، معماری micro frontend این مفهوم را در مرورگر اعمال میکند.
این رابط های کاربری برنامه های وب از این ساختار پیروی می کنند که از اجزای تا حدی مستقل تشکیل شده است.
تیم ها نیز بر اساس نیازهای مشتری یا موارد استفاده به جای تخصص یا فناوری خاص ایجاد می شوند.
در نتیجه، تیمها در پروژههای میکروسرویس و خرد مشارکت دارند.
- به صورت عمودی - از آنجایی که توسعه دهندگان فرانت اند، متخصصان داده، مهندسان باطن، مهندسان QA و غیره نیز روی همان پروژه کار می کنند، ویژگی های خود را از رابط کاربر به پایگاه های داده؛ و
- متقابل - هر یک از اعضای تیم تخصص خود را به گروه کمک می کند.
تیمها همچنین میتوانند پشته فناوری را انتخاب کنند که به بهترین وجه با خط خاص کسبوکارشان سازگار است.
یک تیم می تواند از React برای برنامه ریزی قطعه خود استفاده کند. تیم دیگری یک نسخه Angular جدید ایجاد می کند. Vue.js یکی از این نمونه هاست.
فرانتاندهای میکرو همراه با میکروسرویسهای مرتبط برای رسیدگی به مشکلاتی که تیمهای توسعه معمولاً با یکپارچهها دارند، استفاده میشوند. این استراتژی مزایای زیر را ارائه می دهد.
- آزادی فناوری: مهندسان Frontend میتوانند چارچوبهای جاوا اسکریپت، محیطهای زمان اجرا و کل پشتههای فناوری را بسته به نیاز شرکت انتخاب کنند. در بالای معماری قدیمی، یک چارچوب جدید ممکن است اعمال شود.
- درجه بیشتری از انعطاف پذیری امکان پذیر است زیرا هر فروند میکرو مستقل است و می توان آن را به طور جداگانه توسعه، آزمایش، استقرار و ارتقا داد. در نتیجه، اگر یک تیم روی یک ویژگی کار می کند و یک باگ را رفع کرده است، و تیم دیگری باید ویژگی خود را اضافه کند، نیازی نیست منتظر بمانند تا اولین تیم کار خود را انجام دهد.
- تیمها و سیستمهای مستقل: هر تیم محصول، و در نتیجه هر ویژگی، میتواند با وابستگی کمی به دیگران کار کند، که آن را قادر میسازد حتی زمانی که اجزای نزدیک در دسترس نیستند به کار خود ادامه دهد.
- پایگاههای کد چندگانه کوچکتر: هر یک از فرانتاندهای کوچک، پایگاه کد کوچکتر، قابل مدیریتتر و کوچکتری دارند. افراد کمتری بر روی یک مؤلفه UI خاص تمرکز می کنند، بررسی کد را ساده می کنند و سازماندهی کلی را بهبود می بخشند.
- مقیاسبندی ساده اپلیکیشن: یکی دیگر از مزایای میکرو فرانتاند، توانایی مقیاسبندی هر ویژگی بهصورت جداگانه است. برخلاف یکپارچهها، که در آن کل برنامه باید هر بار که یک ویژگی جدید اضافه میشود، مقیاسبندی شود، این باعث میشود کل فرآیند از نظر زمان و هزینه کارآمدتر شود.
micro frontend چگونه کار می کند؟
همانطور که قبلاً بیان کردیم، تیم ها به صورت عمودی در معماری micro frontend سازماندهی می شوند، به این معنی که آنها با دانش یا هدف دامنه از هم جدا شده اند و از ابتدا تا انتها برای یک محصول خاص مسئول هستند.
این می تواند یک یا دو میکروسرویس پشتیبان و همچنین یک فرانت اند کوچک داشته باشد. با جزئیات بیشتر، بیایید ویژگیهای این عنصر بصری، تعامل با سایر اجزای UI، و ادغام آن در صفحه اصلی را بررسی کنیم.
یک فروند میکرو می تواند باشد
- یک صفحه کامل (به عنوان مثال، یک صفحه جزئیات محصول) یا
- بخش هایی از صفحه که می توانند توسط تیم های دیگر استفاده شوند، مانند سرصفحه ها، پاورقی ها و نوارهای جستجو.
میتوانید یک وبسایت بزرگ را به چند نوع صفحه تقسیم کنید و هر نوع را در اختیار کارکنان خاصی قرار دهید تا روی آن کار کنند.
با این حال، چندین مؤلفه اغلب در صفحات متعددی مانند سرصفحه، پاورقی، بلوکهای پیشنهاد و غیره رخ میدهند. برای مثال، یک بلوک پیشنهاد میتواند در صفحه اصلی، صفحه جزئیات محصول یا حتی صفحه پرداخت قرار گیرد.
در اصل، تیم ها می توانند قطعاتی ایجاد کنند که سایر تیم ها می توانند در صفحات خود از آنها استفاده کنند.
با این حال، بخشهای میکرو را میتوان بهعنوان پروژههای مختلف بهعنوان پروژههای مختلف بهجای اجزای قابل استفاده مجدد، مستقر کرد.
همه اینها فوق العاده به نظر می رسد، اما برای ایجاد یک رابط یکپارچه، صفحات و قطعات باید به نحوی با هم ترکیب شوند.
این نیاز به یکپارچه سازی frontend دارد، که می تواند از طریق انواع استراتژی ها، از جمله مسیریابی، ترکیب، و ارتباط انجام شود (نمودار بالا را ببینید).
مسیریابی
هنگامی که سرویس از صفحه ای که توسط یک تیم کنترل می شود برای دسترسی به صفحه متعلق به تیم دیگری مورد نیاز است، مسیریابی برای یکپارچه سازی در سطح صفحه مفید است.
هر فروند میکرو به عنوان یک برنامه تک صفحه ای مدیریت می شود. برای ارائه مسیریابی می توان از لینک های ساده HTML استفاده کرد.
کاربر می تواند مرورگر را وادار کند که نشانه گذاری هدف را از یک سرور دانلود کند و با کلیک بر روی لینک ها، صفحه فعلی را با صفحه جدید جایگزین کند.
پوسته برنامه حداقل HTML، CSS و جاوا اسکریپت است که یک UI را تقویت می کند. حتی اگر اطلاعات محتوای درخواست شده از سرور همچنان منتظر باشد، کاربر بلافاصله یک صفحه نمایش داده شده ثابت دریافت می کند. پوسته برنامه مرکزی به عنوان یک برنامه والد برای برنامه های تک صفحه ای ایجاد شده توسط تیم های مختلف عمل می کند.
مهم نیست از کتابخانه یا چارچوبی که استفاده میشود، متا فریمورکها امکان ادغام صفحات مختلف را در یک صفحه واحد فراهم میکنند.
ترکیب
ترکیب بندی فرآیند چیدمان قطعات به منظور قرار دادن آنها در فضاهای مناسب در یک صفحه است. در بیشتر موارد، تیمی که صفحه را مستقر می کند بلافاصله محتوای قطعه را دریافت نمی کند.
در عوض، یک مکان یا نشانگر را در جایی قرار می دهد که قطعه باید در نشانه گذاری باشد.
با استفاده از فرآیند آهنگسازی متفاوت، مونتاژ نهایی انجام می شود. ترکیب را می توان به دو دسته اصلی تقسیم کرد: سمت مشتری و سمت سرور.
ترکیب سمت مشتری: مرورگر وب برای ایجاد و ویرایش نشانه گذاری HTML استفاده می شود. هر micro frontend قابلیت تغییر و نمایش نشانه گذاری خود را به طور جداگانه از بقیه صفحه دارد.
برای مثال، Web Components به شما امکان می دهد این نوع ساخت و ساز را انجام دهید.
برنامه این است که هر قطعه به یک مؤلفه وب تبدیل شود که می تواند به طور مستقل به عنوان یک فایل a.js نصب شود، پس از آن برنامه ها می توانند آنها را بارگذاری کنند و در فضاهای تعیین شده برای آنها در طرح زمینه بارگذاری کنند.
اجزای وب به HTML و DOM API وابسته هستند، که سایر فریم ورک های فرانت اند می توانند از آنها استفاده کنند، و همچنین به روش استاندارد ارسال و دریافت داده از طریق props و رویدادها.
ترکیب سمت سرور: با این طراحی، قطعات UI روی سرور ترکیب می شوند که منجر به ارسال یک صفحه کاملاً تشکیل شده به سمت مشتری می شود و سرعت بارگذاری را افزایش می دهد.
مونتاژ اغلب توسط یک سرویس جداگانه انجام می شود که بین مرورگر وب و سرورهای وب قرار می گیرد. CDN یکی از نمونه های سرویس (شبکه تحویل محتوا) است.
بسته به نیاز خود می توانید یکی یا ترکیبی از این دو را انتخاب کنید.
الگوهای ارتباطی Micro Frontend
معماری micro-frontend زمانی بهترین کار را انجام می دهد که بین اجزای مختلف تعامل کم یا بدون وجود داشته باشد. فرانتاندهای میکرو گاهی اوقات نیاز به صحبت با یکدیگر و به اشتراک گذاری اطلاعات دارند. در اینجا چند الگوی بالقوه است که ممکن است منجر به آن شود.
- کارگران وب: کارگر آنلاین مکانیزمی است که محتوای وب را قادر می سازد تا جاوا اسکریپت را مستقل از سایر اسکریپت ها و بدون تأثیر بر سرعت صفحه در پس زمینه اجرا کند. یک Worker API منحصر به فرد برای هر برنامه میکرو ارائه می شود. این مزیت این است که کار وقتگیر را میتوان در رشتههای مختلف انجام داد، و این امکان را میدهد که رشته UI بدون کند شدن یا توقف ادامه یابد.
- انتشار دهنده رویداد: در این حالت، بسیاری از مؤلفهها با گوش دادن به هر تغییر حالت در مؤلفههایی که در آنها مشترک شدهاند، با یکدیگر ارتباط برقرار میکنند. سایر میکرو فرانتاندهایی که در آن رویداد خاص مشترک شدهاند، هنگامی که یک فروند میکرو آن رویداد را اجرا میکند، پاسخ میدهند. انتشار دهنده رویدادی که در هر میکرو فرانتند معرفی شده است، این امر را امکان پذیر می کند.
- تماس های تلفنی و لوازم جانبی: در این قسمت کامپوننت والد و کامپوننت فرزند را تعریف می کنید. ارتباطات در یک ساختار درخت مانند سازماندهی شده است. مؤلفههای والد برای انتقال دادهها به عنوان توابع از درخت مؤلفه به مؤلفههای فرزند استفاده میکنند. به نوبه خود، کودک می تواند با پاسخ دادن به تماس ها، به طور موثر به والدین هشدار دهد که هر اتفاقی در وضعیت آنها رخ می دهد. React از این حالت استفاده می کند.
جوانب مثبت Micro frontend
توسعه در تیم های سریع خودمختار
یک تیم مستقل میتواند هر بخش از یک برنامه وب یا وبسایت را هنگام استفاده از روش micro frontend ایجاد کند.
هر تیم کاملاً مستقل است، به این معنی که مسئولیت کل چرخه توسعه مولفه، از مفهوم تا انتشار و پس از تولید را بر عهده دارد.
علاوه بر این، نشان می دهد که تیم های مختلف می توانند به طور یکپارچه در حالی که همزمان روی یک پروژه کار می کنند، همکاری کنند.
بنابراین، چرخه های انتشار به طور قابل توجهی سریعتر از آنها با یکپارچه های جلویی هستند.
پایگاههای کد کوچکتر میکرو فرانتاندهای فردی منجر به کد پاکتر میشوند
قسمتهای جلویی یکپارچه دارای پایههای کد بزرگ و غیرقابل انعطافی هستند که مدیریت آنها در طول زمان به طور فزایندهای آشفته و چالش برانگیز میشود.
فرانتاندهای میکرو این مشکل را برطرف میکنند. کد منبع هر micro frontend قابل مدیریت تر است زیرا کوچکتر، ساده تر و فشرده تر است.
به عنوان یک نتیجه، راه حل کلی وب از کد تمیزتر سود می برد.
بهبود پایداری برنامه به دلیل اتصال شل
یک راه حل وب به ندرت می تواند به قطعات کاملاً مستقل تقسیم شود. در نتیجه، فرانتاندهای کوچک با یکدیگر صحبت میکنند.
با این حال، هر پیوند بین اجزاء با وجود اتصال سست قابل توجه است.
خرابی یک مؤلفه تأثیر کمی بر عملکرد همه مؤلفههای دیگر دارد، که پایداری یک راهحل وب را افزایش میدهد.
آزمایش ویژگیهای فردی سادهتر شده است
این مزیت ناشی از ویژگی های micro frontend است. بر اساس این طراحی معماری، سمت مشتری یک راه حل وب ماژولار است و هر ماژول مستقل است.
در نتیجه، ارزیابی بخش کوچکی از رابط کاربری به تنهایی برای یک تیم آسانتر از آزمایش یک مونولیت عظیم است.
کاهش اندازه باندل منجر به بارگذاری سریعتر صفحه میشود
یکی از دلایل اصلی تاخیر در زمان بارگذاری در سیستم های وب یکپارچه غنی از ویژگی، اندازه یک بسته جاوا اسکریپت است. از طرف دیگر، رویکرد micro frontend کاهش زمان بارگذاری صفحه را آسان تر می کند.
یک مرورگر مجبور نیست کدهای غیر ضروری را به طور مکرر بارگیری کند زیرا یک صفحه وب از چندین بسته کوچک تشکیل شده است. در نتیجه عملکرد صفحه و زمان بارگذاری افزایش می یابد.
استقلال فناوری
چندین فریمورک های جلویی می تواند توسط توسعه دهندگان برای ایجاد یک راه حل آنلاین منفرد با معماری micro-frontend استفاده شود.
از آنجایی که هر جزء مستقل است، می توان آن را با استفاده از هر فناوری که به بهترین وجه برای وظایف تیم مناسب است، ساخت.
به طور طبیعی، برنامه نویسان باید در انتخاب چارچوب ها برای پروژه نرم افزاری که مسئولیت آن را بر عهده دارند، احتیاط کنند و مشاوره با سایر تیم ها همچنان به شدت توصیه می شود.
با این حال، احتمال اینکه مجبور شوید از یک چارچوب قدیمی برای طول عمر برنامه استفاده کنید، صفر است.
معایب Micro Frontend
آزمایش راه حل پیچیده وب به طور کامل
آزمایش ماژولهای مختلف راهحل وب زمانی که از معماری micro-frontend استفاده میکند، آسان است. با این حال، با ارزیابی یک برنامه وب به عنوان یک کل متفاوت است.
قبل از ادامه، بررسی کنید که همه قسمتها طبق برنامه عمل میکنند. این ممکن است دشوار باشد زیرا فرانتاندهای میکرو به طور مستقل عمل میکنند و فرآیندهای تحویل جداگانه دارند.
سرمایه گذاری های اولیه گران قیمت
توسعههای فرعی خرد معمولاً هزینههای مالی قابل توجهی را طلب میکنند. جمع آوری و نگه داشتن بسیاری از تیم های فرانت اند گران است.
علاوه بر این، برای سازماندهی کار، اطمینان از هماهنگی همه چیز و تضمین ارتباطات تیمی عالی، به پرسنل مدیریتی نیاز دارید.
پیچیدگی توسعه و استقرار
رویههای توسعه و استقرار میتوانند در نتیجه طراحی ریز جلوهای پیچیدهتر شوند.
به عنوان مثال، یک راه حل ممکن است توسط تیم های توسعه مستقلی که روی همان پروژه کار می کنند با اجزای بسیار زیادی پر شود، که می تواند در مرحله استقرار مشکلاتی ایجاد کند.
مونتاژ صحیح همه ماژول ها و ادغام صاف آنها در طرح کلی نیز همیشه ساده نیست. این کار معمولاً نیاز به درک کامل همه وابستگی ها دارد.
مشکلات حفظ انسجام در تجربه کاربر
هنگامی که تیم ها به طور جداگانه روی چندین بخش از نرم افزار کار می کنند، حفظ یک رابط کاربری ثابت چالش برانگیز است.
راه حل وب باید توسط همه توسعه دهندگان پروژه به اشتراک گذاشته شود. در غیر این صورت، تضادهای زیادی در طول جاده وجود دارد.
نتیجه
Micro frontends، یک طراحی معماری معاصر، می تواند عملکرد پروژه های توسعه وب مبتنی بر میکروسرویس در مقیاس بزرگ را تا حد زیادی افزایش دهد.
برنامه نویسان را قادر می سازد تا راه حل کامل را به بخش های مجزا تقسیم کنند که می تواند توسط چندین تیم مستقل ایجاد شود. مزایای متعددی از این امر به دنبال دارد، از جمله عرضه سریعتر ویژگی، آزمایش آسانتر ماژولهای جداگانه، و ارتقای یکپارچهتر.
اما برخی از مشکلات با فرانت اند های میکرو نیز وجود دارد.
به عنوان مثال، آزمایش جامع یک برنامه، می تواند چالش برانگیز باشد.
علاوه بر این، از آنجایی که تیم بزرگی از مهندسان و مدیران مورد نیاز است، پروژههای micro frontend بسیار گران هستند.
در نتیجه، قبل از تصمیم گیری، باید تمام اجزای پرونده تجاری خود را در نظر بگیرید.
ولادیمیر چاماج
به نوعی من متوجه نشدم که ارتباط بین اجزای جداگانه در قسمت جلویی بر اساس چه اصل کار می کند. من متوجه نمی شوم که چگونه می خواهید اجزایی را که در فریمورک های مختلف ایجاد شده اند به هم وصل کنید. در مقاله چیزی در مورد آن وجود ندارد. سیستم حوادث و شنوندگان برای من مانند جهنم روی زمین است. چگونه باید آن را تصور کنیم؟