মনোলিথ ব্রেকিং: কোড স্প্লিটিং টেকনিকের জন্য একটি ব্যাপক গাইড

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

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

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

মাইক্রোফ্রন্ট পদ্ধতি: এটি কি এবং কেন এটি প্রয়োজন?

আমরা MF এর সংজ্ঞায় যাওয়ার আগে, আসুন কয়েকটি সমস্যা দেখি যা প্রকল্পগুলিতে সম্মুখীন হতে পারে:

1. আপনার একটি বড় প্রকল্প আছে . একটি প্রকল্পের আকার সাধারণত বিষয়গত হয় এবং কার্যকারিতার পরিমাণ এবং বিকাশকারীদের সংখ্যা দ্বারা অভিজ্ঞতাগতভাবে নির্ধারণ করা যেতে পারে। যদি আপনার কাছে 1-2টি ফ্রন্ট-এন্ডারকে ধাঁধাঁ দেওয়ার জন্য যথেষ্ট কাজ থাকে এবং একই সাথে তারা "তাদের কনুই ঠেলে" না - এটি একটি ছোট প্রকল্প, 3-6টি মাঝারি, এবং 6-8 এর বেশি ইতিমধ্যেই একটি বড় প্রকল্প। .

   
   

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

   
   

3. আপনি মহান কার্যকারিতা আছে. একজন একক বিকাশকারী শুধুমাত্র তার সাবটিমের জন্য কোডের একটি অংশ বজায় রাখতে পারে। বিষয় এলাকা সম্পর্কে অজ্ঞতা বা তৃতীয় পক্ষের যুক্তি প্রয়োগের জটিলতার কারণে বাকি কোড পরিমার্জন ব্যয়বহুল হতে পারে।

সমস্যাগুলি আরও বাড়তে পারে:

• স্ট্যাক পরিবর্তন করার ইচ্ছা;

• সংশ্লিষ্ট প্রকল্পের একটি পরিবারকে সমর্থন করার জন্য একটি কোম্পানির প্রয়োজনীয়তা।

  
  

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

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

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

মাইক্রোফ্রন্টেন্ডস বনাম অলস লোডিং

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

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

MFs কর্মক্ষমতা সমস্যার সমাধান করে না, এবং কখনও কখনও এমনকি এটি আরও বাড়িয়ে তোলে। কিন্তু তারা উন্নয়নকে এমনভাবে সংগঠিত করতে সাহায্য করে যা একটি নির্দিষ্ট সাবটিমের জন্য আরও আরামদায়ক, উপরের সমস্যাগুলিকে কমিয়ে দেয়।

বিল্ডটাইম বনাম রানটাইম

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

সুতরাং, MF সংগঠিত করার সমস্ত উপায় সময় বা রানটাইম নির্মাণের জন্য দায়ী করা যেতে পারে। প্রতিটি তার সুবিধা এবং অসুবিধা আছে.

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

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

সংস্করণ এবং স্বাধীন স্থাপনা খুবই পরস্পরবিরোধী:

• সংস্করণ করার অর্থ হল আপনি অন্য দলের MF-এর যেকোনো সংস্করণ নিতে পারেন। এটি বিশেষভাবে সত্য যখন আপনাকে অন্যদের থেকে MF-a-এর নির্ভরতা আপগ্রেড করার জন্য অতিরিক্ত কাজ করতে হবে। প্রতিটি দল আপগ্রেড করার জন্য একটি ভাল সময় বেছে নেয়।

  
  

• স্বাধীন স্থাপনা দলগুলোকে আরো স্বায়ত্তশাসন এবং স্বাধীনতা দেয়। সর্বদা MF-এর সর্বশেষ সংস্করণ ব্যবহার করা গুরুত্বপূর্ণ। এর জন্য পশ্চাদগামী সামঞ্জস্য প্রয়োজন।

  
  

রানটাইম মার্জিংয়ের সাথে সংস্করণও প্রয়োগ করা যেতে পারে, তবে এটি ব্যবহারিক নয়। শুধুমাত্র স্বাধীন স্থাপনার স্বার্থে রানটাইমের সাথে যোগাযোগ করা বোধগম্য হয়, এবং পরবর্তীটি সংস্করণের সাথে একসাথে থাকতে পারে না।

পরবর্তী, আমরা MFs একত্রিত করার জন্য প্রতিটি পদ্ধতির নির্দিষ্ট বাস্তবায়নের উদাহরণ দেখতে পাব।

মাইক্রোফ্রন্টেন্ড সংগঠিত করার পদ্ধতি

আইফ্রেম

MF সংগঠিত করার প্রাচীনতম উপায়। iframe হল একটি রিসোর্সের ঠিকানা পাস করার জন্য একটি বিশেষ ট্যাগ যা প্রধান সাইটে প্রদর্শিত হবে। ফলাফল একটি সাইটের মধ্যে একটি সাইট.

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

এই সুবিধাগুলি পারফরম্যান্সের খরচে আসে, কারণ প্রতিটি আইফ্রেমের সন্নিবেশের ফলে প্রচুর সংস্থান হয়। আপনি এটি এড়াতে পারবেন না: একটি DOM নোড ডিবাগ এবং পুনরায় সংযুক্ত করার প্রচেষ্টা পূর্বে লোড করা সংস্থানগুলি সংরক্ষণ করবে না, আপনাকে সেগুলি পুনরায় ডাউনলোড করতে হবে৷ আপনি ক্যাশিং কনফিগার করে কর্মক্ষমতা হ্রাস কমাতে পারেন।

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

ওয়েব কম্পোনেন্ট

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

ওয়েব উপাদানগুলিতে MF তৈরি করার ক্ষমতা থাকা সত্ত্বেও, আমি অনুশীলনে এটি দেখিনি। এবং এটি কোনও দুর্ঘটনা নয়, বেশ কয়েকটি ব্লকার রয়েছে:

• হয় libs Lit বা Stencil যথেষ্ট জনপ্রিয় নয় এবং যথেষ্ট সাধারণ নয়। উপরন্তু, বাজারে পর্যাপ্ত বিশেষজ্ঞ নেই যারা তাদের সাথে কাজ করতে জানে বা যারা শিখতে প্রস্তুত।

  
  

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

  
  

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

  
  

• অনুসন্ধান রোবট একটি ওয়েব উপাদান তৈরি করতে পারে না, এবং এটি এসইও অপ্টিমাইজেশানকে প্রভাবিত করবে।

এনপিএম

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

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

গিট সাবমডিউল (বা লের্নার মতো মনোরেপোস তৈরির অন্য উপায়)

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

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

আসুন দুটি পদ্ধতির মধ্যে পার্থক্যগুলি একবার দেখে নেওয়া যাক:

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

  
  

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

  
  

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

  
  

একক স্পা

একক-স্পা মূলত একটি কাঠামো যা অন্যান্য কাঠামোকে একত্রিত করে। অবিশ্বাস্যভাবে শক্তিশালী প্রযুক্তি, যা বিপুল সংখ্যক সূক্ষ্মতা লুকিয়ে রাখে, এটি একটি পৃথক নিবন্ধের জন্য একটি বিষয়।

স্কিমটি iframe-এর মতোই, কিন্তু MF-এর লোডিং এখন নেটিভ ইম্পোর্ট + ইমপোর্টম্যাপের মাধ্যমে বা পলিফিলের প্রয়োজন হলে Systemjs-এর মাধ্যমে করা হয়।

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

ওয়েবপ্যাক 5 এম ওডিউল ফেডারেশন

একটি ওয়েবপ্যাক 5 প্লাগইন যা বিশেষভাবে MF তৈরির জন্য তৈরি করা হয়েছিল। প্রতিশ্রুতিশীল প্রযুক্তি: রানটাইমে আরও সঠিক বান্ডলিং এবং গতিশীল আমদানির জন্য একটি ছোট বিল্ড প্লাগইন।

এই স্কিমটি প্রায় একের পর এক একক-স্পার পুনরাবৃত্তি করে, কিন্তু এখন গতিশীল আমদানিগুলি MF লোড করতে ব্যবহৃত হয়

আপনার ক্ষেত্রে কী ব্যবহার করবেন তা কীভাবে চয়ন করবেন?

আসুন দেখে নেওয়া যাক কী কী প্রয়োগ করা যেতে পারে এবং কীসের জন্য:

• iframe - অসঙ্গত সংমিশ্রণের জন্য একটি একক সন্নিবেশ

• ওয়েব কম্পোনেন্ট - যখন আপনার একটি ছোট এন্ড-টু-এন্ড কার্যকারিতার প্রয়োজন হয় একটি ফ্রেমওয়ার্কের সাথে আবদ্ধ না হয়ে, যেমন একটি কর্পোরেট UI-kit

• npm প্যাকেজ - যদি প্রকল্পগুলির মধ্যে পুনরায় ব্যবহারযোগ্যতা থাকে এবং/অথবা আপনার বিল্ড টাইমে টাইপ চেক করা প্রয়োজন

• git সাবমডিউল - যখন আপনাকে একটি প্রকল্প মোটামুটিভাবে কাটাতে হবে এবং দায়িত্বের ক্ষেত্রগুলি বিতরণ করতে হবে

• একক-স্পা - যখন একাধিক ফ্রেমওয়ার্ক অনির্দিষ্টকালের জন্য একত্রিত করার প্রবল প্রয়োজন হয়, বিশেষত SSR ছাড়াই

• মডিউল-ফেডারেশন - স্ট্যাকের ঐক্য সাপেক্ষে MF-এর ব্যবহারের জন্য অন্যান্য সমস্ত পরিস্থিতি।

  
  

প্রতিটি পদ্ধতির নিজস্ব উপায়ে ভাল এবং সবকিছুর তার জায়গা থাকা উচিত। MF-এ স্যুইচ করার আগে, আমরা আপনাকে সত্যিই এটির প্রয়োজন কিনা তা ভেবে দেখার পরামর্শ দিই। যে পদ্ধতিই বেছে নেওয়া হোক না কেন, এটি অনিবার্যভাবে বিকাশের স্তরে কিছু জটিল করে তুলবে, CI/CD বা কর্মক্ষমতা। যদি একটি একক স্ট্যাক এবং একটি মনোলিথিক অ্যাপ্লিকেশনে থাকার সুযোগ থাকে, তাহলে এই সুযোগটি সানন্দে গ্রহণ করুন।

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