একই ডোমেনে একাধিক প্রগতিশীল ওয়েব অ্যাপ তৈরি করা

একই ডোমেইন নামের সুবিধা নিয়ে ব্যবহারকারীকে সচেতন করতে যে তারা একই সংস্থা বা পরিষেবার অন্তর্গত একাধিক PWAs তৈরি করবেন।

Chase Phillips

Demián Renzulli

Matt Giuca

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

এই ধরনের সাইট আর্কিটেকচারের একটি উদাহরণ হল একটি ইকমার্স সাইট যেখানে:

• হোম পেজটি https://www.example.com এ রয়েছে।
• বিভাগ পৃষ্ঠাগুলি https://category.example.com এ হোস্ট করা হয়েছে।
• https://product.example.com এ পণ্যের বিস্তারিত পৃষ্ঠা।

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

একটি ইউনিফাইড প্রগ্রেসিভ ওয়েব অ্যাপ তৈরি করার চেষ্টা করার সময় একই সাইটের সাইট বিভাগের জন্য বিভিন্ন উত্স ব্যবহার করা এড়িয়ে চলুন।

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

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

পরিভাষা

• ডোমেইন: ডোমেন নেম সিস্টেম (DNS) এ সংজ্ঞায়িত লেবেলের যেকোনো ক্রম। যেমন: com এবং example.com হল ডোমেইন।
• হোস্টনাম: একটি DNS এন্ট্রি যা অন্তত একটি আইপি ঠিকানার সমাধান করে। উদাহরণস্বরূপ: www.example.com একটি হোস্টনাম হবে, example.com একটি হোস্টনাম হতে পারে যদি এটির একটি IP ঠিকানা থাকে এবং com কখনই একটি আইপি ঠিকানার সমাধান করবে না এবং তাই এটি কখনই হোস্টনাম হতে পারে না৷
• মূল: একটি স্কিম, হোস্টনাম এবং (ঐচ্ছিকভাবে) পোর্টের সংমিশ্রণ। উদাহরণস্বরূপ, https://www.example.com:443 হল একটি মূল৷

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

একাধিক, সম্পর্কিত PWA-এর ক্ষেত্রে

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

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

example.com-এর মালিক কোম্পানি তিনটি স্বাধীন অ্যাপ বা PWA প্রদান করতে চায়, তাদের মধ্যে সম্পর্ক স্থাপন করতে একই ডোমেন নাম ব্যবহার করে।

পৃথক উত্স ব্যবহার করে

এই ধরনের ক্ষেত্রে প্রস্তাবিত পদ্ধতি হল প্রতিটি ধারণাগতভাবে স্বতন্ত্র অ্যাপের নিজস্ব উৎস থেকে লাইভ।

আপনি যদি তাদের সবার ভিতরে একই ডোমেইন নাম ব্যবহার করতে চান তবে আপনি সাবডোমেন ব্যবহার করে তা করতে পারেন। উদাহরণ স্বরূপ, একাধিক ইন্টারনেট অ্যাপ বা পরিষেবা প্রদান করে এমন একটি কোম্পানি https://mail.example.com এ একটি মেল অ্যাপ এবং https://calendar.example.com এ একটি ক্যালেন্ডার অ্যাপ হোস্ট করতে পারে, যখন তাদের ব্যবসার প্রধান পরিষেবা প্রদান করে https: https://www.example.com এ। আরেকটি উদাহরণ হল একটি স্পোর্টস সাইট যেটি https://footballcup.example.com এ একটি ফুটবল চ্যাম্পিয়নশিপের মতো একটি গুরুত্বপূর্ণ ক্রীড়া ইভেন্টের জন্য সম্পূর্ণরূপে নিবেদিত একটি স্বাধীন অ্যাপ তৈরি করতে চায়, যা ব্যবহারকারীরা হোস্ট করা প্রধান ক্রীড়া সাইট থেকে স্বাধীনভাবে ইনস্টল এবং ব্যবহার করতে পারে https: https://www.example.com এ। এই পদ্ধতিটি এমন প্ল্যাটফর্মগুলির জন্যও কার্যকর হতে পারে যা গ্রাহকদের কোম্পানির ব্র্যান্ডের অধীনে তাদের নিজস্ব স্বাধীন অ্যাপ তৈরি করতে দেয়। উদাহরণস্বরূপ, একটি অ্যাপ যা ব্যবসায়ীদের https://merchant1.example.com , https://merchant2.example.com ইত্যাদিতে তাদের নিজস্ব PWA তৈরি করতে দেয়৷

বিভিন্ন অরিজিন ব্যবহার করা অ্যাপগুলির মধ্যে বিচ্ছিন্নতা নিশ্চিত করে, যার অর্থ তাদের প্রত্যেকটি স্বাধীনভাবে বিভিন্ন ব্রাউজার বৈশিষ্ট্য পরিচালনা করতে পারে, যার মধ্যে রয়েছে:

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

একাধিক, স্বাধীন পিডব্লিউএ-র ব্যবহারের ক্ষেত্রে এই ধরনের বিচ্ছিন্নতা তৈরি করা সবচেয়ে বেশি কাম্য, তাই আমরা দৃঢ়ভাবে এই পদ্ধতির সুপারিশ করি ।

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

সাবডোমেন ব্যবহার করে স্বতন্ত্র উৎপত্তিতে বিভিন্ন PWA তৈরি করা একটি ভালো অভ্যাস।

একই উত্স ব্যবহার করে

দ্বিতীয় পদ্ধতিটি একই উত্সে বিভিন্ন PWAs তৈরি করছে। এটি নিম্নলিখিত পরিস্থিতিতে অন্তর্ভুক্ত:

অ ওভারল্যাপিং পাথ

একাধিক পিডব্লিউএ বা ধারণাগত "ওয়েব অ্যাপ", একই মূলে হোস্ট করা, নন-ওভারল্যাপিং পাথ সহ। উদাহরণ স্বরূপ:

• https://example.com/app1/
• https://example.com/app2/

ওভারল্যাপিং/নেস্টেড পাথ

একই উৎপত্তিতে একাধিক PWA, যার একটি সুযোগ অন্যটির ভিতরে নেস্ট করা হয়েছে:

• https://example.com/ ("বাইরের অ্যাপ")
• https://example.com/app/ ("অভ্যন্তরীণ অ্যাপ")

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

একই মূলের অধীনে দুটি স্বাধীন PWA (“app1”, “app2”) প্রদান করতে পাথ (ওভারল্যাপ করা বা না) ব্যবহার করা নিরুৎসাহিত করা হয়।

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

একাধিক, একই-অরিজিন PWA-এর জন্য চ্যালেঞ্জ

এখানে কিছু ব্যবহারিক সমস্যা রয়েছে যা উভয় একই-উৎপত্তি পদ্ধতির জন্য সাধারণ:

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

এই চ্যালেঞ্জগুলি এই পদ্ধতিকে উত্সাহিত করা কঠিন করে তোলে। তা সত্ত্বেও, যদি আপনি একটি পৃথক উত্স (যেমন একটি সাবডোমেন) ব্যবহার করতে না পারেন, যেমনটি আমরা উপস্থাপন করেছি দুটি একই- উৎস বিকল্প থেকে, ওভারল্যাপিং/নেস্টেড পাথগুলি ব্যবহার করা দৃঢ়ভাবে সুপারিশ করা হয় .

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

ওভারল্যাপিং/নেস্টেড পাথের জন্য অতিরিক্ত চ্যালেঞ্জ

ওভারল্যাপিং/নেস্টেড পাথ অ্যাপ্রোচের অতিরিক্ত সমস্যা (যেখানে https://example.com/ হল বাইরের অ্যাপ এবং https://example.com/app/ হল অভ্যন্তরীণ অ্যাপ), তা হল অভ্যন্তরীণ অ্যাপের সমস্ত URL আসলে বাইরের অ্যাপ এবং অভ্যন্তরীণ অ্যাপ উভয়েরই অংশ হিসেবে বিবেচিত হবে।

অনুশীলনে এটি নিম্নলিখিত সমস্যাগুলি উপস্থাপন করে:

• ইনস্টলেশন প্রচার: ব্যবহারকারী যদি অভ্যন্তরীণ অ্যাপটি দেখেন (উদাহরণস্বরূপ, একটি ওয়েব ব্রাউজারে), যখন বাইরের অ্যাপটি ইতিমধ্যেই ব্যবহারকারীর ডিভাইসে ইনস্টল করা থাকে, ব্রাউজারটি প্রচারমূলক ব্যানারগুলি ইনস্টল করবে না এবং BeforeInstallPrompt ইভেন্টটি দেখাবে না ট্রিগার করা কারণ হল যে ব্রাউজারটি পরীক্ষা করবে এবং দেখতে পাবে যে বর্তমান পৃষ্ঠাটি ইতিমধ্যে ইনস্টল করা একটি অ্যাপের অন্তর্গত কিনা এবং এটি উপসংহারে আসবে যে এটি। এর জন্য সমাধান হল ভিতরের অ্যাপটিকে ম্যানুয়ালি ইনস্টল করা ("শর্টকাট তৈরি করুন" ব্রাউজার মেনু বিকল্পের মাধ্যমে), অথবা বাইরের অ্যাপের আগে প্রথমে ভিতরের অ্যাপটি ইনস্টল করা।
• বিজ্ঞপ্তি এবং ব্যাজিং এপিআই : যদি বাইরের অ্যাপটি ইনস্টল করা থাকে কিন্তু ভিতরের অ্যাপটি না থাকে, তাহলে অভ্যন্তরীণ অ্যাপ থেকে আসা বিজ্ঞপ্তি এবং ব্যাজগুলি ভুলভাবে বাইরের অ্যাপে দায়ী করা হবে (যা একটি ইনস্টল করা অ্যাপের সবচেয়ে কাছের এনক্লোজিং স্কোপ)। এই বৈশিষ্ট্যটি সঠিকভাবে কাজ করে যেখানে উভয় অ্যাপ ব্যবহারকারীর ডিভাইসে ইনস্টল করা আছে।
• লিঙ্ক ক্যাপচারিং : বাইরের অ্যাপটি অভ্যন্তরীণ অ্যাপের অন্তর্গত URLগুলি ক্যাপচার করতে পারে। এটি বিশেষত সম্ভবত যদি বাইরের অ্যাপটি ইনস্টল করা থাকে কিন্তু ভিতরের অ্যাপটি না থাকে। একইভাবে, বাইরের অ্যাপের মধ্যে যে লিঙ্কগুলি অভ্যন্তরীণ অ্যাপের সাথে লিঙ্ক করে সেগুলি অভ্যন্তরীণ অ্যাপে ক্যাপচারকে লিঙ্ক করবে না, কারণ সেগুলিকে বাইরের অ্যাপের সুযোগের মধ্যে বিবেচনা করা হয়। উপরন্তু, ChromeOS এবং Android-এ, যদি এই অ্যাপগুলিকে Play Store-এ যোগ করা হয় ( বিশ্বস্ত ওয়েব অ্যাক্টিভিটি হিসেবে), বাইরের অ্যাপটি সমস্ত লিঙ্ক ক্যাপচার করবে। এমনকি অভ্যন্তরীণ অ্যাপ ইনস্টল করা থাকলেও, OS এখনও ব্যবহারকারীকে বাইরের অ্যাপে খোলার পছন্দ অফার করবে।

উপসংহার

এই নিবন্ধে আমরা বিভিন্ন উপায়ে দেখেছি যাতে বিকাশকারীরা একই ডোমেনের মধ্যে একে অপরের সাথে সম্পর্কিত একাধিক প্রগতিশীল ওয়েব অ্যাপ তৈরি করতে পারে৷

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

• পৃথক উত্স: প্রস্তাবিত
• একই উত্স, নন-ওভারল্যাপিং পাথ: প্রস্তাবিত নয়৷
• একই মূল, ওভারল্যাপিং/নেস্টেড পাথ: দৃঢ়ভাবে সুপারিশ করা হয় না

অ-ওভারল্যাপিং পাথ (যেমন https://example.com/app1/ এবং https://example.com/app2/ ব্যবহার করে বিভিন্ন উত্স ব্যবহার করা সম্ভব না হলে ওভারল্যাপিং বা নেস্টেড পাথ ব্যবহার করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়, যেমন https://example.com/ (বাইরের অ্যাপের জন্য) এবং https://example.com/app/ (অভ্যন্তরীণ অ্যাপের জন্য)।

অতিরিক্ত সম্পদ

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

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

আনস্প্ল্যাশে টিম মোসহোল্ডারের ছবি