মাইক্রোফ্রন্টেন্ড কীভাবে কাজ করে: স্থাপত্য, নিদর্শন এবং উদাহরণ

হোম » পাইথন » মাইক্রোফ্রন্টেন্ড কীভাবে কাজ করে: স্থাপত্য, নিদর্শন এবং উদাহরণ

মাইক্রোফ্রন্টেন্ডগুলি সবচেয়ে আলোচিত ফ্রন্টএন্ড আর্কিটেকচার প্যাটার্নগুলির মধ্যে একটি হয়ে উঠেছে। ক্লাসিক একক-পৃষ্ঠার মনোলিথকে ছাড়িয়ে যাওয়া দলগুলির জন্য। যখন আপনার কয়েক ডজন ডেভেলপার একই কোডবেস স্পর্শ করে, তখন রিলিজ চক্র ধীর হয়ে যায়, সর্বত্র রিগ্রেশন দেখা দেয় এবং ছোট UI পরিবর্তনগুলির জন্য হঠাৎ করে ব্যাপক সমন্বয়ের প্রয়োজন হয়। মাইক্রোফ্রন্টেন্ডগুলি UI কে স্বাধীনভাবে নির্মিত এবং স্থাপন করা টুকরোগুলিতে কেটে ঠিক সেই সমস্যাটিকে আক্রমণ করে।

এই নির্দেশিকায় আমরা মাইক্রোফ্রন্টেন্ড কী, কেন তারা উপস্থিত হয়েছিল, মাইক্রোসার্ভিসের সাথে কীভাবে তারা সম্পর্কিত তা নিয়ে আলোচনা করব।, ডিজাইন করার সময় কোন মূল ধারণাগুলিকে আপনার সম্মান করা উচিত এবং React, Angular, Next.js, Web Components, Webpack Module Federation এবং Single-SPA এর মতো প্রযুক্তির সাথে কীভাবে তারা বাস্তবে কাজ করে। আমরা বাস্তব স্থাপত্য নিদর্শন, ভালো অনুশীলন, সাধারণ ত্রুটি এবং পণ্য ক্যাটালগ এবং কার্ট যেমন পৃথক মাইক্রোফ্রন্টেন্ড হিসাবে বাস্তবায়িত, তাও খতিয়ে দেখব।

মাইক্রোফ্রন্টেন্ড কী এবং কেন তারা আবির্ভূত হয়েছিল?

"মাইক্রো ফ্রন্টএন্ডস" শব্দটি ২০১৬ সালের দিকে থটওয়ার্কস টেকনোলজি রাডারে জনপ্রিয় হয়েছিল। একটি খুব সুনির্দিষ্ট প্রবণতার উত্তর হিসেবে: ব্যাকএন্ড আর্কিটেকচারগুলি মাইক্রোসার্ভিসে স্থানান্তরিত হচ্ছিল, কিন্তু ব্রাউজার দিকটি একটি একক দলের মালিকানাধীন একটি বৃহৎ, ভঙ্গুর মনোলিথ হিসাবে রয়ে গেছে। সময়ের সাথে সাথে সেই "মোটা ক্লায়েন্ট" SPA বিকশিত হওয়া কঠিন হয়ে পড়ে, যদিও ব্যাকএন্ডটি সুন্দরভাবে ছোট পরিষেবাগুলিতে বিভক্ত।

একটি মাইক্রোফ্রন্টেন্ড মূলত ব্রাউজার UI-তে প্রয়োগ করা মাইক্রোসার্ভিস ধারণা।: একটি বৃহৎ ফ্রন্টএন্ড রিপোজিটরির পরিবর্তে, আপনি একাধিক ছোট, স্বয়ংসম্পূর্ণ অ্যাপ্লিকেশন থেকে ইউজার ইন্টারফেস তৈরি করেন। প্রতিটি অ্যাপ্লিকেশনের একটি স্পষ্ট ব্যবসায়িক ডোমেন রয়েছে (উদাহরণস্বরূপ, "চেকআউট", "পণ্য অনুসন্ধান", "ছাত্র প্রোফাইল") এবং এটি নিজস্ব ক্যাডেন্সে তৈরি, পরীক্ষা এবং স্থাপন করা যেতে পারে।

ঠিক যেমন মাইক্রোসার্ভিসেস ব্যাকএন্ড লজিককে আলাদা আলাদা ডিপ্লোয়েবল ইউনিটে বিভক্ত করে, তেমনি মাইক্রোফ্রন্টেন্ডগুলি ফ্রন্টএন্ডকে উল্লম্ব স্লাইসে বিভক্ত করে। যা ডাটাবেস বা API থেকে শুরু করে ব্যাকএন্ড, ইউজার ইন্টারফেস পর্যন্ত বিস্তৃত। একটি ক্রস-ফাংশনাল টিম ডেটা স্কিমা থেকে শুরু করে UI উপাদান পর্যন্ত, সেই উল্লম্ব স্লাইসটি এন্ড-টু-এন্ডের মালিক।

এই "উল্লম্ব সংগঠন" স্তর দ্বারা অনুভূমিক বিভাজনের সাথে বৈপরীত্য করে (UI এর জন্য একটি দল, API এর জন্য আরেকটি দল, ডাটাবেসের জন্য আরেকটি দল)। উল্লম্ব দলগুলি দ্রুত পাঠানোর প্রবণতা রাখে কারণ তাদের অর্ধেক কোম্পানির মধ্যে প্রতিটি ছোট পরিবর্তন সমন্বয় করার প্রয়োজন হয় না।

অ্যাপ্লিকেশনের দৃষ্টিকোণ থেকে, একটি মাইক্রোফ্রন্টেন্ড হল একটি স্বায়ত্তশাসিত ওয়েব অ্যাপ্লিকেশন যা একটি বৃহত্তর অভিজ্ঞতায় রূপান্তরিত হতে পারে: এর নিজস্ব রাউটিং, স্টেট ম্যানেজমেন্ট, ডিজাইন সিস্টেম এবং ডিপ্লয়মেন্ট পাইপলাইন থাকতে পারে, যতক্ষণ না এটি বাকি সিস্টেমের সাথে (URL, ইভেন্ট, API, শেয়ার্ড লাইব্রেরি ইত্যাদি) চুক্তির একটি সেটকে সম্মান করে।

মাইক্রোফ্রন্টেন্ডের পিছনে মূল ধারণা এবং নীতিগুলি

সফল মাইক্রোফ্রন্টেন্ড আর্কিটেকচারে বেশ কিছু পুনরাবৃত্ত নীতি দেখা যায়; এগুলো কোন কঠোর নিয়ম নয় কিন্তু যদি তুমি এগুলোকে রেলিং হিসেবে ব্যবহার করো তাহলে এগুলো তোমাকে অনেক যন্ত্রণা থেকে বাঁচাবে।

প্রযুক্তি অজ্ঞেয়বাদ এটি সবচেয়ে বিখ্যাত নীতিগুলির মধ্যে একটি: প্রতিটি দলকে অন্য সকলের সাথে সিঙ্ক্রোনাইজ না করেই তাদের টেক স্ট্যাক নির্বাচন এবং আপগ্রেড করতে সক্ষম হওয়া উচিত। হয়তো একটি মাইক্রোফ্রন্টেন্ড React-এ, আরেকটি Angular-এ এবং একটি লিগ্যাসি মাইক্রোফ্রন্টেন্ড Vue-তে রয়েছে। ব্রাউজার-নেটিভ অ্যাবস্ট্রাকশন যেমন Custom Elements (Web Components) একটি স্ট্যান্ডার্ড DOM API-এর পিছনে এই পার্থক্যগুলি লুকাতে সাহায্য করে।

টিম কোডবেসের মধ্যে শক্তিশালী বিচ্ছিন্নতা আরেকটি মূল লক্ষ্য। আদর্শভাবে, মাইক্রোফ্রন্টেন্ডগুলি জাভাস্ক্রিপ্ট রানটাইম বা গ্লোবাল ভেরিয়েবল শেয়ার করে না। প্রতিটি বান্ডেল স্বয়ংসম্পূর্ণ, নিজস্ব নির্ভরতা লোড করে এবং অন্যদের থেকে লুকানো অবস্থার উপর নির্ভর করে না। এটি দুর্ঘটনাজনিত সংযোগ হ্রাস করে এবং স্বাধীন স্থাপনাগুলিকে অনেক বেশি বাস্তবসম্মত করে তোলে।

নামকরণের দ্বন্দ্ব এড়াতে, দলগুলি প্রায়শই স্পষ্ট নামস্থানের বিষয়ে একমত হয় CSS ক্লাস, DOM ইভেন্ট, লোকালস্টোরেজ কী, কুকিজ এমনকি কাস্টম এলিমেন্ট ট্যাগ নামের জন্য। উদাহরণস্বরূপ, একটি চেকআউট টিম জিনিসের সাথে প্রিফিক্স যুক্ত করতে পারে chk- অথবা এর মতো ট্যাগ ব্যবহার করুন <blue-buy>, যখন একটি সুপারিশ দল ব্যবহার করে rec- or <green-recos>। এক নজরে, DOM আপনাকে বলে দেয় কোন জিনিসটির মালিক কে।

আরেকটি নীতি হল কাস্টম গ্লোবাল API-এর চেয়ে নেটিভ ব্রাউজার ক্ষমতাকে অগ্রাধিকার দেওয়া।। একটি সর্ব-উদ্দেশ্যমূলক PubSub সিস্টেম আবিষ্কার করার পরিবর্তে, আপনি স্ট্যান্ডার্ড DOM ইভেন্টের উপর নির্ভর করতে পারেন, CustomEvent, রাউটিংয়ের জন্য history API অথবা ইন্টিগ্রেশন লেয়ার হিসেবে DOM নিজেই। যখনই আপনার সত্যিই একটি শেয়ার্ড API প্রয়োজন, তখন এটি যতটা সম্ভব ছোট এবং স্থিতিশীল রাখুন।

পরিশেষে, প্রথম দিন থেকেই স্থিতিস্থাপকতা নকশার অংশ হওয়া উচিত।। জাভাস্ক্রিপ্ট ধীর, ব্যর্থ বা ব্লক থাকা অবস্থায়ও প্রতিটি মাইক্রোফ্রন্টেন্ডের কিছু মান থাকা উচিত। সার্ভার-সাইড রেন্ডারিং, প্রগতিশীল বর্ধন এবং স্কেলেটন স্ক্রিনের মতো কৌশলগুলি দুর্বল নেটওয়ার্ক পরিস্থিতিতেও অনুভূত কর্মক্ষমতা উচ্চ রাখতে সহায়তা করে।

এই প্রসঙ্গে "আধুনিক ওয়েব অ্যাপ্লিকেশন" কী?

প্রতিটি ওয়েবসাইটের জন্য মাইক্রোফ্রন্টেন্ড বা জটিল ব্রাউজার ইন্টিগ্রেশন কৌশলের প্রয়োজন হয় না।। একটি ভালো মানসিক মডেল আসে "ডকুমেন্টস-টু-অ্যাপ্লিকেশনস কন্টিনাম" থেকে: বাম দিকে আপনার বেশিরভাগ স্ট্যাটিক ডকুমেন্ট একসাথে লিঙ্ক করা আছে; ডানদিকে আপনার অনলাইন ফটো এডিটরের মতো সম্পূর্ণ ইন্টারেক্টিভ অ্যাপ রয়েছে।

যদি আপনার প্রকল্পটি স্ট্যাটিক ডকুমেন্টের কাছাকাছি হয়, তাহলে একটি সাধারণ সার্ভার-রেন্ডার করা রচনা প্রায়শই যথেষ্ট।। সার্ভার বিভিন্ন উৎস থেকে HTML টুকরো সংগ্রহ করে, সেগুলিকে একসাথে সেলাই করে ব্রাউজারে পাঠায়। আপডেটগুলি পূর্ণ পৃষ্ঠা লোড বা ছোট Ajax ইনজেকশনের মাধ্যমে ঘটে, এবং এটি পুরোপুরি ঠিক আছে।

যখন আপনি আরও গতিশীল, অ্যাপের মতো অভিজ্ঞতার দিকে এগিয়ে যান— তাৎক্ষণিক প্রতিক্রিয়া, অফলাইনে কাজ করা, আশাবাদী UI আপডেট — বিশুদ্ধ সার্ভার-সাইড ইন্টিগ্রেশন যথেষ্ট নয়। আপনার ক্লায়েন্ট-সাইড কম্পোজিশন, স্টেট ম্যানেজমেন্ট এবং রাউটিং প্রয়োজন। এখানেই মাইক্রোফ্রন্টেন্ড আকর্ষণীয় হয়ে ওঠে: তারা আপনাকে অনেক টিমের মধ্যে সেই জটিলতা স্কেল করার একটি উপায় দেয়।

উল্লম্ব সংগঠন এবং ডোমেন-চালিত স্লাইস

একটি সাধারণ সুপারিশ হল প্রযুক্তিগত স্তরের পরিবর্তে ব্যবসায়িক ডোমেনের সাথে মাইক্রোফ্রন্টেন্ডগুলিকে সারিবদ্ধ করা।ব্যবহারকারীর ভ্রমণের পরিপ্রেক্ষিতে চিন্তা করুন: "কার্ট", ​​"পণ্যের বিবরণ", "অ্যাডমিন ব্যবহারকারী", "কোর্স সময়সূচী", "ছাত্রদের রেকর্ড", "চালান", ইত্যাদি।

এই ডোমেনগুলির প্রতিটি একটি সুনির্দিষ্ট দায়িত্ব সহ নিজস্ব মাইক্রোফ্রন্টেন্ড হয়ে উঠতে পারে। একটি বিশ্ববিদ্যালয় ব্যবস্থায়, একটি অ্যাপ ছাত্র প্রোফাইল, অন্যটি কর্মী প্রোফাইল, তৃতীয়টি কোর্সের সময়সূচী এবং অন্যটি পরীক্ষার ফলাফলের UI পরিচালনা করতে পারে। তারা একটি শেল এবং সম্ভবত কিছু স্টাইলিং ভাগ করে, তবে প্রতিটি স্থাপনার দৃষ্টিকোণ থেকে একটি স্বাধীন অ্যাপ্লিকেশন।

ভালো স্লাইসিং আপনার ব্যাকএন্ড মাইক্রোসার্ভিসেসের সীমাবদ্ধ প্রেক্ষাপটও বিবেচনা করে।। আদর্শভাবে, "বিলিং" এর জন্য মাইক্রোফ্রন্টেন্ড মূলত বিলিং মাইক্রোসার্ভিসেসের সাথে কথা বলে, "ক্যাটালগ" ফ্রন্টএন্ড ক্যাটালগ পরিষেবাগুলির সাথে কথা বলে, ইত্যাদি। এটি প্রতিটি উল্লম্ব স্লাইসকে সুসংহত রাখে এবং ক্রস-টিম নির্ভরতা হ্রাস করে।

প্রযুক্তিগত ইন্টিগ্রেশন: API এবং ওয়েব উপাদান হিসেবে DOM

ব্রাউজার-সাইড মাইক্রোফ্রন্টেন্ড আর্কিটেকচারে, DOM নিজেই প্রায়শই প্রাথমিক ইন্টিগ্রেশন API হিসেবে কাজ করে।। একে অপরের জাভাস্ক্রিপ্ট সরাসরি কল করার পরিবর্তে, দলগুলি HTML উপাদান, বৈশিষ্ট্য এবং ইভেন্টের মাধ্যমে কার্যকারিতা প্রকাশ করে।

কাস্টম এলিমেন্ট (ওয়েব কম্পোনেন্টের অংশ) এর জন্য একটি শক্তিশালী আদিম. একটি দল যে কোনও ফ্রেমওয়ার্ক ব্যবহার করে একটি বৈশিষ্ট্য তৈরি করতে পারে এবং তারপর এটিকে একটি কাস্টম ট্যাগ হিসাবে মোড়ানো করতে পারে, উদাহরণস্বরূপ <order-minicart></order-minicart>। ঐ উপাদানের পাবলিক চুক্তি তার ট্যাগ নাম, বৈশিষ্ট্য এবং নির্গত ইভেন্ট দ্বারা সংজ্ঞায়িত করা হয়, এর অভ্যন্তরীণ বাস্তবায়ন দ্বারা নয়।

কাস্টম এলিমেন্টস v1 এর জন্য ব্রাউজার সাপোর্ট এখন সমস্ত প্রধান ব্রাউজারে শক্তিশালী।, যার অর্থ আপনার খুব কমই পলিফিলের প্রয়োজন হয়। বেশিরভাগ মূলধারার ফ্রেমওয়ার্ক - React, Vue, Angular, Svelte, Preact - কাস্টম উপাদানগুলিকে রেন্ডার বা এম্বেড করতে পারে যেন সেগুলি নিয়মিত HTML ট্যাগ, এবং তাদের অনেকগুলিকে একটি কাস্টম উপাদানেও কম্পাইল করা যেতে পারে।

ইন্টিগ্রেশন প্যাটার্নটি দেখতে এরকম কিছু দেখাচ্ছে: একটি "পণ্য পৃষ্ঠা" মাইক্রোফ্রন্টেন্ড সিদ্ধান্ত নেয় যে পৃষ্ঠায় কোন বৈশিষ্ট্যগুলি প্রদর্শিত হবে (নির্বাচক, কেনার বোতাম, মিনি-কার্ট, সুপারিশ)। এটি কাস্টম উপাদানগুলিকে ইনজেক্ট করে যেমন <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>। এই বৈশিষ্ট্যগুলির মালিকানাধীন দলগুলি তাদের উপাদানগুলি নিবন্ধন করে customElements.define এবং জীবনচক্র কলব্যাক বাস্তবায়ন করুন যেমন connectedCallback or attributeChangedCallback.

যখন কোনও পণ্যের ভেরিয়েন্ট পরিবর্তন হয়, তখন পৃষ্ঠাটি হয় উপাদানটি পুনরায় তৈরি করতে পারে অথবা কেবল তার বৈশিষ্ট্যগুলি আপডেট করতে পারে।। যদি কম্পোনেন্টটি প্রাসঙ্গিক বৈশিষ্ট্যগুলি পর্যবেক্ষণ করে, তবে এটি নিজেকে পুনরায় রেন্ডার করতে পারে। অভ্যন্তরীণভাবে, কম্পোনেন্টটি টেমপ্লেট স্ট্রিং, React, Vue, অথবা যেকোনো রেন্ডারিং ইঞ্জিন ব্যবহার করতে পারে; ইন্টিগ্রেটরকে চিন্তা করার প্রয়োজন নেই।

ক্লায়েন্ট-সাইড যোগাযোগ: ইভেন্ট এবং DOM সম্পর্ক

একমুখী "ডেটা ইন" পরিস্থিতিতে অ্যাট্রিবিউট পাস করা ভালো কাজ করে, কিন্তু অনেক বাস্তব মিথস্ক্রিয়ার জন্য উপাদানগুলিকে তাদের পরিবেশ বা ভাইবোনদের সাথে কথা বলতে হয়। একটি সাধারণ উদাহরণ হল একটি "কিনুন" বোতাম যা কোনও আইটেম যোগ করা হলে মিনি-কার্টকে অবহিত করতে হবে।

একটি কাস্টম গ্লোবাল ইভেন্ট বাস তৈরির পরিবর্তে, আপনি ব্রাউজার ইভেন্টের উপর নির্ভর করতে পারেন. উপাদান প্রেরণ CustomEvent DOM ট্রি জুড়ে বুদবুদ তৈরির উদাহরণ। একটি প্যারেন্ট এলিমেন্ট বা এমনকি window সেই ঘটনাগুলি শুনতে এবং প্রতিক্রিয়াগুলি সাজাতে পারে।

উদাহরণস্বরূপ, বাই বোতামটি এমন একটি ইভেন্ট নির্গত করতে পারে যেমন blue:basket:changed বর্তমান কার্ট পেলোড সহ. মিনি-কার্টটি সেই ইভেন্টে সাবস্ক্রাইব করে window অথবা একটি শেয়ার্ড কন্টেইনার এলিমেন্টে ব্যবহার করা হয় এবং যখনই এটি চালু হয় তখন এর অভ্যন্তরীণ অবস্থা রিফ্রেশ করে।

এই পদ্ধতিটি উপাদানগুলিকে স্বাধীন রাখে: বাই বোতামটি জানে না যে কে, যদি কেউ থাকে, তার ইভেন্টগুলির জন্য শোনে। এটি কেবল তার চুক্তি পূরণ করে। এবং মিনি-কার্টটি কেবল ইভেন্টের শব্দার্থবিদ্যার উপর নির্ভর করে, অন্যান্য খণ্ডগুলির বাস্তবায়ন বিবরণের উপর নয়।

সার্ভার-সাইড রেন্ডারিং এবং সার্বজনীন উপাদান

যদি আপনি প্রথম রঙের পারফরম্যান্স, SEO অথবা জাভাস্ক্রিপ্ট ব্যর্থ হলে স্থিতিস্থাপকতার বিষয়ে চিন্তা করেন, তাহলে সার্ভার-সাইড রেন্ডারিং (SSR) অপরিহার্য।। JS বান্ডেল ডাউনলোড এবং রান করার পরেই পিওর ক্লায়েন্ট-সাইড ওয়েব কম্পোনেন্টগুলি প্রদর্শিত হয়, যার অর্থ ধীর নেটওয়ার্কগুলিতে একটি সাদা পর্দা হতে পারে।

একটি বাস্তবসম্মত সমাধান হল কাস্টম এলিমেন্টগুলিকে সার্ভার-সাইড ইনক্লুড (SSI/ESI) এর সাথে একত্রিত করা।। প্রতিটি মাইক্রোফ্রন্টেন্ড একটি HTTP এন্ডপয়েন্ট প্রকাশ করে যা তার খণ্ডের জন্য HTML ফেরত দেয়, উদাহরণস্বরূপ /blue-buy?sku=t_porsche। শেল বা হোস্ট অ্যাপ্লিকেশন দ্বারা রেন্ডার করা মূল পৃষ্ঠায় স্থানধারক থাকে যেমন <!--#include virtual="/blue-buy?sku=t_porsche" --> যা ওয়েব সার্ভার (প্রায়শই nginx) ব্রাউজারে প্রতিক্রিয়া পাঠানোর আগে প্রসারিত করে।

ব্রাউজারে রানটাইমের সময়, একই কাস্টম উপাদানটি হাইড্রেটেড বা পুনরায় চালু করা হয় একবার এর JS বান্ডেল লোড হয়ে গেলে। এটি আপনাকে একটি "সর্বজনীন" উপাদান দেয়: এটি গতি এবং SEO এর জন্য সার্ভারে রেন্ডার করতে পারে, তারপর ক্লায়েন্টে একটি সম্পূর্ণ ইন্টারেক্টিভ কাস্টম উপাদানের মতো আচরণ করতে পারে।

অন্তর্ভুক্ত থাকা SSR-এর একটি অসুবিধা হল সবচেয়ে ধীর খণ্ডটি মোট প্রতিক্রিয়া সময় নির্ধারণ করে। খণ্ড স্তরে ক্যাশিং প্রায় বাধ্যতামূলক। ব্যয়বহুল, অত্যন্ত ব্যক্তিগতকৃত টুকরো (যেমন সুপারিশ) এর জন্য আপনি সার্ভার-সাইড রেন্ডারিং এড়িয়ে যেতে পারেন এবং ক্লায়েন্টে অ্যাসিঙ্ক্রোনাসভাবে লোড করতে পারেন।

লেআউটের ঝামেলাপূর্ণ পরিবর্তন এড়াতে স্কেলিটন স্ক্রিনগুলি একটি ভালো আপস।। একটি খণ্ড সার্ভারে একটি ধূসর রঙের স্থানধারক তৈরি করতে পারে যার আকার চূড়ান্ত কন্টেন্টের প্রায় সমান। যখন আসল ডেটা ক্লায়েন্ট-সাইডে পৌঁছায়, তখন বড় রিফ্লো ছাড়াই কঙ্কালটি অদলবদল করা হয়।

ডেটা লোডিং এবং অনুভূত কর্মক্ষমতা

একটি মাইক্রোফ্রন্টেন্ড জগতে আপনাকে সাবধানে ভাবতে হবে যে কোথা থেকে এবং কখন ডেটা আনা হবে। আপনি সার্ভার-সাইড, ক্লায়েন্ট-সাইড সবকিছু আনতে পারেন, অথবা একটি হাইব্রিড ব্যবহার করতে পারেন। প্রতিটি পছন্দ ক্যাশিং কৌশল, সময়-থেকে-ইন্টারেক্টিভ এবং অনুভূত গতিকে প্রভাবিত করে।

সার্ভার-সাইডে স্বাভাবিকভাবেই প্রতি খণ্ডে সার্ভার-সাইড ফেচগুলিকে উৎসাহিত করা অন্তর্ভুক্ত থাকে। প্রতিটি মাইক্রোফ্রন্টেন্ড "তার" ব্যাকএন্ড পরিষেবাগুলির সাথে কথা বলে, HTML রেন্ডার করে এবং শেলে ফেরত পাঠায়। সেই HTML অন্যান্য টুকরো থেকে স্বাধীনভাবে ক্যাশে করা যেতে পারে, যা লগইন বা পণ্য তালিকার মতো উচ্চ-ট্র্যাফিক অংশগুলিকে স্কেল করতে সহায়তা করে।

ক্লায়েন্টে ডেটা লোড করার সময় আপনার প্রগতিশীল রাজ্যের জন্য বাজেট করা উচিত: প্রাথমিক স্কেলিটন, অ্যাট্রিবিউট পরিবর্তনের সময় দ্রুত আপডেট এবং API গুলি ধীর গতিতে থাকলে ফলব্যাক আচরণ। কখনও কখনও নতুন ডেটা না আসা পর্যন্ত পুরানো ডেটা জায়গায় রাখা প্রতিটি ছোটখাটো পরিবর্তনের জন্য একটি স্কেলিটন ফ্ল্যাশ করার চেয়ে দৃশ্যত কম বিরক্তিকর।

প্রতিক্রিয়া সহ মাইক্রোফ্রন্টেন্ড

ইকোসিস্টেম এবং রেন্ডারিং অপ্টিমাইজেশনের কারণে মাইক্রোফ্রন্টেন্ড বাস্তবায়নের জন্য রিঅ্যাক্ট একটি খুব জনপ্রিয় পছন্দ।। ভার্চুয়াল DOM এবং ডিফিং প্রপ পরিবর্তন বা গ্লোবাল স্টেটের উপর ভিত্তি করে UI এর ছোট অংশ আপডেট করা সহজ করে তোলে এবং আপনি React অ্যাপগুলিকে স্বতন্ত্র SPA বা কাস্টম এলিমেন্ট হিসাবে বান্ডিল করতে পারেন।

React সংস্করণগুলির মধ্যে স্থানান্তর ক্রমবর্ধমান এবং তুলনামূলকভাবে ব্যথাহীন হতে থাকে। অন্যান্য কিছু ফ্রেমওয়ার্কের তুলনায়, যা অনেক স্বাধীন দল পৃথক মাইক্রোফ্রন্টেন্ড বজায় রাখলে সহায়ক। একই সময়ে একটি প্রধান সংস্করণ থেকে অন্যটিতে যাওয়ার জন্য আপনার সমস্ত টুকরোর প্রয়োজন নেই।

অন্যদিকে, বিকেন্দ্রীভূত React মাইক্রোফ্রন্টেন্ডগুলি রিসোর্স স্প্রেল তৈরি করতে পারে।: একাধিক দল, একাধিক CI/CD পাইপলাইন, অনেক বান্ডেল, অনেক ছোট রিপো। বিল্ড, প্রভিশনিং এবং পর্যবেক্ষণের জন্য পর্যাপ্ত অটোমেশন ছাড়া, সেই ওভারহেড পরিচালনা করা কঠিন হয়ে পড়ে।

আরেকটি বাস্তব সমস্যা হল বান্ডিলের আকার। যদি প্রতিটি মাইক্রোফ্রন্টেন্ড React এবং শেয়ার্ড লাইব্রেরির নিজস্ব কপি পাঠায়, তাহলে মোট ডাউনলোডের আকার বিস্ফোরিত হতে পারে, বিশেষ করে যখন একটি পৃষ্ঠা রেন্ডার করার জন্য বেশ কয়েকটি টুকরো প্রয়োজন হয়। মডিউল ফেডারেশন (রানটাইমে নির্ভরতা ভাগ করে নেওয়ার জন্য) অথবা টিম জুড়ে একটি দৃঢ়ভাবে সারিবদ্ধ স্ট্যাকের মতো সমাধানগুলি এটিকে কমাতে পারে।

অ্যাঙ্গুলার সহ মাইক্রোফ্রন্টেন্ড

অ্যাঙ্গুলার আরও মতামতপ্রণোদিত মাইক্রোফ্রন্টেন্ড সেটআপগুলিতে নিজেকে সুন্দরভাবে ধার দেয়, বিশেষ করে যখন আপনি মনোরেপো এবং তাদের চারপাশের টুলিং ব্যবহার করেন (যেমন Nx)। কৌণিক কর্মক্ষেত্রগুলি প্রকল্প এবং লাইব্রেরিতে সংগঠিত হয়, যা একটি বৃহৎ সমাধানকে একাধিক অ্যাপ এবং শেয়ার্ড লাইব্রেরিতে বিভক্ত করা স্বাভাবিক করে তোলে।

অ্যাঙ্গুলার ১২ এবং ওয়েবপ্যাক ৫ এর পর থেকে, মডিউল ফেডারেশন প্রথম শ্রেণীর নাগরিক হয়ে উঠেছে. একটি অ্যাঙ্গুলার প্রজেক্টকে স্কিম্যাটিক কমান্ড ব্যবহার করে হোস্ট বা রিমোট হিসেবে কনফিগার করা যেতে পারে, প্রয়োজনীয় ওয়্যারিং আপ করা যেতে পারে webpack.config.js এবং আপনার জন্য বুটস্ট্র্যাপ লজিক।

এই মডেলে, "হোস্ট" অ্যাঙ্গুলার অ্যাপটি শেল হিসেবে কাজ করে যা নেভিগেশন, শেয়ার্ড স্টেট এবং ডিপেন্ডেন্সি শেয়ারিংকে সুসংগঠিত করে। স্বতন্ত্র অ্যাঙ্গুলার মাইক্রোফ্রন্টেন্ড (রিমোট) অ্যাঙ্গুলার মডিউলগুলিকে প্রকাশ করে যা হোস্ট মডিউল ফেডারেশনের মাধ্যমে গতিশীলভাবে অলসভাবে লোড করতে পারে।

সাধারণ অ্যাঙ্গুলার রাউটিং প্রিমিটিভগুলি এখনও প্রযোজ্য. একটি মাইক্রোফ্রন্টেন্ডের মধ্যে, আপনি ব্যবহার করেন RouterModule.forChild চাইল্ড রুট সংজ্ঞার জন্য যাতে হোস্টই একমাত্র ব্যবহার করে forRoot। এইভাবে, রাউটার দ্বন্দ্ব ছাড়াই একাধিক অ্যাঙ্গুলার অ্যাপ একটি ইউআরএল স্পেসের অধীনে সহাবস্থান করতে পারে।

বাস্তবে মডিউল ফেডারেশন (কৌণিক উদাহরণ)

ওয়েবপ্যাক মডিউল ফেডারেশন হল একটি ওয়েবপ্যাক ৫ বৈশিষ্ট্য যা রানটাইমে একাধিক বিল্ডকে কোড শেয়ার করার অনুমতি দেয়। একটি বিল্ড (হোস্ট) গতিশীলভাবে অন্যান্য বিল্ড (রিমোট) দ্বারা প্রকাশিত মডিউলগুলিকে একটি ছোট ম্যানিফেস্ট ফাইলের মাধ্যমে লোড করে, সাধারণত নামকরণ করা হয় remoteEntry.js.

অ্যাঙ্গুলারে আপনি এটি বেশ দ্রুত স্ক্যাফোল্ড করতে পারেন. উদাহরণস্বরূপ, আপনি একটি হোস্ট অ্যাপ তৈরি করতে পারেন (host-app) এবং তারপর একটি স্কিম্যাটিক চালান যেমন ng add @angular-architects/module-federation --project host-app --port 4200। এটি একটি ModuleFederationPlugin কনফিগারেশন, বুটস্ট্র্যাপিং ফাইল এবং রানটাইম লজিক সেট আপ করে।

এরপর আপনি দুটি রিমোট অ্যাঙ্গুলার অ্যাপ তৈরি করবেন: একটি পণ্য ক্যাটালগের জন্য এবং একটি শপিং কার্টের জন্য।প্রতিটি অ্যাপের নিজস্ব পোর্ট থাকে (যেমন 4201 এর জন্য products-app, 4202 জন্য cart-app) এবং এর নিজস্ব মডিউল ফেডারেশন কনফিগারেশন। ইন webpack.config.js আপনার ব্যবহৃত প্রতিটি রিমোটের exposes একটি মডিউল (সাধারণত প্রধান অ্যাপ মডিউল) একটি কী এর অধীনে প্রকাশ করতে যেমন ./ProductsModule or ./CartModule.

হোস্ট শেল তারপর সেই রুটগুলি সংজ্ঞায়িত করে যেগুলি অলসভাবে সেই দূরবর্তী মডিউলগুলি লোড করে মাধ্যমে loadRemoteModule থেকে @angular-architects/module-federationউদাহরণস্বরূপ, নেভিগেট করা /products থেকে একটি গতিশীল আমদানি ট্রিগার করে http://localhost:4201/remoteEntry.js এবং লোড ProductsModule; /cart কার্ট রিমোটের ক্ষেত্রেও একই কাজ করে।

ক্যাটালগ মাইক্রোফ্রন্টেন্ডের ভিতরে আপনার একটি থাকতে পারে ProductsComponent যা আইটেমের একটি টেবিল রেন্ডার করে, একটি থেকে তথ্য পড়া PRODUCTS_CATALOG ধ্রুবক এবং একটি "কার্টে যোগ করুন" বোতাম অফার করছে। ক্লিক করলে, এটি আইটেমটি ধরে রাখে localStorage একটি "কার্ট" কী এর অধীনে, পণ্যটি ইতিমধ্যেই বিদ্যমান থাকলে পরিমাণ বৃদ্ধি করে।

কার্ট মাইক্রোফ্রন্টেন্ড তারপর একই থেকে পড়ে localStorage চাবি, পণ্যের নাম, মূল্য, পরিমাণ এবং মোট সহ একটি টেবিল প্রদর্শন করে এবং একটি "ক্লিয়ার কার্ট" বোতাম অফার করে যা স্টোরেজটি মুছে দেয় এবং এর অভ্যন্তরীণ অবস্থা পুনরায় সেট করে। এটি দুটি স্বাধীন অ্যাপের মধ্যে শক্ত সংযোগ ছাড়াই অবস্থা ভাগ করে নেওয়ার একটি সহজ কিন্তু দৃষ্টান্তমূলক উপায়।

হোস্ট শেল তৈরি: লেআউট, হোম এবং নেভিগেশন

মাইক্রোফ্রন্টেন্ড জুড়ে ভালো ব্যবহারকারীর অভিজ্ঞতার জন্য একটি শক্ত হোস্ট শেল অত্যন্ত গুরুত্বপূর্ণ।। এটি সাধারণত গ্লোবাল লেআউট (হেডার, ফুটার, সাইডবার), শীর্ষ-স্তরের রাউটিং এবং কখনও কখনও গ্লোবাল স্টেটের মতো প্রমাণীকরণ বা বৈশিষ্ট্য পতাকার মালিক।

কৌণিক উদাহরণে, হোস্ট একটি সংজ্ঞায়িত করে LayoutComponent যা একটি হেডার এবং একটি নেস্টেড রেন্ডার করে router-outlet। হেডারটি তার নিজস্ব HeaderModule এবং অ্যাঙ্গুলারের মাধ্যমে হোম পেজ, পণ্য তালিকা এবং কার্টে নেভিগেশন লিঙ্কগুলি প্রকাশ করে routerLinkরুট পাথগুলিকে একটি enum-এ কেন্দ্রীভূত করা যেতে পারে যেমন RoutesPath জাদুর সুতো এড়াতে।

লেআউট রাউটিং মডিউলটি একটি প্যারেন্ট রুট সেট আপ করে যার সাথে LayoutComponent এর উপাদান হিসেবে এবং এর জন্য চাইল্ড রুটগুলি সংজ্ঞায়িত করে /home, /products এবং /cart. দ্য /home পথ একটি স্থানীয় লোড করে HomeModule; অন্যরা ব্যবহার করে loadRemoteModule রান টাইমে অ্যাঙ্গুলার মাইক্রোফ্রন্টেন্ড টানতে।

হোস্টের মধ্যে, একটি SharedModule পুনর্ব্যবহারযোগ্য বিল্ডিং ব্লক সংগ্রহ করতে পারে যেমন হেডার, লেআউট, সাধারণ নির্দেশিকা এবং ধ্রুবক। এই মডিউলটি রুটে আমদানি করা যেতে পারে AppModule সাথে AppRoutingModule, যা লেআউট রাউটিং কনফিগারেশনের খালি পথ নির্দেশ করে।

Next.js এবং মাইক্রোফ্রন্টেন্ড

Next.js, প্রোডাকশন-গ্রেড রিঅ্যাক্ট ফ্রেমওয়ার্ক হিসেবে, একটি মাইক্রোফ্রন্টেন্ড পদ্ধতির সাথেও ভালো কাজ করে।, বিশেষ করে যেহেতু এটি ওয়েবপ্যাক ৫ গ্রহণ করেছে এবং তাই মডিউল ফেডারেশন সমর্থন করে। SSR, ক্রমবর্ধমান স্ট্যাটিক পুনর্জন্ম এবং রাউটিংয়ের উপর এর ফোকাস এটিকে শেল, পৃথক মাইক্রোফ্রন্টেন্ড, অথবা উভয়ের জন্য একটি ভাল প্রার্থী করে তোলে।

Next.js-এ মাইক্রোফ্রন্টেন্ড বাস্তবায়নের জন্য আপনাকে সাধারণত ওয়েবপ্যাক স্তরে মডিউল ফেডারেশন কনফিগার করতে হয়।, নির্দিষ্ট পৃষ্ঠা বা উপাদানগুলিকে রিমোট হিসাবে প্রকাশ করা এবং হোস্ট থেকে সেগুলি গ্রহণ করা। যদিও মডিউল ফেডারেশন "শুধু" একটি জাভাস্ক্রিপ্ট বান্ডলার বৈশিষ্ট্য, আপনি এটিকে একটি স্থাপত্য প্যাটার্ন হিসাবে ভাবতে পারেন: এটি আপনাকে বিভিন্ন দলের মালিকানাধীন কোড গতিশীলভাবে লোড করতে দেয়, সময়ের আগে সবকিছু একসাথে বান্ডেল না করে।

ওয়েবপ্যাক ৫ ছাড়া লিগ্যাসি Next.js ভার্সনের জন্য আপনার এক্সটার্নাল অ্যাডাপ্টারের প্রয়োজন হবে ফেডারেশন সাপোর্ট সক্ষম করতে। পরবর্তী ১০.২ থেকে, ওয়েবপ্যাক ৫ সাপোর্ট বিল্ট-ইন করা হয়েছে, যা সেটআপকে নাটকীয়ভাবে সহজ করে তোলে।

একক-এসপিএ এবং অন্যান্য মাইক্রোফ্রন্টেন্ড ফ্রেমওয়ার্ক

সিঙ্গেল-এসপিএ হল মাইক্রোফ্রন্টেন্ডের জন্য আরেকটি সুপরিচিত সমাধান, বিশেষ করে রিঅ্যাক্ট ইকোসিস্টেমে।। এটি একই পৃষ্ঠায় একাধিক স্বাধীন অ্যাপ সাজানোর উপর দৃষ্টি নিবদ্ধ করে, প্রতিটি বর্তমান রুটের উপর ভিত্তি করে নিজস্ব DOM নোডে মাউন্ট করা হয়।

Single‑SPA ব্যবহার করে আপনি একাধিক React অ্যাপ্লিকেশন (অথবা এমনকি React, Vue, Angular মিশ্রিত) সহাবস্থান করতে পারেন।। ব্যবহারকারী যখন নেভিগেট করে তখন প্রতিটি মাইক্রোফ্রন্টেন্ড কখন বুটস্ট্র্যাপ, মাউন্ট বা আনমাউন্ট করতে হবে তা ফ্রেমওয়ার্ক পরিচালনা করে এবং আপনি এটিকে আপনার রাউটিং কৌশলের সাথে সংযুক্ত করেন (উদাহরণস্বরূপ, প্রতিটি খণ্ডে React Router ব্যবহার করে)।

সিঙ্গেল-এসপিএ এবং মডিউল ফেডারেশনের মধ্যে নির্বাচন করার সময়, দলগুলি প্রায়শই তাদের বান্ডলার/টুলিং পছন্দগুলি বিবেচনা করে। মডিউল ফেডারেশন ওয়েবপ্যাকের সাথে গভীরভাবে সংহত হয় (এবং, ক্রমবর্ধমানভাবে, Rspack বা Rollup এর মতো বিকল্পগুলির সাথে তারা সমর্থন যোগ করে)। অন্যদিকে, Single-SPA, বান্ডেল শেয়ারিংয়ের চেয়ে রানটাইম অর্কেস্ট্রেশন সম্পর্কে বেশি, তাই আপনি অন্যান্য উপায়ে কোড শেয়ারিং পরিচালনা করার সময় বিভিন্ন বিল্ড টুলের সাথে এটি ব্যবহার করতে পারেন।

মাইক্রোফ্রন্টেন্ডের উদ্দেশ্য, বৈশিষ্ট্য এবং সুবিধা

মাইক্রোফ্রন্টেন্ডের মূল লক্ষ্য হলো সমন্বয়ের কারণে ভেঙে না পড়ে অনেক দল জুড়ে ফ্রন্টএন্ড ডেভেলপমেন্ট স্কেল করা।। সিঙ্ক্রোনাইজড রিলিজ সহ একটি বিশাল কোডবেসের পরিবর্তে, আপনি ছোট স্বাধীনভাবে স্থাপনযোগ্য ইউনিট পাবেন।

মূল লক্ষ্যগুলি সাধারণত অন্তর্ভুক্ত করে একাধিক দলকে সমান্তরালভাবে কাজ করতে সক্ষম করে, UI এর বিভিন্ন অংশের জন্য স্বাধীন স্থাপনা সমর্থন করে, বিভিন্ন প্রযুক্তি যেখানে যুক্তিসঙ্গত হয় সেখানে ব্যবহারের নমনীয়তা বজায় রাখে এবং প্রতিটি কোডবেসের আকার এবং জটিলতা হ্রাস করে রক্ষণাবেক্ষণযোগ্যতা উন্নত করে।

এই ধরনের স্থাপত্যের সাধারণ বৈশিষ্ট্য হল শেয়ার্ড লাইব্রেরির মাধ্যমে উপাদান পুনঃব্যবহার, একটি অ্যাপ্লিকেশন শেলের মাধ্যমে মডুলার ইন্টিগ্রেশন, মাইক্রোফ্রন্টেন্ড প্রতি স্বাধীন পাইপলাইন, সিডিএন এবং ক্যাশিংয়ের মাধ্যমে কর্মক্ষমতা অপ্টিমাইজেশন, কেন্দ্রীভূত সুরক্ষা পরিচালনা এবং শক্তিশালী পর্যবেক্ষণযোগ্যতা।

ব্যবসায়িক দৃষ্টিকোণ থেকে, সুবিধাগুলি যথেষ্ট: আরও বেশি টিমের সাথে ডেভেলপমেন্ট স্কেল আরও ভালো হয়, ব্যর্থতাগুলি আরও ভালোভাবে আলাদা করা যায়, প্রতিটি ডোমেনের জন্য বৈশিষ্ট্যগুলি রোল আউট বা রোল ব্যাক করা যায় এবং পুরো অ্যাপটি পুনর্লিখনের পরিবর্তে একবারে একটি স্লাইস প্রতিস্থাপন করে লিগ্যাসি ফ্রন্টএন্ড স্ট্যাকগুলি ধীরে ধীরে স্থানান্তরিত করা যেতে পারে।

একটি মাইক্রোফ্রন্টেন্ড আর্কিটেকচারের মূল উপাদানগুলি

যদিও বাস্তবায়নগুলি পরিবর্তিত হয়, বেশিরভাগ মাইক্রোফ্রন্টেন্ড আর্কিটেকচারে কয়েকটি কাঠামোগত উপাদান ভাগ করে নেওয়া হয় যা সবকিছুকে সুসংগত রাখে।

অ্যাপ্লিকেশন শেল (বা ধারক) হল মেরুদণ্ড। এটি বাইরের লেআউট, গ্লোবাল নেভিগেশন, প্রমাণীকরণ, কখনও কখনও গ্লোবাল অবস্থা এবং মাইক্রোফ্রন্টেন্ড লোড বা আনলোড করার জন্য যুক্তির মালিক। ব্রাউজার-ভিত্তিক সেটআপগুলিতে, এটি হল পৃষ্ঠা যা অন্যান্য সমস্ত বান্ডেলগুলিকে টেনে আনে।

প্রতিটি মাইক্রোফ্রন্টেন্ড একটি স্বয়ংসম্পূর্ণ মডিউল যা একটি নির্দিষ্ট ক্ষমতা বাস্তবায়ন করে, যেমন পণ্য ক্যাটালগ, শপিং কার্ট, ব্যবহারকারীর প্রোফাইল বা অ্যাডমিন প্যানেল। এটি একটি ইন্টিগ্রেশন পৃষ্ঠ (রুট, কাস্টম এলিমেন্ট, মডিউল ফেডারেশন রিমোট) প্রকাশ করে এবং সিস্টেমের বাকি অংশ থেকে অভ্যন্তরীণ বিবরণ লুকিয়ে রাখে।

ক্রস-মাইক্রোফ্রন্টেন্ড যোগাযোগের জন্য প্রায়শই একটি ইভেন্ট বাস বা বার্তা ব্যবস্থা উপস্থিত থাকে।। এটি DOM ইভেন্টগুলির উপর একটি সাধারণ বিমূর্তকরণ, একটি কেন্দ্রীভূত Redux স্টোর, অথবা একটি কাস্টম বার্তা ব্রোকার হতে পারে। লক্ষ্য হল প্রকাশ/সাবস্ক্রাইব শব্দার্থবিদ্যাকে আলাদা করা: একটি মাইক্রোফ্রন্টেন্ড ইভেন্টগুলি কে পরিচালনা করে তা না জেনেই নির্গত করে।

শেয়ার্ড লাইব্রেরিগুলি পুনঃব্যবহারযোগ্য UI উপাদান, ইউটিলিটি, ডিজাইন টোকেন এবং সাধারণ ক্লায়েন্ট হোস্ট করে।। মনোরেপো সেটআপে Nx এর মতো টুলগুলি এখানে উজ্জ্বল, যা আপনাকে একাধিক অ্যাপ দ্বারা ব্যবহৃত শেয়ার্ড প্যাকেজগুলিকে জোরপূর্বক সীমানা এবং সামঞ্জস্যপূর্ণ সংস্করণ সহ সংজ্ঞায়িত করতে দেয়।

পর্যবেক্ষণযোগ্যতা সংগ্রাহক এবং সরঞ্জাম (উদাহরণস্বরূপ, ওপেনটেলিমেট্রি ব্যবহার করে) সমস্ত মাইক্রোফ্রন্টেন্ড থেকে লগ, মেট্রিক্স এবং ট্রেস একত্রিত করে, যার ফলে একাধিক খণ্ড বা পরিষেবা বিস্তৃত সমস্যাগুলি নির্ণয় করা সম্ভব হয়।

সিডিএনগুলি ডেলিভারি দিকের ছবিটি সম্পূর্ণ করে, JS বান্ডেল, CSS এবং ব্যবহারকারীদের কাছাকাছি থাকা চিত্রগুলির মতো স্ট্যাটিক সম্পদ ক্যাশিং করে, লেটেন্সি হ্রাস করে এবং অরিজিন সার্ভারগুলি অফলোড করে। মাইক্রোফ্রন্টেন্ড সেটআপে, আপনি প্রায়শই প্রতিটি খণ্ডের সম্পদকে স্বাধীন ক্যাশিং এবং রোলআউটের জন্য তার নিজস্ব CDN পথে হোস্ট করেন।

মাইক্রোফ্রন্টেন্ডের জন্য স্থাপত্য এবং নকশার ধরণ

মাইক্রোফ্রন্টেন্ডের ক্ষেত্রে বিশেষভাবে প্রযোজ্য প্যাটার্নের একটি সমৃদ্ধ ক্যাটালগ রয়েছে, সাধারণত আপনি কীভাবে রচনা, স্থাপন এবং সংযোগ করেন তার দ্বারা সংজ্ঞায়িত করা হয়।

কম্পোনেন্ট-ভিত্তিক কম্পোজিশন মানে ওয়েব কম্পোনেন্ট বা অনুরূপ প্রিমিটিভ থেকে UI তৈরি করা। প্রতিটি উপাদানের একটি একক দায়িত্ব থাকে, স্পষ্ট ইনপুট এবং আউটপুট, এবং পৃথকভাবে পরীক্ষা করা যেতে পারে। একটি উচ্চ-স্তরের রচনা স্তর (যেমন একটি শেল বা অর্কেস্ট্রেশন ফ্রেমওয়ার্ক) সেই উপাদানগুলিকে পূর্ণ পৃষ্ঠাগুলিতে সাজিয়ে তোলে।

ফেডারেশন প্যাটার্ন সম্পূর্ণ প্রয়োগের স্বায়ত্তশাসনের উপর জোর দেয়। প্রতিটি মাইক্রোফ্রন্টেন্ড একটি স্বতন্ত্র অ্যাপ যার নিজস্ব জীবনচক্র এবং দল রয়েছে; শেল বা একটি API গেটওয়ে কেবল অনুরোধ/ডেটা সঠিক খণ্ডে পাঠায়। যোগাযোগ সু-সংজ্ঞায়িত REST API বা ইভেন্টের মাধ্যমে ঘটে।

অ্যাপ্লিকেশন শেল প্যাটার্নটি কার্যকরভাবে "হোস্ট" পদ্ধতির। শেলটি মাইক্রোফ্রন্টেন্ড লোড করে, নেভিগেশন এবং নিরাপত্তার মতো ক্রস-কাটিং সমস্যাগুলি পরিচালনা করে এবং একটি সামঞ্জস্যপূর্ণ চেহারা এবং অনুভূতি নিশ্চিত করে। মডিউল ফেডারেশন বা একক-এসপিএ ভিত্তিক সেটআপগুলির সাথে এটি খুবই সাধারণ।

API গেটওয়ে এবং ব্যাকএন্ড-ফর-ফ্রন্টেন্ড (BFF) প্যাটার্নগুলি সার্ভার সাইডে ফোকাস করে। একটি API গেটওয়ে অনেক ব্যাকএন্ড পরিষেবা, রাউটিং অনুরোধ এবং সুরক্ষা প্রয়োগের সামনে বসে। একজন BFF আরও এগিয়ে যায়: প্রতিটি ফ্রন্টএন্ড (ওয়েব, মোবাইল, IoT) তার চাহিদা অনুসারে নিজস্ব ডেডিকেটেড ব্যাকএন্ড তৈরি করতে পারে।

বিতরণকৃত ডেটা স্টোরেজ প্যাটার্নগুলি স্বীকার করে যে বিভিন্ন মাইক্রোফ্রন্টেন্ড তাদের নিজস্ব ডেটা উৎস পরিচালনা করতে পারে অথবা ক্যাশে। ব্রাউজারে এর অর্থ প্রায়শই পৃথক লোকালস্টোরেজ কী, ইনডেক্সডডিবি ডাটাবেস বা ইন-মেমোরি স্টোর ব্যবহার করা হয়, যখন ব্যাকএন্ডে এর অর্থ প্রতিটি মাইক্রোসার্ভিসে পৃথক ডাটাবেস ব্যবহার করা হয়।

পর্যবেক্ষণযোগ্যতা, স্বাধীন স্থাপনা, অনুভূমিক স্কেলেবিলিটি এবং নিরাপত্তা নিদর্শন অপারেশনাল উদ্বেগগুলি সমাধান করা: প্রতিটি টুকরো কীভাবে পর্যবেক্ষণ করা যায়, বিশ্বব্যাপী বিভ্রাট ছাড়াই কীভাবে সেগুলি স্থাপন করা যায়, কীভাবে লোডের নিচে সেগুলি স্কেল করা যায় এবং কীভাবে ধারাবাহিকভাবে প্রমাণীকরণ/অনুমোদন প্রয়োগ করা যায়।

রাউটিং কম্পোজিশন এবং অলস লোডিং প্যাটার্নগুলি UX এবং পারফরম্যান্সের কেন্দ্রবিন্দু।। একটি মাস্টার রাউটার নির্ধারণ করে যে কোন মাইক্রোফ্রন্টেন্ড কোন পথ পরিচালনা করে এবং প্রতিটি মাইক্রোফ্রন্টেন্ডের নিজস্ব অভ্যন্তরীণ রাউটার থাকে। অলস লোডিং নিশ্চিত করে যে আপনি কেবলমাত্র বর্তমান রুটের জন্য প্রয়োজনীয় টুকরোগুলির জন্য কোড ডাউনলোড করতে পারবেন।

পরিশেষে, ঘটনা-ভিত্তিক যোগাযোগের ধরণগুলি নিশ্চিত করে যে আলগাভাবে সংযুক্ত মাইক্রোফ্রন্টেন্ডগুলি এখনও সমন্বয় করতে পারে ডোমেইন ইভেন্টের মাধ্যমে, সরাসরি নির্ভরতা প্রবর্তন না করে যা মডুলারিটির বিন্দুকে পরাজিত করবে।

কখন মাইক্রোফ্রন্টেন্ড ব্যবহার করবেন (এবং কখন ব্যবহার করবেন না)

সুনির্দিষ্ট কার্যকরী ডোমেন সহ বৃহৎ, জটিল অ্যাপ্লিকেশনগুলিতে মাইক্রোফ্রন্টেন্ডগুলি উজ্জ্বল হয়। ই-কমার্স প্ল্যাটফর্ম, এন্টারপ্রাইজ ম্যানেজমেন্ট সিস্টেম, পৌর পোর্টাল, শিক্ষা প্ল্যাটফর্ম, বৃহৎ স্বাস্থ্য পোর্টাল অথবা এমন যেকোনো পণ্যের কথা ভাবুন যেখানে বিভিন্ন কার্যকরী ক্ষেত্রে অনেক দল কাজ করে।

যখন আপনার একাধিক দল সমান্তরালভাবে কাজ করে তখন এগুলি বিশেষভাবে কার্যকর। যাদের প্রযুক্তিগত পছন্দ, প্রকাশ চক্র এবং অগ্রাধিকারগুলিতে স্বায়ত্তশাসনের প্রয়োজন, অথবা যখন আপনি ধীরে ধীরে একটি লিগ্যাসি ফ্রন্টএন্ড আধুনিকীকরণ করছেন এবং সম্পূর্ণ পুনর্লিখনের সামর্থ্য নেই। আপনি একবারে একটি এলাকাকে একটি নতুন মাইক্রোফ্রন্টএন্ডে খোদাই করতে পারেন এবং এটিকে পুরানো শেলের সাথে একীভূত করতে পারেন।

অ্যাপের বিভিন্ন অংশের স্কেল ভিন্নভাবে করার প্রয়োজন হলে এগুলিও সাহায্য করে।। একটি লগইন বা চেকআউট পৃষ্ঠা অ্যাডমিন কনফিগারেশন স্ক্রিনের তুলনায় অনেক বেশি ট্র্যাফিক পেতে পারে; এই স্লাইসগুলিকে স্বাধীনভাবে স্কেল করলে অবকাঠামোগত খরচ অনেক কমতে পারে।

তবে, মাইক্রোফ্রন্টেন্ডগুলি কোনও বিনামূল্যের মধ্যাহ্নভোজ নয়। এগুলি স্থাপত্য জটিলতা যোগ করে, UX এবং ভাগ করা চুক্তিতে শক্তিশালী সমন্বয় প্রয়োজন, এবং নতুন ব্যর্থতা মোড প্রবর্তন করে (উদাহরণস্বরূপ, একটি অংশ লোড না হওয়া)। একক দল সহ ছোট বা মাঝারি অ্যাপগুলির জন্য, একটি সুগঠিত মনোলিথ প্রায়শই সহজ এবং আরও সাশ্রয়ী হয়।

দলগুলিকে "কাঠামোগত নৈরাজ্য" সম্পর্কেও সতর্ক থাকা উচিত।। যদিও প্রতিটি মাইক্রোফ্রন্টেন্ডের জন্য সম্পূর্ণ ভিন্ন স্ট্যাক ব্যবহার করা টেকনিক্যালি সম্ভব, ফ্রেমওয়ার্কের একটি অনিয়ন্ত্রিত মিশ্রণ নিয়োগ, টুলিং এবং কোড শেয়ারিংকে আরও কঠিন করে তোলে। একটি যুক্তিসঙ্গত স্তরের সারিবদ্ধতা (উদাহরণস্বরূপ, "আমরা একটি React-first দোকান, কিন্তু আমরা নির্দিষ্ট ডোমেনের জন্য Angular অনুমোদন করি") সাধারণত দীর্ঘমেয়াদে আরও ভাল কাজ করে।

মাইক্রোফ্রন্টেন্ডগুলি ব্রাউজারে মাইক্রোসার্ভিসেসের মানসিকতা প্রসারিত করে, দলগুলিকে বড় ফ্রন্টএন্ডগুলিকে স্বায়ত্তশাসিত, ডোমেন-ভিত্তিক অংশে বিভক্ত করার একটি উপায় দেয় যা স্বাধীনভাবে বিকশিত, স্থাপন এবং স্কেল করতে পারে এবং একই সাথে একটি অ্যাপ্লিকেশন শেল, শেয়ার্ড লাইব্রেরি, মডিউল ফেডারেশন, ওয়েব কম্পোনেন্ট বা সিঙ্গেল-এসপিএ-এর মতো অর্কেস্ট্রেশন ফ্রেমওয়ার্কের মাধ্যমে একত্রিত হলে একটি সমন্বিত ব্যবহারকারীর অভিজ্ঞতা তৈরি করতে পারে।