paint-brush
মাইক্রো-ফ্রন্টেন্ড মাইগ্রেশন জার্নি - পার্ট 1: ডিজাইনদ্বারা@isharafeev
1,323 পড়া
1,323 পড়া

মাইক্রো-ফ্রন্টেন্ড মাইগ্রেশন জার্নি - পার্ট 1: ডিজাইন

দ্বারা Ildar Sharafeev13m2023/07/12
Read on Terminal Reader
Read this story w/o Javascript

অতিদীর্ঘ; পড়তে

একটি মাইক্রো-ফ্রন্টেন্ড আর্কিটেকচারে স্থানান্তরিত করার জন্য সাংগঠনিক কাঠামো এবং অপারেশনাল ভিত্তির পরিপ্রেক্ষিতে একটি উল্লেখযোগ্য বিনিয়োগ প্রয়োজন। ডিস্ট্রিবিউটেড মনোলিথ আর্কিটেকচার দিয়ে শুরু করা ভালো হবে যা অলস লোডিং (ডাইনামিক ইম্পোর্ট) এর পরিবর্তে লাভ করবে। বিভিন্ন দল দ্বারা নিয়ন্ত্রিত মালিকানার বিভিন্ন এলাকায় কোড বেস বিভক্ত করার একটি অপরিহার্য প্রয়োজন হবে।
featured image - মাইক্রো-ফ্রন্টেন্ড মাইগ্রেশন জার্নি - পার্ট 1: ডিজাইন
Ildar Sharafeev HackerNoon profile picture

আজকের দ্রুতগতির ডিজিটাল বিশ্বে, যেখানে তত্পরতা এবং পরিমাপযোগ্যতা অত্যন্ত গুরুত্বপূর্ণ, ব্যবসাগুলি ক্রমাগত তাদের ওয়েব অ্যাপ্লিকেশনগুলির কার্যকারিতা এবং রক্ষণাবেক্ষণের উন্নতির উপায় খুঁজছে৷


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


অস্বীকৃতি : আমরা শুরু করার আগে, এটা মনে রাখা গুরুত্বপূর্ণ যে এই নিবন্ধটি আমার ব্যক্তিগত অভিজ্ঞতা শেয়ার করার সময়, আমি AWS বা অন্য কোনো প্রতিষ্ঠানে সরঞ্জাম, প্রযুক্তি, বা নির্দিষ্ট প্রক্রিয়ার কোনো মালিকানা বা অভ্যন্তরীণ বিবরণ প্রকাশ করতে সক্ষম নই।


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


উদ্দেশ্য হল অন্তর্দৃষ্টি এবং শেখা পাঠগুলি প্রদান করা যা বৃহত্তর প্রেক্ষাপটে প্রযোজ্য হতে পারে, কোনো গোপন তথ্য প্রকাশ না করে।

মাইগ্রেশন জন্য প্রেরণা

আমি মার্টিন ফাউলারের ব্লগের নিবন্ধ থেকে মাইক্রো-ফ্রন্টেন্ডস সম্পর্কে শিখেছি (আমি মনে করি আপনার মধ্যে অনেকেই)। এটি একটি কাঠামো-অজ্ঞেয়বাদী পদ্ধতিতে মাইক্রো-ফ্রন্টেন্ড আর্কিটেকচার রচনা করার বিভিন্ন উপায় উপস্থাপন করেছে।


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


একটি মাইগ্রেশন বিবেচনা করার দিকে আমাকে ঠেলে দেওয়ার মূল কারণগুলির মধ্যে একটি হল আমাদের অ্যাপ্লিকেশনের ক্রমবর্ধমান বান্ডিল আকার।


2020 সালের গ্রীষ্মে একটি পুঙ্খানুপুঙ্খ বান্ডেল বিশ্লেষণ করার পর, আমি আবিষ্কার করেছি যে 2019 সালের প্রথম দিকে এটির প্রাথমিক লঞ্চের পর থেকে, বান্ডেলের আকার (gzipped) 450KB থেকে 800KB হয়েছে (এটি প্রায় 4MB পার্স করা হয়েছে)-মূল আকারের প্রায় দ্বিগুণ।


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


যদিও আমি মাইক্রো-ফ্রন্টেন্ডের ধারণা সম্পর্কে উত্সাহী ছিলাম, আমি এটাও স্বীকার করেছি যে আমরা নির্দিষ্ট চ্যালেঞ্জগুলির মুখোমুখি হওয়ার কারণে আমরা এখনও সেগুলি গ্রহণ করতে প্রস্তুত ছিলাম না:


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


    এটি একটি পরিপক্ক কাঠামো থাকা অত্যন্ত গুরুত্বপূর্ণ ছিল যা কার্যকরভাবে বিতরণ করা আর্কিটেকচার পরিচালনা করতে পারে এবং বিভিন্ন ফ্রন্টএন্ড উপাদানগুলির মধ্যে নির্ভরতা প্রতিফলিত করতে পারে।


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


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


এটি আমাদের সামগ্রিক সাংগঠনিক কাঠামোকে ব্যাহত না করে বা আমাদের ব্যবসায়িক ডোমেনের অখণ্ডতার সাথে আপস না করে কর্মক্ষমতা এবং মাপযোগ্যতা সংক্রান্ত উদ্বেগগুলিকে মোকাবেলা করার অনুমতি দেবে। এটি আমাদের দল বাড়াতে এবং ব্যবসার দিকনির্দেশগুলি পর্যবেক্ষণ করতে কিছু সময় দেবে।


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


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


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


বিভিন্ন দল দ্বারা নিয়ন্ত্রিত মালিকানার বিভিন্ন এলাকায় কোড বেস বিভক্ত করার একটি অপরিহার্য প্রয়োজন হবে।


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

শুরু

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


এই স্থানান্তরের মধ্যবর্তী পর্যায়গুলির মধ্যে একটি ছিল একটি বিতরণকৃত মনোলিথ আর্কিটেকচার প্রতিষ্ঠা করা, যেখানে একাধিক মডিউল/উইজেটগুলি অলস-লোডিং কৌশলগুলির মাধ্যমে অ্যাসিঙ্ক্রোনাসভাবে বিতরণ করা যেতে পারে যখন কোর পরিষেবা এবং উইজেটগুলির মধ্যে ভাগ করা অবকাঠামো যেমন একটি S3 বালতি এবং CDN ব্যবহার করা যেতে পারে। .


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


প্রায় 1 বছর পরে, অবশেষে আমার মাইক্রো-ফ্রন্টেন্ড মাইগ্রেশন পরিকল্পনাটি কার্যকর করার সময় এসেছে। একটি নতুন ডোমেনে আসন্ন সম্প্রসারণ এবং আমাদের হাতে একটি বৃহত্তর দল, আমরা মাইগ্রেশন কার্যকর করার জন্য সুসজ্জিত ছিলাম।


এটি একটি সুবর্ণ সুযোগের মতো মনে হয়েছিল যা আমরা মিস করতে পারি না।


সর্বোপরি, মনোলিথিক স্থাপত্যের মধ্যে সীমাবদ্ধ থাকার অর্থ চিরকাল এর সীমাবদ্ধতার সাথে লড়াই করা।


একটি নতুন ডোমেনে প্রসারিত করার সীমিত টাইমলাইন একটি অনুঘটক হিসাবে কাজ করে, যা আমাদেরকে সংক্ষিপ্ত এবং ধীর পুনরাবৃত্তির পরিবর্তে এখনই একটি আরও মাপযোগ্য এবং রক্ষণাবেক্ষণযোগ্য আর্কিটেকচার তৈরির দিকে চালিত করে!


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


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


যাইহোক, মাইক্রো-ফ্রন্টেন্ড ধারণাটি সফল প্রমাণিত হবে তা নিশ্চিত না করে আমরা বৈশিষ্ট্যের কাজটি নিয়ে এগিয়ে যেতে পারিনি।


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


এই প্রক্রিয়ার মূল মাইলফলক ছিল একটি প্রমাণ-অব-ধারণার বিকাশ যা নকশা অনুসারে সমস্ত উপাদানের সফল সংহতকরণ প্রদর্শন করবে।


এই মাইলফলকটিকে যথাযথভাবে "পয়েন্ট অফ নো রিটার্ন" নাম দেওয়া হয়েছে, যার লক্ষ্য মাইক্রো-ফ্রন্টেন্ড আর্কিটেকচারের সম্ভাব্যতা এবং কার্যকারিতা যাচাই করা।


যদিও আমি মাইগ্রেশনের সাফল্যের ব্যাপারে আশাবাদী ছিলাম, এটা জরুরি অবস্থার জন্য প্রস্তুত করা ছিল। ফলস্বরূপ, আমি একটি প্ল্যান বি তৈরি করেছি, যা একটি ব্যাকআপ কৌশল হিসাবে কাজ করে যদি প্রাথমিক ধারণাটি পছন্দসই ফলাফল না দেয়।


এর মধ্যে রয়েছে অনুমানে অতিরিক্ত সাত দিন বরাদ্দ করা যাতে আমি বালিশে কান্নাকাটি করতে পারি এবং অলস-লোডিংয়ের মাধ্যমে কোরের সাথে সংযুক্ত একটি নতুন বৈশিষ্ট্য মডিউল এন্ট্রি করার জন্য কয়েক দিন (মনে রাখবেন ডিস্ট্রিবিউটেড মনোলিথ?)।

নকশা

মাইক্রো-ফ্রন্টেন্ড ডিজাইন করার সময়, কম্পোজিশনের জন্য সাধারণত 3টি পন্থা থাকে, প্রতিটিটি রানটাইম অ্যাপ রেজোলিউশনটি কোথায় হয় তার উপর ফোকাস করে। এই পদ্ধতির সৌন্দর্য হল যে তারা পারস্পরিক একচেটিয়া নয় এবং প্রয়োজন অনুসারে একত্রিত করা যেতে পারে।

সার্ভার-সাইড রচনা

মূল ধারণা হল প্রতি পৃষ্ঠায় মাইক্রো-ফ্রন্টেন্ড বান্ডেলগুলিকে বিভক্ত করতে এবং রুট URL এর উপর ভিত্তি করে একটি হার্ড পৃষ্ঠা পুনরায় লোড করার জন্য একটি বিপরীত প্রক্সি সার্ভারের সুবিধা নেওয়া।

সুবিধা:

  • বাস্তবায়ন সহজ


অসুবিধা:

  • মাইক্রো-ফ্রন্টেন্ড অ্যাপের মধ্যে গ্লোবাল স্টেট সিঙ্ক করা হবে না। এটি আমাদের জন্য একটি পরিষ্কার নো-গো পয়েন্ট ছিল কারণ আমাদের ক্লায়েন্ট সাইডে দীর্ঘদিন ধরে চলমান ব্যাকগ্রাউন্ড অপারেশন ছিল।


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


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


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


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

প্রান্ত-পার্শ্ব রচনা

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

সুবিধা:

  • রক্ষণাবেক্ষণের জন্য কম পরিকাঠামো অংশ: প্রক্সি সার্ভারের প্রয়োজন নেই, প্রতিটি মাইক্রো-অ্যাপের জন্য আলাদা CDN


  • সার্ভারহীন প্রযুক্তি ব্যবহার করে কার্যত অসীম স্কেলিং


  • স্বতন্ত্র প্রক্সি সার্ভারের তুলনায় ভালো লেটেন্সি


অসুবিধা:

  • ঠান্ডা শুরুর সময় একটি সমস্যা হতে পারে


  • Lambda@Edge সমস্ত AWS অঞ্চলে সমর্থিত নয় যদি আপনার বহু-অঞ্চল (বিচ্ছিন্ন) অবকাঠামোর প্রয়োজন হয়

ক্লায়েন্ট-সাইড রচনা

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


এই আর্কিটেকচারের মূল প্লেয়ার হল একটি ধারক (শেল) অ্যাপ্লিকেশন যার নিম্নলিখিত দায়িত্ব রয়েছে:


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


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


  • বিশ্বব্যাপী নির্ভরতা রচনা করা: কন্টেইনার অ্যাপটি সমস্ত বিশ্বব্যাপী নির্ভরতা তৈরি করে, যেমন প্রতিক্রিয়া, SDK এবং UI লাইব্রেরি, এবং সেগুলিকে একটি পৃথক বান্ডেল (vendor.js) হিসাবে প্রকাশ করে যা মাইক্রো-ফ্রন্টেন্ডগুলির মধ্যে ভাগ করা যেতে পারে।


সাধারণ ধারণা হল প্রতিটি মাইক্রো-ফ্রন্টেন্ড বান্ডেল 2 ধরনের সম্পদ ফাইল তৈরি করবে:

  • {hash}/index.js: এটি মাইক্রো-ফ্রন্টএন্ড অ্যাপ্লিকেশনের জন্য এন্ট্রি পয়েন্ট হিসাবে কাজ করে, হ্যাশ সমগ্র বিল্ডের জন্য একটি অনন্য শনাক্তকারীকে উপস্থাপন করে।


    হ্যাশ S3 বাকেটের প্রতিটি বান্ডিলের জন্য একটি উপসর্গ কী হিসাবে কাজ করে। এটা মনে রাখা গুরুত্বপূর্ণ যে একাধিক এন্ট্রি পয়েন্ট থাকতে পারে, কিন্তু হ্যাশ তাদের সবার জন্য একই থাকে।


  • manifest.json: এটি একটি ম্যানিফেস্ট ফাইল যাতে মাইক্রো-ফ্রন্টএন্ড অ্যাপ্লিকেশনের জন্য সমস্ত এন্ট্রি পয়েন্টের পথ রয়েছে। এই ফাইলটি সর্বদা S3 বালতির রুটে চলে যাবে, তাই ধারকটি সহজেই এটি আবিষ্কার করতে সক্ষম হবে।


    পরিবর্তনের আরও ভালো পর্যবেক্ষণের জন্য আমি S3 বালতিতে এই ফাইলটির সংস্করণ চালু করার সুপারিশ করছি। আপনি যদি আপনার প্রকল্প তৈরি করতে ওয়েবপ্যাক ব্যবহার করেন, আমি অত্যন্ত সুপারিশ করছি WebpackManifestPlugin যা আপনার জন্য সমস্ত ভারী উত্তোলন করে।


ধারকটি স্টেজ এবং অঞ্চলের উপর ভিত্তি করে শুধুমাত্র মাইক্রো-ফ্রন্টেন্ড অ্যাসেট সোর্স ডোমেন URL (CDN অরিজিন) সম্পর্কে সচেতন। প্রাথমিক পৃষ্ঠা লোডের সময়, কন্টেইনার প্রতিটি মাইক্রো-ফ্রন্টএন্ড অ্যাপ্লিকেশনের জন্য ম্যানিফেস্ট ফাইল ডাউনলোড করে।


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


সঠিক অর্কেস্ট্রেশন লাইব্রেরি নির্বাচন করা এই রচনার সবচেয়ে বড় চ্যালেঞ্জ এবং পরবর্তী অধ্যায়ে আলোচনা করা হবে।

সুবিধা:

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


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


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


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


অসুবিধা:

  • ম্যানিফেস্ট ফাইল আনার জন্য আরও নেটওয়ার্ক হপস: যেহেতু ধারকটিকে প্রতিটি মাইক্রো-ফ্রন্টেন্ডের জন্য ম্যানিফেস্ট ফাইলটি পুনরুদ্ধার করতে হবে, অন্যান্য কম্পোজিশন পদ্ধতির তুলনায় অতিরিক্ত নেটওয়ার্ক অনুরোধ এবং সম্ভাব্য লেটেন্সি থাকতে পারে। প্রারম্ভিক পৃষ্ঠা লোডের উপর সমস্ত ম্যানিফেস্ট আপফ্রন্ট লোড করে বা কিছু প্রিলোডিং কৌশল প্রবর্তন করে এটি প্রশমিত করা যেতে পারে।


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

হাইব্রিড রচনা

যেমনটি আমি এই অধ্যায়ে আগে উল্লেখ করেছি, এই সমস্ত কম্পোজিশন প্যাটার্ন একই শেল প্রয়োগের মধ্যে মিশ্রিত এবং মিলিত হতে পারে। এটি দেখতে কেমন হতে পারে তার একটি উদাহরণ এখানে দেওয়া হল:

সুপারিশ

আমি শুরুতে একটি সমজাতীয় পদ্ধতির সাথে শুরু করার পরামর্শ দিই — একটি রচনা প্যাটার্ন নির্বাচন করুন যা আপনার জন্য আরও ভাল হয় এবং এর চারপাশে অবকাঠামো তৈরি করা শুরু করুন।


আমাদের জন্য, ক্লায়েন্ট-সাইড কম্পোজিশন ছিল সর্বোত্তম বিকল্প, কিন্তু ভবিষ্যতের জন্য, আমরা কিছু অঞ্চলকে এজ-সাইড অর্কেস্ট্রেশনে স্যুইচ করার কথা বিবেচনা করেছি (Lambda@Edge-এর উপলব্ধতার উপর ভিত্তি করে)।

অর্কেস্ট্রেশন লাইব্রেরি নির্বাচন করা

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


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


বেশ কিছু জনপ্রিয় অর্কেস্ট্রেশন লাইব্রেরি বিদ্যমান, যার প্রত্যেকটির নিজস্ব শক্তি এবং বিবেচনা রয়েছে।

একক-স্পা

একক-স্পা একটি ব্যাপকভাবে গৃহীত অর্কেস্ট্রেশন লাইব্রেরি যা মাইক্রো-ফ্রন্টেন্ড রচনার জন্য একটি নমনীয় এবং বর্ধিত পদ্ধতি প্রদান করে। এটি বিকাশকারীদের একটি শেল অ্যাপ্লিকেশন তৈরি করতে দেয় যা একাধিক মাইক্রো-ফ্রন্টেন্ডের লোডিং এবং আনলোডিং অর্কেস্ট্রেট করে।


একক-এসপিএ জীবনচক্র ইভেন্টগুলির উপর সূক্ষ্ম নিয়ন্ত্রণ প্রদান করে এবং বিভিন্ন কাঠামো এবং প্রযুক্তি সমর্থন করে।


সুবিধা:

  • ফ্রেমওয়ার্ক অজ্ঞেয়বাদী: লাইব্রেরি বিভিন্ন ফ্রন্টএন্ড ফ্রেমওয়ার্ক যেমন React, Angular, Vue.js এবং আরও অনেক কিছুর সাথে ভাল কাজ করে।


  • নমনীয় কনফিগারেশন: এটি রাউটিং, অলস-লোডিং এবং ভাগ করা নির্ভরতার জন্য শক্তিশালী কনফিগারেশন বিকল্প সরবরাহ করে।


  • মজবুত ইকোসিস্টেম: একক-এসপিএ-এর একটি সক্রিয় সম্প্রদায় এবং প্লাগইন এবং এক্সটেনশনের সমৃদ্ধ ইকোসিস্টেম রয়েছে।


অসুবিধা:

  • শেখার বক্ররেখা: একক-স্পা দিয়ে শুরু করার জন্য এর ধারণা এবং API সম্পর্কে কিছু প্রাথমিক শিক্ষা এবং বোঝার প্রয়োজন হতে পারে।


  • কাস্টমাইজেশন জটিলতা: মাইক্রো-ফ্রন্টেন্ড আর্কিটেকচার জটিলতা বাড়ার সাথে সাথে অর্কেস্ট্রেশন কনফিগার করা এবং পরিচালনা করা চ্যালেঞ্জিং হয়ে উঠতে পারে।

কিয়ানকুন

কিয়ানকুন একটি শক্তিশালী অর্কেস্ট্রেশন লাইব্রেরি যা অ্যান্ট ফাইন্যান্সিয়াল (আলিবাবা) দল দ্বারা তৈরি করা হয়েছে। এটি রচনার জন্য একটি আংশিক HTML পদ্ধতি ব্যবহার করে। মাইক্রো-ফ্রন্টেন্ড অ্যাপের দিকে, এটি লোড করার জন্য সমস্ত এন্ট্রি পয়েন্ট সহ একটি প্লেইন HTML স্নিপেট তৈরি করে।


এই HTML ফাইলটি ব্যবহার করার পরে, ধারকটি সমস্ত অর্কেস্ট্রেশন করে এবং অ্যাপটি মাউন্ট করে। এই কনফিগারেশনে, আংশিক HTML একটি ম্যানিফেস্ট ফাইলের ভূমিকা পালন করে যা আমি আগের অধ্যায়ে বলেছিলাম।


সুবিধা:

  • ফ্রেমওয়ার্ক অজ্ঞেয়বাদী: Qiankun বিভিন্ন ফ্রন্টএন্ড ফ্রেমওয়ার্ক সমর্থন করে, যার মধ্যে রয়েছে React, Vue.js, Angular, এবং আরও অনেক কিছু।


  • সরলীকৃত ইন্টিগ্রেশন: Qiankun মাইক্রো-ফ্রন্টেন্ড তৈরি এবং পরিচালনার জন্য সহজে ব্যবহারযোগ্য API এবং সরঞ্জামগুলির একটি সেট সরবরাহ করে।


  • পরিমাপযোগ্যতা এবং কর্মক্ষমতা: Qiankun কোড স্যান্ডবক্সিং, রাষ্ট্র বিচ্ছিন্নতা, এবং মাইক্রো-ফ্রন্টেন্ডের মধ্যে যোগাযোগের জন্য দক্ষ প্রক্রিয়া সরবরাহ করে।


অসুবিধা:

  • নির্ভরতা দ্বন্দ্ব: ভাগ করা নির্ভরতা পরিচালনা এবং মাইক্রো-ফ্রন্টেন্ড জুড়ে সামঞ্জস্যতা নিশ্চিত করার জন্য সতর্ক কনফিগারেশন এবং বিবেচনার প্রয়োজন হতে পারে।


  • শেখার বক্ররেখা: যদিও Qiankun ব্যাপক ডকুমেন্টেশন প্রদান করে, একটি নতুন লাইব্রেরি গ্রহণ করা আপনার উন্নয়ন দলের জন্য একটি শেখার বক্ররেখা জড়িত হতে পারে।


  • অপ্রয়োজনীয় ডেটা তারের মাধ্যমে পাঠানো: আংশিক HTML স্নিপেটে অপ্রয়োজনীয় ডেটা (বডি, মেটা, ডকটাইপ ট্যাগ) থাকে যা নেটওয়ার্কের মাধ্যমে পাঠানো প্রয়োজন।

মডিউল ফেডারেশন

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


ওয়েবপ্যাক এবং রানটাইম নমনীয়তার সাথে এর নিরবিচ্ছিন্ন একীকরণের সাথে, মডিউল ফেডারেশন মাইক্রো-ফ্রন্টেন্ড পরিচালনা এবং অর্কেস্ট্রেট করার জন্য একটি জনপ্রিয় পছন্দ হয়ে উঠেছে।


সুবিধা:

  • ওয়েবপ্যাকের সাথে নিরবচ্ছিন্ন ইন্টিগ্রেশন: আপনি যদি ইতিমধ্যেই আপনার বিল্ড টুল হিসাবে ওয়েবপ্যাক ব্যবহার করছেন, তাহলে মডিউল ফেডারেশনের সুবিধা সেটআপ এবং ইন্টিগ্রেশন প্রক্রিয়াকে সহজ করে।


  • রানটাইম নমনীয়তা: মডিউল ফেডারেশন ডায়নামিক লোডিং এবং নির্ভরতা ভাগাভাগি সক্ষম করে, মাইক্রো-ফ্রন্টেন্ড পরিচালনায় নমনীয়তা প্রদান করে।


অসুবিধা:

  • সীমিত কাঠামো সমর্থন: যদিও মডিউল ফেডারেশন একাধিক ফ্রন্টএন্ড ফ্রেমওয়ার্কের সাথে সামঞ্জস্যপূর্ণ, এটি নির্দিষ্ট ব্যবহারের ক্ষেত্রে অতিরিক্ত কনফিগারেশন বা সমাধানের প্রয়োজন হতে পারে।


  • সম্প্রদায় সমর্থন: মডিউল ফেডারেশন একটি অপেক্ষাকৃত নতুন প্রযুক্তি, যা ওয়েবপ্যাক 5 এ একটি মূল প্লাগইন হিসাবে প্রকাশিত হয়েছে (এবং পরে v4 তে ব্যাক-পোর্ট করা হয়েছে)। Next.js লাইব্রেরিটিও নতুন, সম্প্রতি একটি ওপেন সোর্স হিসেবে প্রকাশ করা হচ্ছে। সমস্ত নতুন টুলের মতো, একটি ছোট সম্প্রদায় এবং কম সমর্থন উপলব্ধ হতে পারে। আপনার যদি কঠোর সময়সীমা থাকে বা সহজে উপলব্ধ উত্তর ছাড়াই প্রশ্নের সম্মুখীন হওয়ার প্রত্যাশা করেন তবে এই ফ্যাক্টরটি বিবেচনা করা গুরুত্বপূর্ণ।

উপসংহার

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


আমরা একটি প্রযুক্তিগত দৃষ্টি নথির গুরুত্ব অন্বেষণ করেছি যা বিস্তারিত কর্মক্ষমতা বিশ্লেষণ প্রদর্শন করে এবং স্থানান্তরের বিভিন্ন পর্যায়কে রূপরেখা দেয়।


তারপরে আমরা মাইক্রো-ফ্রন্টেন্ডের জন্য ডিজাইনের বিবেচনার মধ্যে পড়েছি, তিনটি পন্থা নিয়ে আলোচনা করেছি: সার্ভার-সাইড কম্পোজিশন, এজ-সাইড কম্পোজিশন এবং ক্লায়েন্ট-সাইড কম্পোজিশন।


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


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


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


মূলত 18 এপ্রিল, 2023-এ https://thesametech.com- এ প্রকাশিত।


এছাড়াও আপনি আমাকে টুইটারে অনুসরণ করতে পারেন, এবং নতুন পোস্ট সম্পর্কে বিজ্ঞপ্তি পেতে LinkedIn-এ সংযোগ করতে পারেন !