"প্রোগ্রেসিভ ওয়েব অ্যাপস ইন মাল্টি-অরিজিন সাইটস" ব্লগ পোস্টে , ডেমিয়ান একাধিক অরিজিনের উপর নির্মিত সাইটগুলি একটি একক প্রোগ্রেসিভ ওয়েব অ্যাপ তৈরি করার সময় যে চ্যালেঞ্জগুলির মুখোমুখি হয় তা নিয়ে আলোচনা করেছেন যা তাদের সকলকে অন্তর্ভুক্ত করে।
এই ধরণের সাইট আর্কিটেকচারের একটি উদাহরণ হল একটি ই-কমার্স সাইট যেখানে:
- হোম পেজটি
https://www.example.comএ রয়েছে। - বিভাগ পৃষ্ঠাগুলি
https://category.example.comএ হোস্ট করা আছে। - https:
https://product.example.comএ পণ্যের বিস্তারিত পৃষ্ঠাগুলি।
প্রবন্ধে আলোচনা করা হয়েছে যে, একই-অরিজিন নীতি বেশ কিছু বিধিনিষেধ আরোপ করে, যা পরিষেবা কর্মী, ক্যাশে এবং অনুমতিগুলিকে অরিজিন জুড়ে ভাগ করে নেওয়াকে বাধা দেয়। সেই কারণে, আমরা দৃঢ়ভাবে এই ধরণের কনফিগারেশন এড়িয়ে চলার পরামর্শ দিচ্ছি এবং যাদের ইতিমধ্যেই এইভাবে সাইট তৈরি করা হয়েছে, তাদের যখনই সম্ভব একটি একক অরিজিন সাইট আর্কিটেকচারে স্থানান্তর করার কথা বিবেচনা করার পরামর্শ দিচ্ছি।
এই পোস্টে, আমরা বিপরীত পরিস্থিতির দিকে নজর দেব: বিভিন্ন উৎসের একটি একক PWA-এর পরিবর্তে, আমরা একই ডোমেন নামের সুবিধা গ্রহণ করে একাধিক PWA প্রদান করতে চাওয়া কোম্পানিগুলির ক্ষেত্রে বিশ্লেষণ করব এবং ব্যবহারকারীকে সচেতন করব যে সেই PWA-গুলি একই সংস্থা বা পরিষেবার অন্তর্গত।
আপনি হয়তো লক্ষ্য করেছেন, আমরা ভিন্ন ভিন্ন কিন্তু আন্তঃসম্পর্কিত শব্দ ব্যবহার করছি, যেমন ডোমেইন এবং উৎপত্তি। এগিয়ে যাওয়ার আগে, এই ধারণাগুলি পর্যালোচনা করুন।
প্রযুক্তিগত পদ
- ডোমেন: ডোমেন নেম সিস্টেম (DNS) এ সংজ্ঞায়িত লেবেলের যেকোনো ক্রম। উদাহরণস্বরূপ:
comএবংexample.comহল ডোমেন। - হোস্টনেম: একটি DNS এন্ট্রি যা কমপক্ষে একটি IP ঠিকানায় সমাধান করে। উদাহরণস্বরূপ:
www.example.comএকটি হোস্টনেম হবে,example.comএকটি হোস্টনেম হতে পারে যদি এর একটি IP ঠিকানা থাকে, এবংcomকখনও একটি IP ঠিকানায় সমাধান করে না, তাই এটি কখনও একটি হোস্টনেম হতে পারে না। - অরিজিন: একটি স্কিম, হোস্টনেম এবং (ঐচ্ছিকভাবে) পোর্টের সংমিশ্রণ। উদাহরণস্বরূপ,
https://www.example.com:443হল একটি অরিজিন।
এর নাম থেকেই বোঝা যায়, একই-উৎপত্তি নীতিতে উৎপত্তির উপর বিধিনিষেধ আরোপ করা হয়েছে, তাই আমরা বেশিরভাগ প্রবন্ধ জুড়ে এই শব্দটি উল্লেখ করব। তবুও, বিভিন্ন "উৎপত্তি" তৈরি করার জন্য ব্যবহৃত কৌশলটি বর্ণনা করার জন্য আমরা সময়ে সময়ে "ডোমেন" বা "সাবডোমেন" ব্যবহার করব।
একাধিক, সম্পর্কিত PWA-এর ক্ষেত্রে
কিছু ক্ষেত্রে, আপনি হয়তো স্বাধীন অ্যাপ তৈরি করতে চাইবেন, কিন্তু তবুও সেগুলিকে একই প্রতিষ্ঠান বা "ব্র্যান্ড"-এর অন্তর্গত হিসেবে চিহ্নিত করতে পারবেন। একই ডোমেন নাম পুনঃব্যবহার করা সেই সম্পর্ক স্থাপনের একটি ভালো উপায়। উদাহরণস্বরূপ:
- একটি ই-কমার্স সাইট একটি স্বতন্ত্র অভিজ্ঞতা তৈরি করতে চায় যাতে বিক্রেতারা তাদের ইনভেন্টরি পরিচালনা করতে পারেন, এবং নিশ্চিত করতে চান যে এটি ব্যবহারকারীদের পণ্য কেনার মূল ওয়েবসাইটের অন্তর্গত।
- একটি স্পোর্টস নিউজ সাইট একটি বড় ক্রীড়া ইভেন্টের জন্য একটি নির্দিষ্ট অ্যাপ তৈরি করতে চায়, যাতে ব্যবহারকারীরা বিজ্ঞপ্তি ব্যবহার করে তাদের প্রিয় প্রতিযোগিতার পরিসংখ্যান পেতে পারেন এবং এটি একটি প্রোগ্রেসিভ ওয়েব অ্যাপ হিসেবে ইনস্টল করতে পারেন, একই সাথে ব্যবহারকারীরা এটিকে সংবাদ সংস্থার তৈরি একটি অ্যাপ হিসেবে চিনতে পারেন তা নিশ্চিত করতে চান।
- একটি কোম্পানি আলাদা চ্যাট, মেইল এবং ক্যালেন্ডার অ্যাপ তৈরি করতে চায় এবং চায় যে সেগুলি কোম্পানির নামের সাথে সংযুক্ত করে পৃথক অ্যাপ হিসেবে কাজ করবে।
আলাদা উৎস ব্যবহার করুন
এই ধরনের ক্ষেত্রে প্রস্তাবিত পদ্ধতি হল প্রতিটি ধারণাগতভাবে স্বতন্ত্র অ্যাপের নিজস্ব উৎসের জন্য লাইভ।
যদি আপনি তাদের সকলের ভিতরে একই ডোমেন নাম ব্যবহার করতে চান, তাহলে আপনি সাবডোমেন ব্যবহার করে এটি করতে পারেন। উদাহরণস্বরূপ, একাধিক ইন্টারনেট অ্যাপ বা পরিষেবা সরবরাহকারী একটি কোম্পানি https://mail.example.com এ একটি মেল অ্যাপ এবং https://calendar.example.com এ একটি ক্যালেন্ডার অ্যাপ হোস্ট করতে পারে, একই সাথে https://www.example.com এ তাদের ব্যবসার মূল পরিষেবা প্রদান করে। আরেকটি উদাহরণ হল একটি স্পোর্টস সাইট যা https://footballcup.example.com এ একটি ফুটবল চ্যাম্পিয়নশিপের মতো একটি গুরুত্বপূর্ণ ক্রীড়া ইভেন্টের জন্য সম্পূর্ণরূপে নিবেদিত একটি স্বাধীন অ্যাপ তৈরি করতে চায়, যা ব্যবহারকারীরা https://www.example.com এ হোস্ট করা মূল ক্রীড়া সাইট থেকে স্বাধীনভাবে ইনস্টল এবং ব্যবহার করতে পারে। এই পদ্ধতিটি এমন প্ল্যাটফর্মগুলির জন্যও কার্যকর হতে পারে যেখানে গ্রাহকরা কোম্পানির ব্র্যান্ডের অধীনে তাদের নিজস্ব স্বাধীন অ্যাপ তৈরি করতে দেয়। উদাহরণস্বরূপ, একটি অ্যাপ যা ব্যবসায়ীদের https://merchant1.example.com , https://merchant2.example.com ইত্যাদিতে তাদের নিজস্ব PWA তৈরি করতে দেয়।
বিভিন্ন উৎস ব্যবহার করলে অ্যাপগুলির মধ্যে বিচ্ছিন্নতা নিশ্চিত হয়, যার অর্থ হল প্রতিটি অ্যাপ স্বাধীনভাবে বিভিন্ন ব্রাউজার বৈশিষ্ট্য পরিচালনা করতে পারে, যার মধ্যে রয়েছে:
- ইনস্টলযোগ্যতা: প্রতিটি অ্যাপের নিজস্ব ম্যানিফেস্ট থাকে এবং এটি নিজস্ব ইনস্টলযোগ্য অভিজ্ঞতা প্রদান করে।
- স্টোরেজ: প্রতিটি অ্যাপের নিজস্ব ক্যাশে, স্থানীয় স্টোরেজ এবং মূলত সকল ধরণের ডিভাইস-স্থানীয় স্টোরেজ থাকে, অন্যদের সাথে শেয়ার না করেই।
- পরিষেবা কর্মী: প্রতিটি অ্যাপের নিবন্ধিত স্কোপের জন্য নিজস্ব পরিষেবা কর্মী রয়েছে।
- অনুমতি: অনুমতিগুলি উৎস অনুসারেও বিস্তৃত। এর ফলে, ব্যবহারকারীরা ঠিক জানেন যে তারা কোন পরিষেবার জন্য অনুমতি দিচ্ছেন এবং বিজ্ঞপ্তির মতো বৈশিষ্ট্যগুলি প্রতিটি অ্যাপের সাথে সঠিকভাবে যুক্ত করা হয়।
একাধিক, স্বাধীন PWA ব্যবহারের ক্ষেত্রে এই ধরণের বিচ্ছিন্নতা তৈরি করা সবচেয়ে কাম্য, তাই আমরা দৃঢ়ভাবে এই পদ্ধতির সুপারিশ করছি ।
যদি সাবডোমেনের অ্যাপগুলি একে অপরের সাথে স্থানীয় ডেটা ভাগ করতে চায় তবে তারা কুকিজের মাধ্যমে তা করতে পারে। আরও উন্নত পরিস্থিতিতে, তারা একটি সার্ভারের মাধ্যমে স্টোরেজ সিঙ্ক্রোনাইজ করতে পারে।
একই উৎস ব্যবহার করুন
দ্বিতীয় পদ্ধতি হল একই উৎসের উপর বিভিন্ন PWA তৈরি করা। এর মধ্যে নিম্নলিখিত পরিস্থিতিগুলি অন্তর্ভুক্ত রয়েছে:
অ-ওভারল্যাপিং পাথ
একাধিক PWA বা ধারণাগত "ওয়েব অ্যাপস", একই উৎসে হোস্ট করা, নন-ওভারল্যাপিং পাথ সহ। উদাহরণস্বরূপ:
-
https://example.com/app1/ -
https://example.com/app2/
ওভারল্যাপিং বা নেস্টেড পাথ
একই উৎসের একাধিক PWA, যার একটির স্কোপ অন্যটির ভিতরে অবস্থিত:
-
https://example.com/("বাইরের অ্যাপ") -
https://example.com/app/("ভিতরের অ্যাপ")
সার্ভিস ওয়ার্কার এপিআই এবং ম্যানিফেস্ট ফর্ম্যাট আপনাকে পাথ-লেভেল স্কোপিং ব্যবহার করে যেকোনো একটি করতে দেয়। যাইহোক, উভয় ক্ষেত্রেই, একই উৎস ব্যবহার করলে অনেক সমস্যা এবং সীমাবদ্ধতা দেখা দেয়, যার মূল কারণ হল ব্রাউজার এগুলিকে সম্পূর্ণরূপে স্বতন্ত্র "অ্যাপ" হিসাবে বিবেচনা করবে না, তাই এই পদ্ধতিটি নিরুৎসাহিত করা হয় ।
পরবর্তী বিভাগে, আমরা এই চ্যালেঞ্জগুলি আরও বিশদে বিশ্লেষণ করব, এবং যদি পৃথক উৎস ব্যবহার করা সম্ভব না হয় তবে কী করা যেতে পারে।
একাধিক, একই-উত্স PWA-এর জন্য চ্যালেঞ্জ
এখানে কিছু ব্যবহারিক সমস্যা রয়েছে যা উভয় একই-উদ্ভিদ পদ্ধতির ক্ষেত্রেই সাধারণ:
- স্টোরেজ: কুকিজ, স্থানীয় স্টোরেজ এবং সকল ধরণের ডিভাইস-স্থানীয় স্টোরেজ অ্যাপগুলির মধ্যে ভাগ করা হয়। সেই কারণে, যদি ব্যবহারকারী একটি অ্যাপের জন্য স্থানীয় ডেটা মুছে ফেলার সিদ্ধান্ত নেন, তাহলে এটি মূল থেকে সমস্ত ডেটা মুছে ফেলবে; একটি একক অ্যাপের জন্য এটি করার কোনও উপায় নেই। মনে রাখবেন যে Chrome এবং অন্যান্য কিছু ব্রাউজার সক্রিয়ভাবে ব্যবহারকারীদের একটি অ্যাপ আনইনস্টল করার সময় স্থানীয় ডেটা মুছে ফেলার জন্য অনুরোধ করবে এবং এটি মূল অ্যাপের অন্যান্য অ্যাপগুলির ডেটাও প্রভাবিত করবে। আরেকটি সমস্যা হল যে অ্যাপগুলিকে তাদের স্টোরেজ কোটাও ভাগ করে নিতে হবে যার অর্থ যদি তাদের মধ্যে কোনও একটি খুব বেশি জায়গা নেয়, তবে অন্যটি নেতিবাচকভাবে প্রভাবিত হবে।
- অনুমতি: ব্রাউজারের অনুমতিগুলি মূলের সাথে আবদ্ধ। এর অর্থ হল যদি ব্যবহারকারী একটি অ্যাপকে অনুমতি দেয়, তবে এটি একই সাথে সেই মূলের সমস্ত অ্যাপের জন্য প্রযোজ্য হবে। এটি একটি ভালো জিনিস বলে মনে হতে পারে (একাধিকবার অনুমতি চাইতে হবে না), তবে মনে রাখবেন: ব্যবহারকারী যদি একটি অ্যাপের অনুমতি ব্লক করে, তবে এটি অন্যদের সেই অনুমতির অনুরোধ করতে বা সেই বৈশিষ্ট্যটি ব্যবহার করতে বাধা দেবে। মনে রাখবেন যে ব্রাউজারের অনুমতিগুলি প্রতিটি অরিজিনকে কেবল একবার মঞ্জুর করার প্রয়োজন হলেও, অন্যদিকে সিস্টেম-স্তরের অনুমতিগুলি প্রতিটি অ্যাপকে একবার মঞ্জুর করতে হবে, একাধিক অ্যাপ একই অরিজিনকে নির্দেশ করে কিনা তা নির্বিশেষে।
- ব্যবহারকারীর সেটিংস: সেটিংসও প্রতিটি অরিজিন অনুসারে সেট করা হয়। উদাহরণস্বরূপ, যদি দুটি অ্যাপের ফন্টের আকার ভিন্ন হয় এবং ব্যবহারকারী তার ক্ষতিপূরণ দেওয়ার জন্য কেবল একটিতে জুম সামঞ্জস্য করতে চান, তাহলে তারা অন্যান্য অ্যাপগুলিতেও সেটিং প্রয়োগ না করে এটি করতে পারবেন না।
এই চ্যালেঞ্জগুলি এই পদ্ধতিকে উৎসাহিত করা কঠিন করে তোলে। তবুও, যদি আপনি "আলাদা অরিজিন ব্যবহার করা" বিভাগে আলোচনা করা হয়েছে এমন একটি পৃথক অরিজিন (যেমন একটি সাবডোমেন) ব্যবহার করতে না পারেন, তাহলে আমরা যে দুটি একই-অরিজিন বিকল্প উপস্থাপন করেছি, তার মধ্যে নন-ওভারল্যাপিং পাথ ব্যবহার করা জোরালোভাবে সুপারিশ করা হয়, ওভারল্যাপিং এবং নেস্টেড পাথের উপর।
যেমনটি উল্লেখ করা হয়েছে, এই বিভাগে আলোচিত চ্যালেঞ্জগুলি একই-উদ্ভূত উভয় পদ্ধতির ক্ষেত্রেই সাধারণ। পরবর্তী বিভাগে আমরা বিস্তারিতভাবে আলোচনা করব কেন ওভারল্যাপিং এবং নেস্টেড পাথ ব্যবহার করা সবচেয়ে কম প্রস্তাবিত কৌশল।
ওভারল্যাপিং এবং নেস্টেড পাথের জন্য অতিরিক্ত চ্যালেঞ্জ
ওভারল্যাপিং এবং নেস্টেড পাথ পদ্ধতির (যেখানে https://example.com/ হল বাইরের অ্যাপ এবং https://example.com/app/ হল ভিতরের অ্যাপ) অতিরিক্ত সমস্যা হল, ভিতরের অ্যাপের সমস্ত URL আসলে বাইরের অ্যাপ এবং ভিতরের অ্যাপ উভয়েরই অংশ হিসেবে বিবেচিত হবে।
বাস্তবে এটি নিম্নলিখিত সমস্যাগুলি উপস্থাপন করে:
- ইনস্টলেশন প্রচার: যদি ব্যবহারকারী ভিতরের অ্যাপটি পরিদর্শন করেন (উদাহরণস্বরূপ, একটি ওয়েব ব্রাউজারে), যখন বাইরের অ্যাপটি ইতিমধ্যেই ব্যবহারকারীর ডিভাইসে ইনস্টল করা থাকে, তখন ব্রাউজারটি ইনস্টল প্রচারমূলক ব্যানারগুলি দেখাবে না এবং BeforeInstallPrompt ইভেন্টটি ট্রিগার হবে না। কারণ হল ব্রাউজারটি পরীক্ষা করবে এবং দেখবে যে বর্তমান পৃষ্ঠাটি ইতিমধ্যেই ইনস্টল করা কোনও অ্যাপের কিনা, এবং এটি সিদ্ধান্তে আসবে যে এটিই। এর সমাধান হল ভিতরের অ্যাপটি ম্যানুয়ালি ইনস্টল করা ("শর্টকাট তৈরি করুন" ব্রাউজার মেনু বিকল্পের মাধ্যমে), অথবা বাইরের অ্যাপের আগে প্রথমে ভিতরের অ্যাপটি ইনস্টল করা।
- বিজ্ঞপ্তি এবং ব্যাজিং API : যদি বাইরের অ্যাপটি ইনস্টল করা থাকে কিন্তু ভিতরের অ্যাপটি না থাকে, তাহলে ভিতরের অ্যাপ থেকে আসা বিজ্ঞপ্তি এবং ব্যাজগুলি ভুল করে বাইরের অ্যাপের সাথে যুক্ত করা হবে (যা একটি ইনস্টল করা অ্যাপের নিকটতম এনক্লোজিং স্কোপ)। ব্যবহারকারীর ডিভাইসে উভয় অ্যাপই ইনস্টল করা থাকলে এই বৈশিষ্ট্যটি সঠিকভাবে কাজ করে।
- লিঙ্ক ক্যাপচারিং : বাইরের অ্যাপটি ভেতরের অ্যাপের URL গুলি ক্যাপচার করতে পারে। বিশেষ করে যদি বাইরের অ্যাপটি ইনস্টল করা থাকে কিন্তু ভেতরের অ্যাপটি না থাকে তাহলে এটি সম্ভব। একইভাবে, বাইরের অ্যাপের মধ্যে থাকা লিঙ্কগুলি ভেতরের অ্যাপের সাথে লিঙ্ক করা ক্যাপচার করবে না, কারণ এগুলি বাইরের অ্যাপের আওতার মধ্যে বিবেচিত হয়। অতিরিক্তভাবে, ChromeOS এবং Android-এ, যদি এই অ্যাপগুলি Play Store-এ যোগ করা হয় ( Trusted Web Activities হিসাবে), বাইরের অ্যাপটি সমস্ত লিঙ্ক ক্যাপচার করবে। এমনকি ভেতরের অ্যাপটি ইনস্টল করা থাকলেও, OS ব্যবহারকারীকে বাইরের অ্যাপে খোলার বিকল্প প্রদান করবে।
উপসংহার
আমরা বিভিন্ন উপায়ে দেখেছি কিভাবে ডেভেলপাররা একই ডোমেনের মধ্যে একে অপরের সাথে সম্পর্কিত একাধিক প্রগতিশীল ওয়েব অ্যাপ তৈরি করতে পারে।
সংক্ষেপে, আমরা দৃঢ়ভাবে সুপারিশ করছি যে স্বাধীন PWA হোস্ট করার জন্য একটি ভিন্ন অরিজিন (যেমন সাবডোমেন ব্যবহার করে) ব্যবহার করা উচিত। একই অরিজিনে এগুলি হোস্ট করা অনেক চ্যালেঞ্জের মুখোমুখি হয়, প্রধানত কারণ ব্রাউজার এগুলিকে সম্পূর্ণরূপে স্বতন্ত্র অ্যাপ হিসাবে বিবেচনা করবে না।
- পৃথক উৎস: প্রস্তাবিত
- একই উৎস, ওভারল্যাপিং নয় এমন পথ: প্রস্তাবিত নয়
- একই উৎস, ওভারল্যাপিং এবং নেস্টেড পাথ: দৃঢ়ভাবে সুপারিশ করা হয় না
যদি ভিন্ন ভিন্ন উৎস ব্যবহার করা সম্ভব না হয়, তাহলে নন-ওভারল্যাপিং পাথ ব্যবহার করে (যেমন https://example.com/app1/ এবং https://example.com/app2/ , তাহলে ওভারল্যাপিং বা নেস্টেড পাথ ব্যবহার না করার জন্য জোরালোভাবে সুপারিশ করা হচ্ছে, যেমন https://example.com/ (বাইরের অ্যাপের জন্য) এবং https://example.com/app/ (ভিতরের অ্যাপের জন্য)।
অতিরিক্ত সম্পদ
প্রযুক্তিগত পর্যালোচনা এবং পরামর্শের জন্য অনেক ধন্যবাদ: জো মেডলি, ডমিনিক এনজি, অ্যালান কাটার, ড্যানিয়েল মারফি, পেনি ম্যাকলাচলান, থমাস স্টেইনার এবং ডারউইন হুয়াং