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

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

ডেমিয়ান রেনজুলি
Demián Renzulli

প্রকাশিত: ১৯ আগস্ট, ২০১৯

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

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

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

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

ভালোটা

প্রথমে কার্যকর কারণগুলি একবার দেখে নিন:

  • স্থানীয়করণ / ভাষা: একটি দেশ-কোড শীর্ষ-স্তরের ডোমেন ব্যবহার করে, বিভিন্ন দেশে পরিবেশিত সাইটগুলিকে পৃথক করতে (যেমন https://www.google.com.ar ), অথবা বিভিন্ন স্থানে লক্ষ্য করা সাইটগুলিকে বিভক্ত করতে সাবডোমেন ব্যবহার করে (যেমন: https://newyork.craigslist.org ) অথবা একটি নির্দিষ্ট ভাষার জন্য সামগ্রী অফার করতে (যেমন 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-দের জন্য চ্যালেঞ্জ এবং সমাধান

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

সেবা কর্মীরা

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

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

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

ক্যাশিং

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

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

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

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

অনুমতিসমূহ

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

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

স্থাপন

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

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

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

  1. beforeinstallprompt ইভেন্টটি শুনুন
  2. প্রম্পটটি প্রদর্শিত হওয়া থেকে বিরত রাখুন , event.preventDefault() কল করুন।

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

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

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

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

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

উপসংহার

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

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

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

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