نوشته های علی بدخشان

چگونه یک پیاده سازی واقعی به سبک Micro Frontends داشته باشیم-قسمت دوم

علی بدخشان — Mon, 30 Aug 2021 19:10:59 +0430

این قسمت دوم از این مطلب است. اگر قسمت اول را نخوانده اید توصیه میکنم حتما ابتدا آن را مطالعه کنیدچگونه یک پیاده سازی واقعی به سبک Micro Frontends داشته باشیم - قسمت اولدر قسمت اول درباره اینکه قرار است چه چیزی و چطور پیاده سازی شود صحبت کردم و در این قسمت به جزییات پیاده سازی خواهم پرداخت و با جزییات دقیق خواهم گفت که این مثال چگونه پیاده سازی شده است.در ابتدا بهتر است فریم ورک ها و کتابخانه هایی که در این پیاده سازی استفاده شده اند را معرفی کنم:Angularاین فریم ورک به عنوان فریم ورک اصلی هم برای پیاده سازی core این مثال و هم برای پیاده سازی اکثر app ها استفاده شده است. البته دو app هم توسط Vue.js توسعه داده شده و به کمک Custom element امکان قرار گرفتن در کنار app های دیگر را پیدا کرده اند. اگر می خواهید در مورد Angular بیشتر بدانید اینجا را مطالعه کنید.اگر می خواهید در مورد Vue.js بیشتر بدانید اینجا را مطالعه کنید.اگر می خواهید در مورد Custom elements بیشتر بدانید اینجا را مطالعه کنید.Webpack Module Federationاین یک plugin است که از نسخه 5 webpack رسما به آن اضافه شد و این امکان را به Webpack اضافه کرد که Webpack بتواند بین local module ها و remote module ها تمایز قائل شود. local module ها، ماژول هایی هستند که در زمان build در دسترس هستند و می توانند به صورت مستقیم در فرایند build مشارکت کنند اما remote module ها، ماژول هایی هستند که در زمان build در دسترس نیستند و در فرایند دیگری build شده و یا خواهند شد و اکنون تنها آن را به webpack معرفی می کنیم بدون اینکه اطلاعاتی در مورد آن داشته باشیم.(حتی در بسیاری از مواقع از جمله در مثال ما این معرفی هم در زمان اجرا صورت می‌گیرد). امیدوارم توضیحات مختصر من توانسته باشد دلیل اینکه این plugin چقدر می‌تواند برای توسعه سیستم های بر پایه Micro Frontends مفید باشد را روشن کرده باشد.Multiple separate builds should form a single application. These separate builds should not have dependencies between each other, so they can be developed and deployed individually. This is often known as Micro-Frontends, but is not limited to that.(https://webpack.js.org/concepts/module-federation/) اگر تمایل دارید بیشتر با آن آشنا شوید این مطلب را مطالعه کنید هر چند برای فهمیدن بهتر و کامل‌تر حتما لازم است مثالهای مربوطه را ببینید.Narik Micro Frontendsیک کتابخانه سبک بر پایه Angular که از آن برای مدیریت app ها، load و Initialize کردن آنها و دیگر موارد مشابه استفاده کرده ام. در نوشته های بعدی به صورت مفصل در مورد آن توضیح خواهم داد.در کنار این سه مورد اصلی از یک کتابخانه دیگر هم استفاده شده است. (@angular/builders) اما دلیل استفاده از این کتابخانه چیست؟ هر چند Angular در roadmap خود پشتیبانی از Micro frontends را در برنامه دارد اما در حال حاضر( نسخه 12) اعمال تنظیمات مربوط Module Federation در Webpack را به صورت مستقیم پشتیبانی نمی‌کند. برای این منظور می توان از امکانی که Angular برای سفارشی سازی فرایند build در اختیار توسعه دهندگان گداشته است استفاده کرد(Angular Cli Builder). کتابخانه های زیادی برای این منظور وجود دارد، حتی شما می‌توانید خودتان انواع سفارشی Builder را بنویسید، اما من برای این قسمت تصمیم گرفتم از این کتابخانه استفاده کنم.در ادامه مراحل پیاده سازی این مثال را با هم مرور می‌کنیم:برای شروع یک پروژه Angular ایجاد می‌کنیم.( اگر با این موضوع آشنا نیستید این مطلب را مطالعه کنید) پس از آن وابستگی های مورد نظرمان را اضافه می‌ کنیم. من برای این منظور از yarn استفاده می‌کنم. شما می‌توانید از yarn و یا npm استفاده کنید.yarn add @angular-builders/custom-webpack @narik/micro-frontends-infrastructure @narik/micro-frontends-core @narik/micro-frontends-ui @angular-architects/module-federationعلاوه بر وابستگی های بالا که مربوط به Micro Frontends هستند به دلیل اینکه در این مثال من از کامپوننت های Angular Material استفاده کرده‌ام لازم است تا وابستگی های زیر نیز اضافه شوند.( بنا به تصمیم شما ممکن است این وابستگی ها نیاز نباشند و با اینکه نیاز به یکسری وابستگی های دیگر باشد)yarn add @angular/cdk @angular/flex-layout @angular/materialدر این مرحله تنظیمات مربوط به Narik Micro Frontends را در سیستم انجام میدهیم .این کار بسیار ساده است. ابتدا در app.module.ts ، ماژول های مربوطه را import می کنیمimport { MicroFrontendsCoreModule } from '@narik/micro-frontends-core' ... imports:[ ..., MicroFrontendsCoreModule.forRoot() ]سپس لازم است تا به کمک APP_INITIALIZER فرایند initialize شدن سرویس های Narik Micro Frontends را انجام دهیم. این موضوع تضمین می‌کند تا قبل از Initialize شدن Narik Micro-Frontends اجرای برنامه شروع نشود.import {MicroFrontendsService} from '@narik/micro-frontends-infrastructure' ..... providers[ { provide: APP_INITIALIZER, useFactory: initializeMicroFrontendsService, deps: [MicroFrontendsService], multi: true, } ] .... export function initializeMicroFrontendsService( microFrontendsService: MicroFrontendsService ): () => Promise { return () => microFrontendsService.initialize(); }تنظیم app.module.ts به پایان رسید. فایل کامل شده را می توانید در اینجا ببینید.پس از آن دو کار کوچک در app.component داریم. در ابتدا در فایل app.component.html محتوای زیر را می گذاریمloading

در خط اول فقط نمایش یک loading است تا app شما load شود. شما می‌توانید loading دلخواه خود را بگذارید و در خط دوم شما مکان load شدن app ها را مشخص می کنید. در ادامه در فایل app.component.ts لازم است تا app پیش فرض را load کنیم و در مکان مورد نظر نمایش دهیم.export class AppComponent{ constructor(public microFrontendsService: MicroFrontendsService) { this.microFrontendsService.loadAndInitializeDefaultApp('#content-root'); } }فایلهای کامل app.component.html و app.component.ts را می توانید در اینجا و اینجا ببینید.منظور من از app پیش فرض چیست؟ همانطور که در قسمت اول گفتم برای این مثال 10 app داریم. app پیش فرض، app ی است که در ابتدا باید load و initialize شود که در مثال ما همان shell app است. اینکه چگونه این app مشخص می شود را در ادامه خواهیم دید.کاری که تا کنون انجام دادیم روی قسمتی از سیستم بود که اسم آن را host یا میزبان می گذاریم، که در واقع تنها کاری که انجام می دهد میزبانی از app های سیستم است و هیچ کار دیگری با این قسمت نداریم. بقیه کار پیاده سازی سیستم می شود پیاده سازی app ها که هر کدام می تواند توسط یک تیم پیاده سازی شود و مستقل تست و deploy شودو app میزبان تنها با یکسری config از وجود آنها باخبر می شود که این config ها در زمان اجرا هم می توانند تغییر کنند. در این مرحله به سراغ پیاده سازی shell app می رویم. هر چند در این مثال من تمامی app ها در یک Angular Workspace در کنار هم قرار داده ام ولی همانطور که گفتم این app های هیچ وابستگی به هم ندارند و می توانند کاملا به به صورت مستقل توسعه داده شوند. برای ایجاد هر app مراحل زیر را انجام می دهیم:ng g application app-nameپس از اینکه app ایجاد شد تنظیمات Module Federation را روی آن انجام می دهیم. برای این منظور ابتدا در فایل angular.json تنظمیات بیلدرها را برای این app به @angular-builders/custom-webpack تغییر میدهیم و پس از آن به کمک تنظیمات customWebpackConfig آدرس فایل سفارشی تنظیمات webpack را مشخص می کنیم.موارد مطرح شده در این قسمت تنظیمات مربوط به @angular-builders/custom-webpack و Module Federation است که جزییات آن در حوصله این نوشته نیست. با مراجعه یه مستندات هر کدام می توانید جزییات بیشتر و کاملتری را ببینید. در نوشته ای که قبلا برای یک مثال دیگر نوشته ام این موضوع را کمی بیشتر توضیح داده‌ام.Tutorial: How create a pluggable Angular app with Webpack Module Federationمی‌توانید فایل های کامل شده را در این آدرس ها ببینید. فایل angular.json ، extra-webpack.config jsدر این مثال shell app بسیار ساده است. فقط در app.component.html محتوای زیر قرار میگیرد. https://gist.github.com/abadakhshan/e5b2ef6ac941746142b74f2f564e57af#file-shell-app-component-html همانطور که مشاهده می کنید در این کد یک toolbar در بالا قرار گرفته است و در پایین نیز یک router-outlet که قرار است دیگر app ها در این قسمت نمایش داده شوند. همانطور که قبلا گفته شد shell app فقط وظیفه مشخص کردن layout را دارد. تنها موردی که در این کد لازم است تا در مورد آن صحبت شود این قسمت است در این قسمت shell یه سیستم اینگونه می گوید که در داخل toolbar فضایی در نظر گرفته است برای بقیه app ها و از بقیه app ها می خواهد که محتوای مد نظرشان را در این قسمت قرار دهند. اگر هیچ app دیگری برای این قسمت محتوا ارائه ندهد طبیعتا هیچ چیزی به این قسمت اضافه نخواهد شد و اختلالی در کارکرد shell به وجود نخواهد آمد. مقدار Key هم نام فضای در نظر گرفته شده را مشخص می کند . در ادامه خواهیم دید که چگونه app ها می توانند برای اینگونه فضا ها محتوا ارائه کنند. در این خط extension-host کامپوننتی است که در MicroFrontendsUiModule ارائه شده است.و مرحله آخر برای اینکه shell app ما آماده استفاده باشد این است که آن را به سیستم معرفی کنیم.کتابخانه Narik Micro Frontends مفهومی دارد به نام app discovery که وظیفه آن شناسایی app های سیستم است. در حال حاضر پیاده سازی پیش فرض این مفهوم در این کتابخانه بر اساس یک فایل json است که مشخصات app ها در آن قرار میگیرد. این فایل به نام apps.json در مسیر assets قرار میگیرد.برای معرفی shell اطلاعات زیر را به apps.json اضافه میکنیم. https://gist.github.com/abadakhshan/003a057b0f3f0ffcab5524d77b85f1fd مشخصه key شناسه یکتای هر app است. در مورد app پیش فرض قبلا صحبت کردیم. isDefault مشخص می‌کند که آیا این app، پیش فرض است و یا نه. مشخصه load مشخص میکند که این app چگونه باید load شود و initialize مشخص میکند که این app چکونه باید initialize شود. در کتابخانه Narik Micro Frontends دو مفهوم وجود دارد به نام app loader و app Initializer. وظیفه app loader لود کردن app ها بر اساس اطلاعاتی است که در قسمت مشخصه load برای app مشخص شده است. پیاده سازی پیش فرض برای این مفهوم، لود app به کمک Module Federation است.وظیفه app initializer این است که app ها را initialize کند. اینکه چگونه یک app باید initialize شود بر اساس نوع app متفاوت خواهد بود. در حال حاضر پیاده سازی های مختلفی از app initializer در کتابخانه Narik Micro Frontends وجود دارد که بر اساس مشخصه type از یکی از این موارد استفاده می شود. مثلا این مقدار برای shell app برابر "angular-app" است . پس از AngularAppInitializer استفاده خواهد شد. این نوع initializer بر اساس module و bootstrapComponent مشخص شده، می‌تواند app لود شده را initialize کرده و در سیستم قرار دهد. پس از انجام این کارها shell app آماده است.در ادامه پیاده سازی shopping cart را انجام می دهیمتمامی مراحل کاملا شبیه shell app است با چند تفاوت ساده. تفاوت اول در معرفی این app به سیستم است. https://gist.github.com/abadakhshan/efd6f0a01e136afbe224e52ff6b05cac همانطور که می بینید چند تقاوت با shell app دارد. اول از همه مشخصه eagerInitialize. این مشخصه به سیستم می گوید که این app در همان ابتدا باید initialize شود. یعنی حتی قبل از load. چرا؟ اگر به نوع این app دقت کنید می‌بینید که این app از نوع angular-routing-app است . پس لازم است در همان ابتدا routing مربوطه به سیستم معرفی شود , و سیستم هر گاه درخواست route متناسب را دریافت کند این app را لود خواهد کرد. دومین نکته این است که تنظیمات این app دارای یک قسمت metadata است.در این قسمت این app اطلاعات بیشتری به سیستم خواهد داد. فایل metadata را با هم ببینیم. https://gist.github.com/abadakhshan/3353539b6ef37161eefb8ab56b043bbb این فایل دارای دو قسمت مهم است. apps و extension-points. در قسمت apps ، مواردی معرفی می شود که با app های دیگر هیچ تفاوتی ندارند، فقط زیر مجموعه این app تلقی می‌شوند. یعنی این app ها هم می‌توانستند در همان فایل apps.json قرار بگیرند ولی برای مدیریت راحت تر app ها، این فیچر اضافه شده است که یک app بتواند app های زیر مجموعه خودش را داشته باشد. یکی از مزایای این روش این است که اگر مثلا Shopping Cart app غیر فعال شود تمامی app های زیر مجموعه هم غیر فعال خواهند شد.قسمت دوم قسمت extension-points است. حتما به خاطر دارید در shell app در مورد موضوعی صحبت کردیم به نام extension point و اینکه shell app فضایی را در toolbar خود فراهم کرده است که بقیه app ها برای آن قسمت محتوا مشخص کنند. در این قسمت Shopping Cart app میگوید که برای extension point های با Key برابر "shopping-cart-button" می خواهد که shopping-cart-button app لود شود. اگر محتوای همین فایل را نگاه کنید "shopping-cart-button" یک app است مثل همه app ها با این تفاوت که نوع آن برابر " angular-component" است. سیستم کاری که می‌کند این است که پس از لود app یک نمونه از کامپوننت مشخص شده می سازد و در ان extension point قرار می‌دهد.همینطور Shopping Cart app برای دو point دیگر محتوا مشخص کرده است. با این تفاوت که app های مشخص شده در این قسمت نوع متفاوتی دارند. اگر به فایل دقت کنید نوع این app ها "custom-element" است. روال کار کاملا شبیه مدل قبل است با این تفاوت که پس از لود app یه نمونه از custom element مشخص شده ساخته می شود.تنها یک نمونه app مانده است که تا کنون بررسی نکرده ایم که نمونه آن هم در این فایل وجود دارد "angular-service". این نوع app ها یک یا چند پیاده سازی سرویس یه سیستم اضافه می‌کنند. سرویس هایی که در اختیار بقیه app ها قرار خواهند گرفت. البته بقیه app ها هیچگاه درگیر اینکه پیاده سازی توسط کدام app و یا اینکه چگونه پیاده سازی انجام گرفته است نخواهند شد. بلکه contract سرویس در اختیار آنها قرار خواهد گرفت و آنها از آن استفاده خواهند کرد. دو نمونه app که از این نوع در این مثال داریم shopping-cart-service و tax-service هستند.بقیه app ها هم به همین روش به سیستم اضافه می شوند. حتما جزییات بیشتری هم در این مثال وجود دارد که فکر می‌کنم پرداختن به آنها در این نوشته ضرورتی ندارد. کد کامل این مثال در این آدرس و کتابخانه ای که از آن استفاده شده است در این آدرس قرار گرفته است که می‌توانید آنها را ببینید.https://github.com/NarikMe/narik-micro-frontends-samplehttps://github.com/NarikMe/narik-micro-frontendsحتما خوشحال خواهم شد اگر نظرات شما را داشته باشم.

چگونه یک پیاده سازی واقعی به سبک Micro Frontends داشته باشیم - قسمت اول

علی بدخشان — Mon, 30 Aug 2021 19:09:29 +0430

امروزه توسعه برنامه های کاربردی بر پایه وب دنیای جدیدی رو تجربه می کند. علاوه بر ظهور فریم ورک ها و کتابخانه های متفاوت و قدرتمند در این حوزه، به نظر من نکته ای که حرکت به سمت این دنیای جدید را بیشتر نشان می‌دهد، ظهور و بروز مباحث معماری در حوزه فرانت اند است. مباحثی که هنوز هم شاید از دید بعضی ها فقط مربوط به حوزه بک اند هستند.یکی از مهمترین مباحثی که این روزه در این حوزه مطرح می‌شود موضوع Micro frontends هست. تعریف های متفاوتی برای Micro frontends وجود دارد؛ اما شاید یکی از بهترین تعاریف، این تعریف باشد :"An architectural style where independently deliverable frontend applications are composed into a greater whole"(https://martinfowler.com/articles/micro-frontends.html)شاید این چند خط هم کمک کند که درک بهتری پیدا کنیم:Think about a website or web app as a composition of features which are owned by independent teams. (https://micro-frontends.org/)هدف من در این نوشته معرفی Micro frontends نیست. اما خوب اگر قبلا در این مورد مطالعه ای نداشته اید توصیه می‌کنم حتما سری به مقالات و کتابهایی که معرفی می‌کنم بزنید و بعد ادامه این مطلب را مطالعه کنید.مقالات و کتابهای مفید در مورد Micro frontendshttps://martinfowler.com/articles/micro-frontends.htmlhttps://www.manning.com/books/micro-frontends-in-actionhttps://www.oreilly.com/library/view/building-micro-frontends/9781492082989/همانطور که در ابتدای نوشته مطرح شد هدف من در این نوشته معرفی Micro frontends نیست و اگر شما مطالب معرفی شده و بقیه مطالب مشابه را مطالعه کنید می‌توانید دید خوبی نسبت به مفاهیم پیدا کنید. اما مشکل اصلی معمولا اینجاست که این مفاهیم را چطور می‌شود پیاده سازی کرد. شاید هم بشود مثالهایی از پیاده سازی برای موارد خیلی ساده پیدا کرد اما وقعا برای یک Enterprise application چطور می‌شود این مفاهیم و این معماری را پیاده سازی کرد. در طی این دو سالی که در شرکت همکاران سیستم به همراه یک تیم بزرگ و حرفه ای مشغول پیاده سازی یک سیستم واقعا بزرگ با سبک معماری Micro Frontends بوده ایم متوجه شدم که هر چند مطالعه مقالات و کتابها می تواند مسیر را برای ما روشن کند و به حرکت ما جهت دهد، اما حرکت در این مسیر نیازمند داشتن دانش و تجربه بسیار بیشتری است تا در برخورد با چالشها و انتخاب جهت گیری ها بتوان بهترین تصمیم ها را گرفت. البته آنچه که در این نوشته به آن می پردازم پیاده سازی یک مثال کوچک است و با رویکردی حتی متفاوت از آنچه که در این مسیر دو ساله در همکاران سیستم رفته ایم.هر چند این مثال هم حتما قابل گسترش هست و می‌تواند به عنوان مبنا برای Enterprise Application ها هم قرار بگیرد. البته من در نوشته های بعدی این مسیر را ادامه خواهم داد و امیدوارم شما هم در این مسیر با من همراه باشید. برای آشنایی بیشتر با آنچه که در همکاران سیستم انجام داده ایم میتوانید این ارائه را ببینید.رویداد آنلاین رونمایی از معماری رابط کاربری جدید همکاران سیستماین مطلب در دو قسمت نوشته می شود. در قسمت اول درباره اینکه قرار است چه چیزی و چطور پیاده سازی شود صحبت می‌کنم و در قسمت دوم هم درباره جزییات پیاده سازی صحبت خواهم کرد . اما قبل از اینکه شروع کنم باز هم روی یک مساله تاکید می‌کنم. مطمئنا برای پیاده سازی یک محصول بر پایه Micro Frontends نیازمند داشتن دانش و پرداختن به مسائل بیشتری از آنچه که در این نوشته مطرح شده است، هستید. مثلا اینکه چطور یک سیستم بزرگ را به app های کوچکتر بشکنیم، این app ها چطور با یکدیگر ارتباط داشته باشند، چطور در نهایت با هم ترکیب بشوند، استراتژی های مربوط به versioning و deployment و موارد دیگر. دقت کنید که مثلا موضوعاتی مثل شکستن app ها در این مثال به گونه ای انجام شده است که درک بهتری از روش پیاده سازی به ما بدهد و احتمالا در یک پروژه واقعی شاید شکست app ها به گونه ای متفاوت انجام شود.مقدمات قدری طولانی شد. پس بهتر است برویم سراغ اصل مطلب. قرار است در این مثال یک سایت خرید اینترنتی ساده را پیاده سازی کنیم. این سایت شامل صفحه ای است که لیست کالا ها را نشان میدهد و کاربر امکان اضافه کردن کالاها از این لیست به سبد خرید را دارد. سبد خرید چیزی شبیه همه سبد های خریدهایی است که در سایت‌های مشابه دیده اید به همراه صفحه نهایی کردن خرید که شامل محاسبات ساده و انتخاب روش پرداخت است. در کنار اینها یک قسمت ساده هم برای نمایش اطلاعات کاربر جاری و احتمالا ویرایش این اطلاعات داریم. در ادامه صفحات پیاده سازی شده این مثال را با هم می‌بینیمصفحه کالا و سبد خریدصفحه نهایی کردین خریدنمایش مشخصات و پروفایل کاربرهمانطور که می بینید این مثال شامل سه صفحه ساده است. حالا اگر بخواهیم این مثال را با سبک معماری Micro Frontends پیاده سازی کنیم به نظر شما سیستم ما به چه app هایی شکسته خواهد شد؟قبل از اینکه در مورد app ها صحبت کنیم من این مثال را به چهار حوزه اصلی تقسیم می‌کنمShellدر واقع container اصلی است و بیشتر وظیفه مشخص کردن layout و مکانهای قرارگیری app های دیگر را بر عهده دارد و احتمالا شامل بیزنس خاصی نخواهد بودUserمدیریت هر آنچه که مربوط به کاربر است در این حوزه خواهد بود. مسائلی مانند ورود به سیستم، تغییر پروفایل، آدرس ها و موارد مشابهProductنمایش اطلاعات کالاها به شکل ها و ترتیب های مختلف در این حوزه انجام خواهد پذیرفتShopping Cartمسائل مربوط به سبد خرید مثلا نمایش موارد اضافه شده، کم و زیاد کردن آنها، انجام محاسبات و نهایی کردن سفارش در این حوزه انجام می شود .در این قسمت می توانیم گریزی بزنیم به مفاهیم Micro Frontends. آیا ما برای هر کدام از این حوزه ها یک تیم مستقل داریم؟ الزاما نه. ولی اگر قرار است ما تیم های مختلفی داشته باشم می توانیم تیم ها را بر اساس این حوزه ها تقسیم بندی کنیم و از یکی از بزرگترین مزایای Micro Frontends بهره مند شویمAs a higher-order benefit of decoupling both our codebases and our release cycles, we get a long way towards having fully independent teams, who can own a section of a product from ideation through to production and beyond(https://martinfowler.com/articles/micro-frontends.html)پس ما دارای چهار app خواهیم بود؟ می‌توانیم بگوییم حداقل چهار app. هر تیم ممکن است بیشتر ازیک app را توسعه دهد. ولی واقعا ما در این مثال چند app خواهیم داشت؟ پاسخ به این سوال وابستگی زیادی به تعریف ما از app دارد. طبق تعریفی که من از app دارمهر قطعه ای که به صورت مستقل بتواند develop و deploy شود یک app است.پس با این تعریف، تعداد app های ما بیشتر خواهد بود. برای مثال در حوزه Shopping Cart یک app داریم که شامل دکمه سبد خرید است در header صفحه، یک app که کار انجام محاسبات مربوط به tax را انجام میدهد و و حتی سه app دیگر . یعنی app ها ممکن است در حد یک قطعه کوچک UI( چیزی شبیه Plugin) و یا حتی یک سرویس باشند. ممکن است در برخی نوشته ها اینها را app مستقل ندانند و به عنوان قسمتهایی از یک app بزرگتر به حساب آورند. با توجه به این صحبتها، app های موجود در این مثال را می توانید در شکل زیر ببینید:همانطور که در تصویر مشخص است در این مثال ما ده app داریم. برای آشنایی در مورد هر کدام توضیح مختصری می دهم.Shell:در مورد Shell قبلا توضیح دادم. این app وظیفه مشخص کردن layout برنامه را برعهده دارد. اینکه منو در کجا قرار بگیرد. دکمه نمایش سبد خرید در کجا قرار بگیرید، بقیه صفحات قرار است در کجا لود شوند و … .Shopping Cart Button:دکمه ای است که در اکثر سایتهای مشابه می بینید. در بالای صفحه قرار می گیرد و وضعیت سبد خرید شما را نمایش می دهد. اگر روی آن کلیک کنید جزیات بیشتری از سبد خرید را نمایش می دهد و پس از کلیک رو دکمه نهایی کردن خرید شما را به صفحه نهایی کردن خرید راهنمایی می کند.Shopping Cart: این app در واقع صفحه نهایی کردن سفارش است. در این صفحه کاربر سبد خرید را مشاهده میکند . میتواند برخی از اقلام را حذف کند. محاسبات نهایی و حمع پرداختی کاربر نمایش داده می شود و کاربر می تواند نحوه پرداخت و مشخصات آن را مشخص کند.Shopping Cart Service:یک سرویس است که هیچ نمود ظاهری ندارد. وظیفه مدیریت اطلاعات سبد خرید را به عهده دارد. در جرییات پیاده سازی بیشتر در مورد این سرویس خواهم گفت.Payment Type 1:صفحه ای است که اگر کاربر نحوه پرداخت نوع 1 را انتخاب کند لود می شود تا اطلاعات مورد نظر را از کاربر بگیرید.Payment Type 2:صفحه ای است که اگر کاربر نحوه پرداخت نوع 2 را انتخاب کند لود می شود تا اطلاعات مورد نظر را از کاربر بگیریدProducts:صفحه ای است که لیست محصولات را به کاربر نمایش می دهد و کاربر می تواند محصولات مورد نظر را به سبد خرید اضافه کند.User Profile:صفحه نمایش/ویرایش اطلاعات کاربر .Current User Button:دکمه ای که در بالای صفحه قرار میگیرد و در صورتی که کاربر وارد صفحه شده باشد اطلاعات کاربر را نمایش می دهد و احتمالا با امکاناتی مانند خروج از سیستم و موارد مشابه.شاید مجدد این سوال مطرح شود که چه لزومی دارد که یک سیستم به app های به این کوچکی تقسیم شوند. در پاسخ باید به چند نکته اشاره کنم:همانطور که گفتم این یک مثال است و شاید شما اینگونه فرایند شکستن سیستم را انجام ندهید.موارد مطرح شده در این مثال خیلی ساده هستند ولی اگر با سیستم های واقعی کار کرده باشید حتما می‌دانید که مثلا صفحه نمایش کالا حاوی چه جزییات و پیچیدگیهای مهمی می‌تواند باشد که شاید یک تیم را برای مدتها به خود مشغول کند.شکستن سیستم به app های کوچک این امکان را به شما می‌دهد که هر قطعه از سیستم جدا توسعه پیدا کند، جدا تست شود و جدا deploy شود. این یک امتیاز خیلی مهم است. تیمهای متمرکز بر موضوعات مشخص. مثلا ممکن است سرویسهای محاسبه به صورت مستقل این فرایند را طی کنند و راحت بتوانند جایگزین هم شوند. البته خیلی مهم است که بدانید در مقابل چیزهایی که به دست می‌آورید چه چیزهایی را از دست می‌دهید.شاید دلیل جدا شدن بعضی قسمتها ماهیت مختلف آن قسمت باشد. به عنوان مثال Current User Profile یک app جدا از User profile شده است. زیرا در همان ابتدا لازم است در header بالا و در دل Shell لود شود ولی User Profile فقط وقتی کاربر در خواست صفحه مورد نظر را داد لود و نمایش داده می‌شود. پس بهتر است تا Current User App به صورت یک bundle مستقل و بسیار سبک باشد.در قسمت دوم این نوشته به بیان جزییات پیاده سازی خواهم پرداخت.چگونه یک پیاده سازی واقعی به سبک Micro Frontends داشته باشیم- قسمت دوم