برای تحلیل چرایی استفاده از میکروفرانت-اند و موارد کاربری آن باید ابتدا مسیر پیشرفت و نیازمندی‌های حوزه فرانت-اند را بررسی کنیم. در ابتدا پیدایش تکنولوژیهای مبتنی بر وب کاربران را به استفاده از وب‌سایت‌ها هدایت کرد، در آن زمان بیشتر درگاه‌های آنلاین ارائه دهنده خدمات به صورت بسیار ساده و بدون ایجاد راه‌های تعاملی مشغول به انجام وظایف خود بودند. رفته رفته با افزایش استفاده از این نوع فناوری‌ها، نیازمندی‌های مورد انتظار هم تغییر پیدا کرد به صورتی که سطح تعامل بین کاربر و وب‌سایت افزایش یافت و همین مورد نیازمند ایجاد بستر‌هایی پیچیده‌تر برای ارائه خدمات بود. در نتیجه بازه زمانی ایجاد نسخه دوم وب(WEB 2.0) شامل تکامل سکوهایی شد تا بتوانند در دو لایه بک-اند و فرانت-اند با استفاده از صفحات وب خدمات گسترده‌تر و تعامل‌پذیرتری را به کاربران خود ارائه کنند.
در همین زمان استفاده از دستگاه‌های الکترونیکی جدیدی با صفحات نمایش کوچک‌تری در بازار رواج یافت و از طرفی با استقبال زیاد کاربران مواجه شد. از این رو بستر‌های ارائه دهنده خدمات از طریق درگاه‌های وب باید طوری روش‌های استفاده و دسترسی‌پذیری برنامه‌های کاربردی خود را تنظیم می‌کرند تا بتوانند در تمامی دستگاه‌ها و تمامی ابعاد خدمات خود را به خوبی به کاربران ارائه دهند.
۲-۱ برنامه‌های کاربردی مخصوص سیستم عامل‌ها(Native Applications)
حال با استفاده گسترده از تبلت‌ها و موبایل‌ها، برنامه‌های کاربردی مخصوص برای اجرا در بستر سیستم عامل‌های این دستگاه‌ها توسعه یافت. از ویژگی‌های مهم این برنامه‌ها می‌توان به سرعت و عملکرد خوب، دسترسی‌پذیری و قابلیت استفاده بالا و طراحی بهینه اشاره کرد. رفته رفته کاربران از درگاه‌های وب هم انتظار داشتند تا مانند برنامه‌های کاربردی مخصوص سیستم عامل‌ها عمل کنند.
بنابراین با تغییر نیازمندیها دوباره باید فناوری‌های جدیدتری به کار گرفته می‌شد تا کاربران به بهترین شکل ممکن از خدمات استفاده کنند. برخی از این نیازمندیها:
· ارائه پیام‌های مناسب به هر کاربر متناسب به وضعیت درخواست آن کاربر از برنامه.
· طراحی و پیاده‌سازی برخی المان‌های حرکتی مانند زمان‌های بارگیری یا بارگذاری فایل.
· برخی از اعمال بدون بارگیری دوباره صفحه(Refresh) باید انجام شوند.
· در زمان بارگیری صفحه آن قسمت‌هایی که بارگیری نشده‌اند باید با طرحی متفاوت نمایش داده شوند.
اکنون نیازمندی‌های کاربران دائماً در حال تغییر است و آن‌ها انتظار دارند تا برنامه‌های مبتنی بر وب بتوانند در لایه رابط کاربری این نیازمندیها را به ساده‌ترین شکل به آن‌ها ارائه کنند. از طرفی حوزه فرانت-اند هم در حال ارائه کتابخانه‌ها و فریمورک‌های جدیدتری به محیط توسعه لایه واسط کاربری است. تمامی موارد ذکر شده باعث انتقال مسئولیت و پیچیدگی زیادی به بخش فرانت-اند برنامه‌های مبتنی بر وب شده.
حال توسعه‌دهندگان این حوزه باید معماری ارائه می‌کردند که اول در راستای مبانی میکروسرویس‌ها باشد و دوم نیاز‌های لایه فرانت-اند را نیز در نظر می‌گرفت. بنابراین ایده اولیه معماری و دیدگاه میکروفرانت-اند شکل گرفت به صورتی که نرم‌افزار به صورت عمودی به بخش‌هایی تقسیم می‌شود و هر بخش افراد و روش عملکردی مستقل خود را دارد سپس هر کدام از این افراد در تیم‌های خود مشغول به ارائه خدمات با استفاده از پایگاه‌داده مستقل گروه خود می‌شوند.
۱-۲ ساختار کلی معماری
تیمها:
هر گروه با یک اسم مرتبط به عملیات خود سعی دارد تا یک فعالیت مشخص که در نهایت ارزش و خدمت مورد نظر را برای کاربر هدف ایجاد می‌کند را به سازمان خود ارائه دهد. در اصل تفاوت اصلی این رویکرد در بخش ساختار افراد در روش تقسیم‌بندی آن‌ها است به صورتی که دیگر مانند قبل معیار گروه‌بندی فناوری و تکنولوژی‌ها نیست بلکه در میکرو فرانت-اند معیار اصلی حوزه رفع نیازمندی‌های مختلف کاربران نهایی است. به عنوان مثال: تیم پیشنهاد دهنده، تیم محصول، تیم نقد و بررسی و...
صفحه‌ها:
همانطور که گفته شد تیمها به صورت مستقل وظایف مشخصی را دنبال می‌کنند و آن‌ها را ارائه می‌دهند. این وظایف می‌توانند در قالب صفحات، بخشی از یک نیاز عملکردی و یا چندین بخش از یک صفحه باشد. تشخیص این موضوع که یک فرآورده یک تیم در کدام دسته از موارد ذکر شده قرار گیرد با نقطه‌های اشتراکی میان تیمها است. در واقع ممکن است در یک صفحه برای فروش کالا نیاز به بخش پیشنهاد کالا و نقد و بررسی به صورت جداگانه در یک صفحه باشد و یا در صورت تشخیص به هر کدام صفحه‌ای جدا تعلق بگیرد.
ادغام بخش‌ها(Integration):
برای انجام دادن این بخش نیاز به اتصال قسمتهای مختلف در ۳ مورد را داریم:
1. اتصال در سطح صفحات:
اگر بارگیری صفحه اهمیت زیادی نداشته باشد با استفاده از لینک‌ها می‌توان صفحات را به راحتی به یکدیگر متصل کرد اما در صورت عدم بارگیری مجدد صفحه‌ها باید از برخی فریمورک‌ها استفاده کرد.
2. ترکیب‌بندی:
در واقع هر صفحه مسئولیتی در قبال قرار دادن هر بخش در جای مخصوص به خود را ندارد و این یکپارچگی باید طی فرآیند دیگری انجام شود که به ۲ صورت است: ۱- ترکیب‌بندی سمت سرور
۲- ترکیب‌بندی سمت کاربر
3. ارتباط بخش‌ها:
در پایان هم، هر بخش باید در داخل صفحات بتواند با بخش‌های دیگر در ارتباط باشد و واکنش مناسب را ارائه کند.
موضوعات اشتراکی(shared topics):
تا این قسمت حتما می‌دانیم که میکرو فرانت-اندبا تقسیم قسمتهای مختلف برنامه به بخش‌های کوچک‌تر و کم ارتباط(loosely coupled) سعی در انتقال مفاهیم میکروسرویس به فرانت-اند را داشته‌است اما این ارتباط کم و کارکرد مستقل بخش‌ها باید در بعضی نقاط توسط معیارهایی کنترل و راهنمایی شود.
کارایی وب:
در میکرو فرانت-اند هر گروه به صورت مستقل برای رسیدن به هدف نهایی مورد نظر خود تلاش می‌کند و به دلیل گسترش این گروه‌ها و در نتیجه تولید کدهای زیاد ممکن است برخی ناهماهنگی‌ها و افزونگی کد انجام شود. بنابراین باید همواره بر عملکرد و کارایی فرآورده‌های هر بخش نظارت وجود داشته باشد.
سیستم طراحی:
برای رعایت تداوم‌پذیری در بخش‌های متفاوت باید یک سیستم کلی و میان تیمی ارائه شود تا تمامی تیمها بر اساس آن کامپوننت‌های خود را توسعه دهند. در این صورت با وجود اینکه هر بخش به صورت مستقل و جداگانه در حال توسعه است اما برای کاربر نهایی به شکل یک وب‌سایت واحد به نمایش در خواهد آمد.
دانش اشتراکی:
در بعضی موقعیت‌ها نیاز است تا تیمها نکات مهم و تکرارپذیر خود را برای دیگر گروه‌ها به اشتراک بگذارند تا از دوباره کاری‌ها جلوگیری شود.
تا اینجای این نوشته متوجه شدیم که معماری میکروفرانت-اند با تقسیم افراد در گروه‌هایی با ساختار عمودی سیستم سعی در پیشبرد فرآیند توسعه بخش‌های لایه فرانت‌اند را با سرعت و کارایی بهتر دارد که در این ساختار برای جلوگیری از بروز برخی مشکلات باید به نکاتی نظیر استفاده از معیارهای میان تیمی و به کار گیری تکنیک‌های ادغام بخش‌ها رو بیاوریم. حال که مبانی کلی و پایه‌ای میکروفرانت-اند را درک کردیم میخواهیم بدانیم که قرار است چه مشکلاتی را در طی پیاده‌سازی این معماری حل کنیم.
۱-۳ توسعه محصول سریع‌تر
فرض کنید که قرار است یک نیازمندی جدید در محصول پوشش داده شود، در معماری معمولی طی جلساتی میان افراد مختلف در تیم‌های متفاوت مبانی این امکانات جدید ارائه می‌شود تا به مرحله پیاده‌سازی کامل برسد. اما در میکروفرانت-اند می‌توانیم تمام افرادی که برای انجام آن نیازمندی جدید همکاری دارند را در یک گروه واحد قرار دهیم و کل مسیر پیاده‌سازی آن را برای یک محیط ثابت پیش ببریم. این موضوع خود باعث افزایش سرعت امکانات جدید در محصول می‌شود.
۲-۳ حذف فرانت‌اند یکپارچه
دیگر خبری از استفاده از کدهای فرانت‌اند به صورت یکجا نیست و در میکروفرانت-اند با تقسیم هر بخش برای توسعه هر قسمت از محصول بسیار راحت‌تر هستیم. برخی از فواید این معماری:
· فرآیند استقرار مستقل
· جداسازی و انزوای امکان بروز خطا و شکست در کد به یک بخش
· راحتی در فهم و توسعه کد
· افزایش امکان استفاده مجدد و بازیابی کد
· پیشبینی‌پذیر تر بودن بخش‌ها زیرا دیگر حالت‌های(states) اشتراکی زیادی نداریم.
۳-۳ قابلیت ایجاد تغییرات بنیادین
همانطور که در بخش اول گفته شد با تغییر روزمره نیازمندی‌های کاربران چه در محصول و چه در انطباق با فناوری‌های جدید محیط کسب و کار، این لایه فرانت‌اند است که بیشتر از اکثر بخش‌ها در طول زمان کم‌تری ممکن از تغییر کند. در این راستا توسعه دهندگان باید قادر باشند تا در شرایط مختلف تغییرات بنیادی را در ساختار هر بخش ایجاد کنند. مانند: تغییر در فریمورک‌ها رای انجام بعضی اعمال خاص در صفحه‌ها.
از طرفی سازمان‌ها زمانی که تصمیم به ارائه محصول در بازارهای بزرگ می‌گیرند انتظار دارند تا بتوانند به سرعت در راستای رفع نیازمندی‌های محیط کسب و کار خود در هر دامنه مشخص اقدامات مورد نظرشان را اعمال کنند بنابراین باید علاوه بر به کار گیری از میکروسرویس در سطح‌های پایین‌تر از فرانت‌اند خود بخش فرانت محصول هم همیشه در نظر داشته باشیم.
۴-۳ تصمیم‌گیری مستقل
اینکه بتوانیم در هر بخش آزادانه امکان تصمیم‌گیری برای تغییر در تکنولوژیهای مورد استفاده در آن بخش را داشته باشیم.(بدون توجه به درگیر شدن در فرآیند انجام انتقال هر سیستم به وضعیتی که نیازمندی‌های پذیرش آن فناوری جدید را داشته باشد.)
قطعاً در معماری یکپارچه برای تغییرهای هر چند کوچک به دلیل وابستگی زیاد بین بخش‌ها باید قسمت زیادی از کدها را تغییر دهیم و چه بسا امکان این تغییر اصلاً فراهم نشود و مجبور به بازیابی تمامی کد پروژه شویم.اما در میکروفرانت-اند این آزادی را داریم که هر زمان با توجه به استقلال معماری میکرو(داخلی) تکنولوژی را تغییر دهیم و البته نیم نگاهی هم به مستندات و قوانین معماری ماکرو(خارجی) جهت اعمال تغییرات داشته باشیم.
تمامی نقاط قوت و کارایی بالای این معماری بررسی و اشاره شد اما قطعاً مانند تمامی تصمیماتی که یک معمار نرم‌افزار باید بگیرد(همیشه نکات منفی و مثبتی وجود دارد) هیچگاه قطعیتی نسبت به موضوعی وجود ندارد و معمار باید نسبت به شرایط اقدامات لازم را ارائه کند. از این رو در این قسمت برخی نکات منفی معماری میکروفرانت‌اند نوشته شده است.
۱-۴ افزونگی
چندین تیم به صورت هم زمان در حال توسعه نرم‌افزار هستند و در اصل هر گروه قصد دارند تا استک تکنولوژی خود را توسعه دهند، هر تیم فرآیند استقرار و یکپارچه‌سازی مداوم مخصوص به خود را دارد و امکان دارد تا اسکریپت‌های JS/CSS داخل برنامه نهایی قرار داده شود که در تمام محصول بی‌جهت تکرار می‌شوند. به عنوان مثال: یک مشکل امنیتی در یک کتابخانه محبوب را در یک مکان مرکزی نمی‌توان رفع کرد بلکه تمامی بخش‌ها باید جداگانه به آن بپردازند.
دلیل اصلی ایجاد همچین معماری که هیچ موردی را در بخش‌های خود با یکدیگر به اشتراک نمی‌گذارد این است که با تمامی موارد بالا باز هم نمی‌توان ضرر ایجاد وابستگی بالا را قبول کرد و این موارد را دچار نشد.
۲-۴ تداوم و ثبات
در تمامی بخش‌ها هر تیم پایگاه‌داده جداگانه خود را دارد تا بتواند به صورت موازی و مستقل با آن کار کند اما در برخی موارد و برای بعضی بخش‌ها نیازمند استفاده از داده‌های ثبت شده در دیگر قسمت‌ها هستیم. در این موارد می‌توانیم از تکنیک‌های تکثیر داده‌ها مانند Even Bus و feed system استفاده کنیم. به عنوان مثال یک تیم غیر از خود تیم محصول به داده‌های این قسمت نیاز دارد، آن‌ها می‌توانند داده‌های محصول را تکثیر کنند تا اگر بخش محصول دچار مشکل شد این اختلال در کار آن‌ها تأثیر نگزارد. البته همچنان با استفاده از این تکنیک‌ها هم ممکن است سرعت پاسخ‌گویی به درخواست‌ها کاهش یابد و سیستم دچار اختلالات دیگری شود.
۳-۴ ناهمگونی
استفاده از تکنولوژیهای مختلف در هر گروه اگر بیش از اندازه شود خود باعث بروز مشکل در روند توسعه نرم‌افزار می‌شود. که باعث سخت شدن جابه‌جایی افراد در تیم‌های مختلف و استخدام افراد جدید می‌شود.
۱-۵ برای پروژه‌های متوسط و بزرگ
یکی از اهداف اصلی میکروفرانت‌اند در اصل افزایش مقیاس‌پذیری سیستمی که از آن استفاده می‌کند است. بنابراین اگر نرم‌افزار با تعداد مشخص و کمی افراد در حال ارائه خدمان و توسعه است پس نیازی به استفاده از این معماری نیست زیرا استفاده از آن در سیستم‌های کوچک بسیار زیان‌آورتر است تا اینکه بتواند به سازمان کمکی کند. مثلاً اگر تعداد افرادی که در حال توسعه محصول هستند از ۱۰ نفر بیشتر شد و مدیریت و کنترل فرآیند‌ها سخت‌تر از قبل شد نیاز داریم تا تفکر میکروفرانت‌اند را اعمال کنیم.
۲-۵ بهترین عملکرد برای وب‌سایت‌ها
هر چند این معماری قابل استفاده برای تمامی بستر‌های ارائه دهنده خدمات که از لایه رابط کاربری بهره می‌برند هست اما باید توجه داشت که به عنوان مثال برای برنامه‌های مخصوص یک دستگاه(native APP) چون تمامی بسته‌های توسعه به صورت یک بسته واحد اجرا می‌شوند بنابراین استفاده از این معماری توجیه خاصی جهت بهینه کردن فرآیند توسعه نرم‌افزار ندارد.
۳-۵ بهره‌وری در مقابل سربار
در ابتدای کار اول باید یکسری محدوده‌ها و قوانینی تعیین شود تا تمامی افراد از آن‌ها پیروی کنند و تیمها در کد و خروجی کار هماهنگ و یکدست‌تر کار کنند. مثلاً استفاده از یک فناوری خاص در فریمورک ری‌اکت. همچنین ارائه یک راه ارتباطی جهت اشتراک‌گذاری دانش بین افراد هر تیم می‌تواند به بالا رفتن سطح عملکرد کلی سیستم کمک کند.
با گسترش نرم‌افزار و استفاده از تیم‌های مختلف برای توسعه محصول بعضی پیچیدگی‌های جدیدی ایجاد می‌شوند و مدیریت تمام تیمها خود می‌تواند بسیار زمان‌گیر باشد. مثلاً اگر در فرآیندی که چندین گروه در توسعه آن شرکت دارند مشکل به وجود آید مسئولیت رفع آن به عهده کدام گروه است؟ یا محیط مرورگر‌های یک محیط اشتراکی است و همیشه در صورت بروز مشکل پیدا کردن منشع آن آسان نخواهد بود.
همانطور که گفته شد باید بزرگی پروژه مورد نظر به حد قابل قبولی برسد تا بتوانیم آن را مناسب برای اجرای میکروفرانت-اند بدانیم. از طرفی نرم‌افزاری که قرار است ایم معماری برای آن پیاده‌سازی شود باید طوری تحلیل و طراحی شده باشد که برای تقسیم‌بندی آن به صورت عمودی در تیم‌های مختلف به مشکل بر نخوریم. در واقع نباید وظایف و موضوعاتی که گروه‌های قرار است حول آن‌ها کار کنند تداخل و یا هم‌پوشانی زیادی داشته باشند. زیرا در این صورت بحث‌ها و موارد غیر قطعی بسیاری رخ می‌دهد و این خود باعث از بین رفتن زمان مفید توسعه محصول می‌شود.
اگر نیازمندی‌های محصول توسعه آن را در تعداد زیادی از پلتفرم‌ها الزامی بداند نیز استفاده از میکروفرانت توصیه نمی‌شود زیرا به علت افزایش تعداد پلتفرم‌ها یک تیم قادر به توسعه هر کدام از آن‌ها نمی‌باشد. به عنوان مثال نرم‌افزاری مانند Netflix که در تمامی دستگاه‌ها مانند تلویزیون‌ها، Setup Box، کنسول‌های بازی و گوشی‌های همراه و تبلت‌ها برنامه کاربردی فعال دارد و سعی می‌کند تا کدبیس خود در بستر وب و ارائه خدمات مختلف با استفاده از آن را در تمامی دستگاه‌های ذکر شده حفظ کند. توسعه چنین محصولی بر اساس معماری میکروفرانت-اند کمی با مشکل روبه رو می‌شود.
با اینکه این دیدگاه در سال‌های اخیر موفق به ارائه کارایی خود شده‌است اما خیلی از شرکت‌ها از در سال‌ها قبل از آن استفاده می‌کردند.مانند آمازون که گفته می‌شود برای یکپارچه کردن بخش‌های مختلف در صفحات از تکنیک‌ها ادغام کدهای فرانت استفاده می‌کند.
البته در حوزه فروشگاه‌های الکترونیکی میکروفرانت-اند بسیار پر کاربرد بوده است. به عنوان مثال:
OTTO Group، IKEA، Thalia از دسته فروشگاه‌های اینترنتی هستند که از این معماری استفاده می‌کنند. دیگر شرکت‌هایی که از مبانی این دیدگاه استفاده می‌کنند می‌توان به Spotify اشاره کرد. آن‌ها با استفاده از تیم‌هایی که اسم آن‌ها را اسکوآد(squad) تعیین کرده‌اند در قالب فریمورک SAP اقدام به تقسیم افراد و فعالیت‌های سازمان در گروه‌هایی با استقلال بالا کرده‌است.
