মাল্টি-অরিজিন সাইটে প্রগতিশীল ওয়েব অ্যাপস

মাল্টি-অরিজিন সাইটগুলিতে প্রগতিশীল ওয়েব অ্যাপস তৈরির জন্য চ্যালেঞ্জ এবং সমাধান।

Demián Renzulli

পটভূমি

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

একাধিক উত্সের ভাল এবং খারাপ ব্যবহার

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

ভাল

আসুন প্রথমে দরকারী কারণগুলি দেখি:

• স্থানীয়করণ / ভাষা: একটি দেশ-কোড টপ-লেভেল ডোমেন ব্যবহার করে, বিভিন্ন দেশে পরিবেশন করা সাইটগুলিকে আলাদা করতে (যেমন https://www.google.com.ar ), বা সাবডোমেন ব্যবহার করে বিভিন্ন অবস্থানে লক্ষ্য করা সাইটগুলিকে ভাগ করতে (যেমন: https://newyork.craigslist.org ) বা একটি নির্দিষ্ট ভাষার জন্য সামগ্রী অফার করতে (যেমন pedia https://en.wikipedia.org )।

• স্বাধীন ওয়েবঅ্যাপ: অভিজ্ঞতা প্রদানের জন্য বিভিন্ন সাবডোমেন ব্যবহার করে যার উদ্দেশ্য মূল উৎসের সাইট থেকে যথেষ্ট আলাদা। উদাহরণস্বরূপ, একটি নিউজ সাইটে, ক্রসওয়ার্ড ওয়েবঅ্যাপটি ইচ্ছাকৃতভাবে https://crosswords.example.com থেকে পরিবেশন করা যেতে পারে এবং প্রধান ওয়েবসাইটের সাথে কোনো সংস্থান বা কার্যকারিতা ভাগ না করেই একটি স্বাধীন PWA হিসাবে ইনস্টল ও ব্যবহার করা যেতে পারে।

খারাপ

আপনি যদি এই জিনিসগুলির কোনোটি না করেন, তাহলে প্রগ্রেসিভ ওয়েব অ্যাপস তৈরি করার সময় মাল্টি-অরিজিন আর্কিটেকচার ব্যবহার করা একটি অসুবিধা হতে পারে।

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

নিম্নলিখিত নিদর্শন, উদাহরণস্বরূপ, অত্যন্ত নিরুৎসাহিত করা হয়:

• সাইট বিভাগ: সাবডোমেনে একটি সাইটের বিভিন্ন বিভাগ আলাদা করা। নিউজ সাইটগুলিতে, হোম পেজটি এখানে দেখা অস্বাভাবিক নয়: https://www.example.com , যখন ক্রীড়া বিভাগটি https://sports.example.com এ, রাজনীতি https://politics.example.com এ থাকে এবং আরও অনেক কিছু। একটি ই-কমার্স সাইটের ক্ষেত্রে, পণ্য বিভাগের জন্য https://category.example.com , পণ্যের পৃষ্ঠাগুলির জন্য https://product.example.com ইত্যাদি ব্যবহার করে।

• ব্যবহারকারী প্রবাহ: নিরুৎসাহিত করা আরেকটি পদ্ধতি হল সাইটের বিভিন্ন ছোট অংশকে আলাদা করা, যেমন লগইন বা সাবডোমেনে ক্রয় প্রবাহের জন্য পৃষ্ঠাগুলি। উদাহরণস্বরূপ, https://login.example.com এবং https://checkout.example.com ব্যবহার করে।

সেসব ক্ষেত্রে যেখানে একক উত্সে স্থানান্তর করা সম্ভব নয়, নিম্নলিখিত চ্যালেঞ্জগুলির একটি তালিকা এবং (যেখানে সম্ভব), সমাধানগুলি যা প্রগতিশীল ওয়েব অ্যাপস তৈরি করার সময় বিবেচনা করা যেতে পারে৷

বিভিন্ন উত্স জুড়ে পিডব্লিউএ-এর জন্য চ্যালেঞ্জ এবং ওয়ার্কঅ্যারাউন্ড

একাধিক উত্সের উপর একটি ওয়েবসাইট তৈরি করার সময়, একটি ইউনিফাইড PWA অভিজ্ঞতা প্রদান করা চ্যালেঞ্জিং, বেশিরভাগ একই-অরিজিন নীতির কারণে, যা অনেকগুলি সীমাবদ্ধতা আরোপ করে৷ চলুন এক সময়ে তাদের তাকান.

সেবা কর্মীরা

পরিষেবা কর্মী স্ক্রিপ্ট URL-এর উৎপত্তি পৃষ্ঠা কলিং রেজিস্টার() এর উৎপত্তির মতোই হতে হবে। এর মানে হল, উদাহরণস্বরূপ, https://www.example.com এর একটি পৃষ্ঠা https://section.example.com এ পরিষেবা কর্মী url-এর সাথে register() কল করতে পারে না।

আরেকটি বিবেচ্য বিষয় হল যে একজন পরিষেবা কর্মী শুধুমাত্র মূল এবং পথের অধীনে হোস্ট করা পৃষ্ঠাগুলিকে নিয়ন্ত্রণ করতে পারে। এর মানে হল, যদি পরিষেবা কর্মীকে https://www.example.com এ হোস্ট করা হয় তবে এটি শুধুমাত্র সেই উৎস থেকে URLগুলিকে নিয়ন্ত্রণ করতে পারে ( স্কোপ প্যারামিটারে সংজ্ঞায়িত পথ অনুসারে), কিন্তু অন্যান্য সাবডোমেনে যেমন https://section.example.com এর কোনো পৃষ্ঠা নিয়ন্ত্রণ করবে না।

এই ক্ষেত্রে, একমাত্র সমাধান হল একাধিক পরিষেবা কর্মী ব্যবহার করা (প্রতি মূলে একজন)।

ক্যাশিং

ক্যাশে অবজেক্ট, ইনডেক্সডডিবি এবং লোকাল স্টোরেজও একটি একক উত্সের জন্য সীমাবদ্ধ। এর মানে হল যেগুলি https://www.example.com এর অন্তর্গত ক্যাশে অ্যাক্সেস করা সম্ভব নয়, উদাহরণস্বরূপ: https://www.section.example.com ।

এইরকম পরিস্থিতিতে সঠিকভাবে ক্যাশে পরিচালনা করতে আপনি কিছু করতে পারেন:

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

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

অনুমতি

অনুমতিগুলিও উত্সের জন্য স্কোপড। এর মানে হল যে যদি কোনও ব্যবহারকারী https://section.example.com উত্সের জন্য একটি প্রদত্ত অনুমতি প্রদান করে তবে এটি https://www.example.com মতো অন্য উত্সগুলিতে বহন করবে না।

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

ইনস্টলেশন

একটি PWA ইনস্টল করার জন্য, প্রতিটি অরিজিনের একটি start_url সহ নিজস্ব ম্যানিফেস্ট থাকতে হবে যা নিজের সাথে সম্পর্কিত । এর মানে হল যে কোনও ব্যবহারকারী একটি প্রদত্ত উত্সে ইনস্টলেশন প্রম্পট গ্রহণ করে (যেমন: https://section.example.com ) অন্য একটিতে একটি start_url সহ PWA ইনস্টল করতে সক্ষম হবে না (যেমন: https://www.example.com )। অন্য কথায়, একটি সাবডোমেনে ইনস্টলেশন প্রম্পট প্রাপ্ত ব্যবহারকারীরা শুধুমাত্র উপপৃষ্ঠাগুলির জন্য PWA ইনস্টল করতে সক্ষম হবেন, অ্যাপের মূল URL-এর জন্য নয়।

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

এই সমস্যাটি প্রশমিত করার জন্য আপনি নিশ্চিত করতে পারেন যে প্রম্পটটি শুধুমাত্র মূল উত্সে দেখানো হয়েছে৷ যখন একজন ব্যবহারকারী একটি সাবডোমেন পরিদর্শন করে যা ইনস্টলেশনের মানদণ্ড পাস করে:

1. beforeinstallprompt শুনুন ।
2. প্রম্পটটি উপস্থিত হওয়া থেকে প্রতিরোধ করুন , event.preventDefault() কল করা।

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

স্বতন্ত্র মোড

একটি স্বতন্ত্র উইন্ডোতে নেভিগেট করার সময়, ব্যবহারকারী যখন PWA এর ম্যানিফেস্ট দ্বারা সেট করা সুযোগের বাইরে চলে যায় তখন ব্রাউজারটি ভিন্নভাবে আচরণ করবে। আচরণ প্রতিটি ব্রাউজার সংস্করণ এবং বিক্রেতার উপর নির্ভর করে। উদাহরণস্বরূপ, সাম্প্রতিক ক্রোম সংস্করণগুলি একটি Chrome কাস্টম ট্যাব খোলে, যখন কোনও ব্যবহারকারী স্বতন্ত্র মোডে সুযোগের বাইরে চলে যায়৷

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

1. নতুন URL, https://login.example.com , একটি পূর্ণ স্ক্রীন আইফ্রেমের ভিতরে খুলতে পারে৷
2. আইফ্রেমের ভিতরে কাজটি শেষ হয়ে গেলে (উদাহরণস্বরূপ, লগইন প্রক্রিয়া), postMessage() ব্যবহার করা যেতে পারে, iframe থেকে প্রাপ্ত যেকোনো তথ্য মূল পৃষ্ঠায় ফেরত দিতে।
3. চূড়ান্ত পদক্ষেপ হিসাবে, একবার মূল পৃষ্ঠায় বার্তাটি প্রাপ্ত হলে, শ্রোতাদের নিবন্ধনমুক্ত করা যেতে পারে এবং অবশেষে DOM থেকে iframe মুছে ফেলা হবে।

উপসংহার

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

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

একটি দীর্ঘমেয়াদী কৌশল বা সাইট পুনঃডিজাইন মূল্যায়ন করার সময়, একটি একক মূলে স্থানান্তরিত করার কথা বিবেচনা করুন, যদি না মাল্টি-অরিজিন আর্কিটেকচার রাখার একটি গুরুত্বপূর্ণ কারণ থাকে।

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