ساخت چندین برنامه وب پیشرفته در یک دامنه

چگونه می توان چندین PWA را با استفاده از یک نام دامنه ایجاد کرد تا به کاربر اطلاع دهد که متعلق به یک سازمان یا سرویس است.

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 که حداقل به یک آدرس 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 میزبانی شده است، نصب و استفاده کنند. این رویکرد همچنین ممکن است برای پلتفرم‌هایی مفید باشد که به مشتریان اجازه می‌دهند برنامه‌های مستقل خود را تحت برند شرکت ایجاد کنند. به عنوان مثال، برنامه‌ای که به بازرگانان اجازه می‌دهد PWA خود را در https://merchant1.example.com ، https://merchant2.example.com و غیره ایجاد کنند.

استفاده از مبداهای مختلف جداسازی بین برنامه ها را تضمین می کند، به این معنی که هر یک از آنها می توانند ویژگی های مختلف مرورگر را به طور مستقل مدیریت کنند، از جمله:

• قابلیت نصب: هر برنامه مانیفست مخصوص به خود را دارد و تجربه قابل نصب خود را ارائه می دهد.
• فضای ذخیره‌سازی: هر برنامه دارای حافظه پنهان، حافظه محلی و اساساً همه اشکال حافظه محلی دستگاه است، بدون اینکه آنها را با دیگران به اشتراک بگذارد.
• Service Workers: هر برنامه برای محدوده های ثبت شده سرویس دهنده خاص خود را دارد.
• مجوزها: مجوزها نیز بر اساس مبدا تعیین می شوند. به لطف آن، کاربران دقیقاً می دانند که برای کدام سرویس مجوز می دهند و ویژگی هایی مانند اعلان ها به درستی به هر برنامه نسبت داده می شود.

ایجاد چنین درجه ای از انزوا در مورد استفاده از PWA های چندگانه مستقل، مطلوب ترین است، بنابراین ما به شدت این رویکرد را توصیه می کنیم .

اگر برنامه‌های زیر دامنه‌ها بخواهند داده‌های محلی را با یکدیگر به اشتراک بگذارند، همچنان می‌توانند این کار را از طریق کوکی‌ها انجام دهند، یا برای سناریوهای پیشرفته‌تر، می‌توانند همگام‌سازی فضای ذخیره‌سازی را از طریق یک سرور در نظر بگیرند.

با استفاده از همان مبدا

رویکرد دوم ساخت PWA های مختلف بر روی یک مبدا است. این شامل حالات زیر است:

مسیرهای غیر همپوشانی

چند PWA یا «برنامه‌های وب» مفهومی، که در یک مبدا میزبانی می‌شوند، با مسیرهای غیر همپوشانی. به عنوان مثال:

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

مسیرهای همپوشانی/تودرتو

چندین PWA در یک مبدا که یکی از آنها در داخل دیگری قرار دارد:

• https://example.com/ ("برنامه بیرونی")
• https://example.com/app/ ("برنامه داخلی")

Service worker API و فرمت مانیفست به شما امکان می دهد یکی از موارد بالا را با استفاده از محدوده سطح مسیر انجام دهید. با این حال، در هر دو مورد، استفاده از مبدأ یکسان مشکلات و محدودیت‌های زیادی را به همراه دارد، که ریشه آن از این واقعیت ناشی می‌شود که مرورگر به طور کامل آنها را «برنامه‌های» متمایز در نظر نمی‌گیرد، بنابراین از این رویکرد جلوگیری می‌شود .

در بخش بعدی، این چالش ها را با جزئیات بیشتری تجزیه و تحلیل می کنیم و اگر استفاده از مبداهای جداگانه گزینه ای نباشد، چه کاری می توان انجام داد.

چالش‌هایی برای چندین PWA با منشاء مشابه

در اینجا برخی از مسائل عملی مشترک برای هر دو رویکرد یکسان وجود دارد:

• فضای ذخیره‌سازی: کوکی‌ها، فضای ذخیره‌سازی محلی و همه اشکال ذخیره‌سازی محلی دستگاه بین برنامه‌ها به اشتراک گذاشته می‌شوند. به همین دلیل، اگر کاربر تصمیم بگیرد که داده های محلی یک برنامه را پاک کند، تمام داده ها را از مبدا پاک می کند. هیچ راهی برای انجام این کار برای یک برنامه وجود ندارد. توجه داشته باشید که Chrome و برخی از مرورگرهای دیگر هنگام حذف نصب یکی از برنامه‌ها به طور فعال از کاربران می‌خواهند که داده‌های محلی را پاک کنند و این روی داده‌های سایر برنامه‌ها در مبدا نیز تأثیر می‌گذارد. مسئله دیگر این است که برنامه ها نیز باید سهمیه ذخیره سازی خود را به اشتراک بگذارند، به این معنی که اگر هر یک از آنها فضای زیادی را اشغال کند، دیگری تأثیر منفی خواهد داشت.
• مجوزها: مجوزهای مرورگر به مبدا گره خورده است. این بدان معناست که اگر کاربر به یک برنامه مجوز بدهد، به طور همزمان برای همه برنامه های موجود در آن مبدا اعمال می شود. این ممکن است چیز خوبی به نظر برسد (عدم درخواست چندین بار مجوز)، اما به یاد داشته باشید: اگر کاربر مجوز یک برنامه را مسدود کند، از درخواست دیگران یا استفاده از آن ویژگی جلوگیری می کند. توجه داشته باشید که حتی اگر مجوزهای مرورگر فقط یک بار در هر مبدأ اعطا شود، از طرف دیگر مجوزهای سطح سیستم باید یک بار به هر برنامه داده شود، صرف نظر از اینکه آیا چندین برنامه به یک مبدا اشاره می کنند یا خیر.
• تنظیمات کاربر: تنظیمات نیز بر اساس مبدا تنظیم می شوند. به عنوان مثال، اگر دو برنامه اندازه فونت متفاوتی داشته باشند و کاربر بخواهد بزرگنمایی را فقط در یکی از آنها تنظیم کند تا آن را جبران کند، نمی‌تواند بدون اعمال تنظیمات روی سایر برنامه‌ها نیز این کار را انجام دهد.

این چالش ها تشویق به این رویکرد را دشوار می کند. با این وجود، اگر نمی‌توانید از یک مبدأ جداگانه (مثلاً یک زیر دامنه)، همانطور که در بخش استفاده از مبدا جداگانه بحث شد، از دو گزینه با مبدا یکسانی که ارائه کردیم، استفاده کنید، استفاده از مسیرهای غیر همپوشانی، روی مسیرهای همپوشانی/تودرتو توصیه می‌شود.

همانطور که گفته شد، چالش‌های مورد بحث در این بخش برای هر دو رویکرد یکسان مشترک است. در بخش بعدی به جزئیات بیشتر می پردازیم که چرا استفاده از مسیرهای همپوشانی/تودرتو کمترین استراتژی توصیه شده است.

چالش‌های اضافی برای مسیرهای همپوشانی/تودرتو

مشکل اضافی با رویکرد مسیرهای همپوشانی/تودرتو (که در آن https://example.com/ برنامه بیرونی و https://example.com/app/ برنامه داخلی است)، این است که همه URL ها در برنامه داخلی در واقع بخشی از برنامه بیرونی و برنامه داخلی در نظر گرفته می شوند.

در عمل این مسائل زیر را نشان می دهد:

• ارتقای نصب: اگر کاربر از برنامه داخلی بازدید کند (مثلاً در یک مرورگر وب)، وقتی برنامه خارجی قبلاً در دستگاه کاربر نصب شده است، مرورگر بنرهای تبلیغاتی نصب را نشان نمی‌دهد و رویداد BeforeInstallPrompt فعال نمی‌شود. دلیل آن این است که مرورگر بررسی می کند و می بیند که آیا صفحه فعلی متعلق به برنامه ای است که قبلاً نصب شده است یا خیر و به این نتیجه می رسد که اینگونه است. راه حل این است که برنامه داخلی را به صورت دستی نصب کنید (از طریق گزینه منوی مرورگر "ایجاد میانبر")، یا ابتدا برنامه داخلی را قبل از برنامه خارجی نصب کنید.
• Notification and Badging API : اگر برنامه بیرونی نصب شده باشد اما برنامه داخلی نصب نشده باشد، اعلان‌ها و نشان‌هایی که از برنامه داخلی می‌آیند به اشتباه به برنامه خارجی (که نزدیک‌ترین محدوده برنامه نصب‌شده است) نسبت داده می‌شوند. این ویژگی در مواردی که هر دو برنامه روی دستگاه کاربر نصب شده باشند به درستی کار می کند.
• ضبط پیوند : برنامه بیرونی ممکن است نشانی‌های اینترنتی متعلق به برنامه داخلی را بگیرد. این امر به ویژه در صورتی محتمل است که برنامه بیرونی نصب شده باشد اما برنامه داخلی نصب نشده باشد. به طور مشابه، پیوندهای درون برنامه بیرونی که به برنامه داخلی پیوند دارند، ضبط را به برنامه داخلی پیوند نمی‌دهند، زیرا در محدوده برنامه بیرونی در نظر گرفته می‌شوند. علاوه بر این، در ChromeOS و Android، اگر این برنامه‌ها به فروشگاه Play اضافه شوند (به عنوان فعالیت‌های وب مورد اعتماد )، برنامه بیرونی همه پیوندها را می‌گیرد. حتی اگر برنامه داخلی نصب شده باشد، سیستم عامل همچنان به کاربر این امکان را می دهد که آنها را در برنامه بیرونی باز کند.

نتیجه گیری

در این مقاله راه‌های مختلفی را بررسی کردیم که توسعه‌دهندگان می‌توانند چندین برنامه وب پیشرو مرتبط با یکدیگر را در یک دامنه بسازند.

به طور خلاصه، ما قویاً توصیه می‌کنیم که از مبدأ متفاوت (مثلاً با استفاده از زیر دامنه‌ها) برای میزبانی PWA مستقل استفاده کنید. میزبانی آنها در همان مبدا چالش‌های زیادی را به همراه دارد، عمدتاً به این دلیل که مرورگر به طور کامل آنها را برنامه‌های مجزا نمی‌داند.

• منشاء جداگانه: توصیه می شود
• مبدأ یکسان، مسیرهای غیر همپوشانی: توصیه نمی شود
• مبدا یکسان، مسیرهای همپوشانی/تودرتو: به شدت توصیه نمی شود

اگر امکان استفاده از مبداهای مختلف وجود ندارد، از مسیرهای غیرهمپوشانی (مانند https://example.com/app1/ و https://example.com/app2/ ) استفاده کنید، اکیداً توصیه می شود از مسیرهای همپوشانی یا تودرتو مانند https://example.com/ (برای برنامه بیرونی) و https://example.com/app/ (برای برنامه داخلی) استفاده کنید.

منابع اضافی

• برنامه های وب پیشرو در سایت های چند منبع

با تشکر فراوان از نظرات و پیشنهادات فنی آنها: جو مدلی، دومینیک انگ، آلن کاتر، دانیل مورفی، پنی مک لاکلان، توماس اشتاینر و داروین هوانگ

عکس توسط تیم موشولدر در Unsplash

چگونه می توان چندین PWA را با استفاده از یک نام دامنه ایجاد کرد تا به کاربر اطلاع دهد که متعلق به یک سازمان یا سرویس است.

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 که حداقل به یک آدرس 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 میزبانی شده است، نصب و استفاده کنند. این رویکرد همچنین ممکن است برای پلتفرم‌هایی مفید باشد که به مشتریان اجازه می‌دهند برنامه‌های مستقل خود را تحت برند شرکت ایجاد کنند. به عنوان مثال، برنامه‌ای که به بازرگانان اجازه می‌دهد PWA خود را در https://merchant1.example.com ، https://merchant2.example.com و غیره ایجاد کنند.

استفاده از مبداهای مختلف جداسازی بین برنامه ها را تضمین می کند، به این معنی که هر یک از آنها می توانند ویژگی های مختلف مرورگر را به طور مستقل مدیریت کنند، از جمله:

• قابلیت نصب: هر برنامه مانیفست مخصوص به خود را دارد و تجربه قابل نصب خود را ارائه می دهد.
• فضای ذخیره‌سازی: هر برنامه دارای حافظه پنهان، حافظه محلی و اساساً همه اشکال حافظه محلی دستگاه است، بدون اینکه آنها را با دیگران به اشتراک بگذارد.
• Service Workers: هر برنامه برای محدوده های ثبت شده سرویس دهنده خاص خود را دارد.
• مجوزها: مجوزها نیز بر اساس مبدا تعیین می شوند. به لطف آن، کاربران دقیقاً می دانند که برای کدام سرویس مجوز می دهند و ویژگی هایی مانند اعلان ها به درستی به هر برنامه نسبت داده می شود.

ایجاد چنین درجه ای از انزوا در مورد استفاده از PWA های چندگانه مستقل، مطلوب ترین است، بنابراین ما به شدت این رویکرد را توصیه می کنیم .

اگر برنامه‌های زیر دامنه‌ها بخواهند داده‌های محلی را با یکدیگر به اشتراک بگذارند، همچنان می‌توانند این کار را از طریق کوکی‌ها انجام دهند، یا برای سناریوهای پیشرفته‌تر، می‌توانند همگام‌سازی فضای ذخیره‌سازی را از طریق یک سرور در نظر بگیرند.

با استفاده از همان مبدا

رویکرد دوم ساخت PWA های مختلف بر روی یک مبدا است. این شامل حالات زیر است:

مسیرهای غیر همپوشانی

چند PWA یا «برنامه‌های وب» مفهومی، که در یک مبدا میزبانی می‌شوند، با مسیرهای غیر همپوشانی. به عنوان مثال:

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

مسیرهای همپوشانی/تودرتو

چندین PWA در یک مبدا که یکی از آنها در داخل دیگری قرار دارد:

• https://example.com/ ("برنامه بیرونی")
• https://example.com/app/ ("برنامه داخلی")

Service worker API و فرمت مانیفست به شما امکان می دهد یکی از موارد بالا را با استفاده از محدوده سطح مسیر انجام دهید. با این حال، در هر دو مورد، استفاده از مبدأ یکسان مشکلات و محدودیت‌های زیادی را به همراه دارد، که ریشه آن از این واقعیت ناشی می‌شود که مرورگر به طور کامل آنها را «برنامه‌های» متمایز در نظر نمی‌گیرد، بنابراین از این رویکرد جلوگیری می‌شود .

در بخش بعدی، این چالش ها را با جزئیات بیشتری تجزیه و تحلیل می کنیم و اگر استفاده از مبداهای جداگانه گزینه ای نباشد، چه کاری می توان انجام داد.

چالش‌هایی برای چندین PWA با منشاء مشابه

در اینجا برخی از مسائل عملی مشترک برای هر دو رویکرد یکسان وجود دارد:

• فضای ذخیره‌سازی: کوکی‌ها، فضای ذخیره‌سازی محلی و همه اشکال ذخیره‌سازی محلی دستگاه بین برنامه‌ها به اشتراک گذاشته می‌شوند. به همین دلیل، اگر کاربر تصمیم بگیرد که داده های محلی یک برنامه را پاک کند، تمام داده ها را از مبدا پاک می کند. هیچ راهی برای انجام این کار برای یک برنامه وجود ندارد. توجه داشته باشید که Chrome و برخی از مرورگرهای دیگر هنگام حذف نصب یکی از برنامه‌ها به طور فعال از کاربران می‌خواهند که داده‌های محلی را پاک کنند و این روی داده‌های سایر برنامه‌ها در مبدا نیز تأثیر می‌گذارد. مسئله دیگر این است که برنامه ها نیز باید سهمیه ذخیره سازی خود را به اشتراک بگذارند، به این معنی که اگر هر یک از آنها فضای زیادی را اشغال کند، دیگری تأثیر منفی خواهد داشت.
• مجوزها: مجوزهای مرورگر به مبدا گره خورده است. این بدان معناست که اگر کاربر به یک برنامه مجوز بدهد، به طور همزمان برای همه برنامه های موجود در آن مبدا اعمال می شود. این ممکن است چیز خوبی به نظر برسد (عدم درخواست چندین بار مجوز)، اما به یاد داشته باشید: اگر کاربر مجوز یک برنامه را مسدود کند، از درخواست دیگران یا استفاده از آن ویژگی جلوگیری می کند. توجه داشته باشید که حتی اگر مجوزهای مرورگر فقط یک بار در هر مبدأ اعطا شود، از طرف دیگر مجوزهای سطح سیستم باید یک بار به هر برنامه داده شود، صرف نظر از اینکه آیا چندین برنامه به یک مبدا اشاره می کنند یا خیر.
• تنظیمات کاربر: تنظیمات نیز بر اساس مبدا تنظیم می شوند. به عنوان مثال، اگر دو برنامه اندازه فونت متفاوتی داشته باشند و کاربر بخواهد بزرگنمایی را فقط در یکی از آنها تنظیم کند تا آن را جبران کند، نمی‌تواند بدون اعمال تنظیمات روی سایر برنامه‌ها نیز این کار را انجام دهد.

این چالش ها تشویق به این رویکرد را دشوار می کند. با این وجود، اگر نمی‌توانید از یک مبدأ جداگانه (مثلاً یک زیر دامنه)، همانطور که در بخش استفاده از مبدا جداگانه بحث شد، از دو گزینه با مبدا یکسانی که ارائه کردیم، استفاده کنید، استفاده از مسیرهای غیر همپوشانی، روی مسیرهای همپوشانی/تودرتو توصیه می‌شود.

همانطور که گفته شد، چالش‌های مورد بحث در این بخش برای هر دو رویکرد یکسان مشترک است. در بخش بعدی به جزئیات بیشتر می پردازیم که چرا استفاده از مسیرهای همپوشانی/تودرتو کمترین استراتژی توصیه شده است.

چالش‌های اضافی برای مسیرهای همپوشانی/تودرتو

مشکل اضافی با رویکرد مسیرهای همپوشانی/تودرتو (که در آن https://example.com/ برنامه بیرونی و https://example.com/app/ برنامه داخلی است)، این است که همه URL ها در برنامه داخلی در واقع بخشی از برنامه بیرونی و برنامه داخلی در نظر گرفته می شوند.

در عمل این مسائل زیر را نشان می دهد:

• ارتقای نصب: اگر کاربر از برنامه داخلی بازدید کند (مثلاً در یک مرورگر وب)، وقتی برنامه خارجی قبلاً در دستگاه کاربر نصب شده است، مرورگر بنرهای تبلیغاتی نصب را نشان نمی‌دهد و رویداد BeforeInstallPrompt فعال نمی‌شود. دلیل آن این است که مرورگر بررسی می کند و می بیند که آیا صفحه فعلی متعلق به برنامه ای است که قبلاً نصب شده است یا خیر و به این نتیجه می رسد که اینگونه است. راه حل این است که برنامه داخلی را به صورت دستی نصب کنید (از طریق گزینه منوی مرورگر "ایجاد میانبر")، یا ابتدا برنامه داخلی را قبل از برنامه خارجی نصب کنید.
• Notification and Badging API : اگر برنامه بیرونی نصب شده باشد اما برنامه داخلی نصب نشده باشد، اعلان‌ها و نشان‌هایی که از برنامه داخلی می‌آیند به اشتباه به برنامه خارجی (که نزدیک‌ترین محدوده برنامه نصب‌شده است) نسبت داده می‌شوند. این ویژگی در مواردی که هر دو برنامه روی دستگاه کاربر نصب شده باشند به درستی کار می کند.
• ضبط پیوند : برنامه بیرونی ممکن است نشانی‌های اینترنتی متعلق به برنامه داخلی را بگیرد. این امر به ویژه در صورتی محتمل است که برنامه بیرونی نصب شده باشد اما برنامه داخلی نصب نشده باشد. به طور مشابه، پیوندهای درون برنامه بیرونی که به برنامه داخلی پیوند دارند، ضبط را به برنامه داخلی پیوند نمی‌دهند، زیرا در محدوده برنامه بیرونی در نظر گرفته می‌شوند. علاوه بر این، در ChromeOS و Android، اگر این برنامه‌ها به فروشگاه Play اضافه شوند (به عنوان فعالیت‌های وب مورد اعتماد )، برنامه بیرونی همه پیوندها را می‌گیرد. حتی اگر برنامه داخلی نصب شده باشد، سیستم عامل همچنان به کاربر این امکان را می دهد که آنها را در برنامه بیرونی باز کند.

نتیجه گیری

در این مقاله راه‌های مختلفی را بررسی کردیم که توسعه‌دهندگان می‌توانند چندین برنامه وب پیشرو مرتبط با یکدیگر را در یک دامنه بسازند.

به طور خلاصه، ما قویاً توصیه می‌کنیم که از مبدأ متفاوت (مثلاً با استفاده از زیر دامنه‌ها) برای میزبانی PWA مستقل استفاده کنید. میزبانی آنها در همان مبدا چالش‌های زیادی را به همراه دارد، عمدتاً به این دلیل که مرورگر به طور کامل آنها را برنامه‌های مجزا نمی‌داند.

• منشاء جداگانه: توصیه می شود
• مبدأ یکسان، مسیرهای غیر همپوشانی: توصیه نمی شود
• مبدا یکسان، مسیرهای همپوشانی/تودرتو: به شدت توصیه نمی شود

اگر امکان استفاده از مبداهای مختلف وجود ندارد، از مسیرهای غیرهمپوشانی (مانند https://example.com/app1/ و https://example.com/app2/ ) استفاده کنید، اکیداً توصیه می شود از مسیرهای همپوشانی یا تودرتو مانند https://example.com/ (برای برنامه بیرونی) و https://example.com/app/ (برای برنامه داخلی) استفاده کنید.

منابع اضافی

• برنامه های وب پیشرو در سایت های چند منبع

با تشکر فراوان از نظرات و پیشنهادات فنی آنها: جو مدلی، دومینیک انگ، آلن کاتر، دانیل مورفی، پنی مک لاکلان، توماس اشتاینر و داروین هوانگ

عکس توسط تیم موشولدر در Unsplash

چگونه می توان چندین PWA را با استفاده از یک نام دامنه ایجاد کرد تا به کاربر اطلاع دهد که متعلق به یک سازمان یا سرویس است.

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 که حداقل به یک آدرس 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 میزبانی شده است، نصب و استفاده کنند. این رویکرد همچنین ممکن است برای پلتفرم‌هایی مفید باشد که به مشتریان اجازه می‌دهند برنامه‌های مستقل خود را تحت برند شرکت ایجاد کنند. به عنوان مثال، برنامه‌ای که به بازرگانان اجازه می‌دهد PWA خود را در https://merchant1.example.com ، https://merchant2.example.com و غیره ایجاد کنند.

استفاده از مبداهای مختلف جداسازی بین برنامه ها را تضمین می کند، به این معنی که هر یک از آنها می توانند ویژگی های مختلف مرورگر را به طور مستقل مدیریت کنند، از جمله:

• قابلیت نصب: هر برنامه مانیفست مخصوص به خود را دارد و تجربه قابل نصب خود را ارائه می دهد.
• فضای ذخیره‌سازی: هر برنامه دارای حافظه پنهان، حافظه محلی و اساساً همه اشکال حافظه محلی دستگاه است، بدون اینکه آنها را با دیگران به اشتراک بگذارد.
• Service Workers: هر برنامه برای محدوده های ثبت شده سرویس دهنده خاص خود را دارد.
• مجوزها: مجوزها نیز بر اساس مبدا تعیین می شوند. به لطف آن، کاربران دقیقاً می دانند که برای کدام سرویس مجوز می دهند و ویژگی هایی مانند اعلان ها به درستی به هر برنامه نسبت داده می شود.

ایجاد چنین درجه ای از انزوا در مورد استفاده از PWA های چندگانه مستقل، مطلوب ترین است، بنابراین ما به شدت این رویکرد را توصیه می کنیم .

اگر برنامه‌های زیر دامنه‌ها بخواهند داده‌های محلی را با یکدیگر به اشتراک بگذارند، همچنان می‌توانند این کار را از طریق کوکی‌ها انجام دهند، یا برای سناریوهای پیشرفته‌تر، می‌توانند همگام‌سازی فضای ذخیره‌سازی را از طریق یک سرور در نظر بگیرند.

با استفاده از همان مبدا

رویکرد دوم ساخت PWA های مختلف بر روی یک مبدا است. این شامل حالات زیر است:

مسیرهای غیر همپوشانی

چند PWA یا «برنامه‌های وب» مفهومی، که در یک مبدا میزبانی می‌شوند، با مسیرهای غیر همپوشانی. به عنوان مثال:

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

مسیرهای همپوشانی/تودرتو

چندین PWA در یک مبدا که یکی از آنها در داخل دیگری قرار دارد:

• https://example.com/ ("برنامه بیرونی")
• https://example.com/app/ ("برنامه داخلی")

Service worker API و فرمت مانیفست به شما امکان می دهد یکی از موارد بالا را با استفاده از محدوده سطح مسیر انجام دهید. با این حال، در هر دو مورد، استفاده از مبدأ یکسان مشکلات و محدودیت‌های زیادی را به همراه دارد، که ریشه آن از این واقعیت ناشی می‌شود که مرورگر به طور کامل آنها را «برنامه‌های» متمایز در نظر نمی‌گیرد، بنابراین از این رویکرد جلوگیری می‌شود .

در بخش بعدی، این چالش ها را با جزئیات بیشتری تجزیه و تحلیل می کنیم و اگر استفاده از مبداهای جداگانه گزینه ای نباشد، چه کاری می توان انجام داد.

چالش‌هایی برای چندین PWA با منشاء مشابه

در اینجا برخی از مسائل عملی مشترک برای هر دو رویکرد یکسان وجود دارد:

• فضای ذخیره‌سازی: کوکی‌ها، فضای ذخیره‌سازی محلی و همه اشکال ذخیره‌سازی محلی دستگاه بین برنامه‌ها به اشتراک گذاشته می‌شوند. به همین دلیل، اگر کاربر تصمیم بگیرد که داده های محلی یک برنامه را پاک کند، تمام داده ها را از مبدا پاک می کند. هیچ راهی برای انجام این کار برای یک برنامه وجود ندارد. توجه داشته باشید که Chrome و برخی از مرورگرهای دیگر هنگام حذف نصب یکی از برنامه‌ها به طور فعال از کاربران می‌خواهند که داده‌های محلی را پاک کنند و این روی داده‌های سایر برنامه‌ها در مبدا نیز تأثیر می‌گذارد. مسئله دیگر این است که برنامه ها نیز باید سهمیه ذخیره سازی خود را به اشتراک بگذارند ، به این معنی که اگر هر یک از آنها فضای زیادی را به خود اختصاص دهند ، دیگری تحت تأثیر منفی قرار می گیرد.
• مجوزها: مجوزهای مرورگر به مبدا گره خورده است. این بدان معناست که اگر کاربر اجازه یک برنامه را اعطا کند ، به طور همزمان برای کلیه برنامه های موجود در آن مبدا اعمال می شود. این ممکن است مانند یک چیز خوب به نظر برسد (نیازی به درخواست مجوز چندین بار نیست) ، اما به یاد داشته باشید: اگر کاربر اجازه یک برنامه را مسدود کند ، دیگران را از درخواست آن مجوز یا استفاده از آن ویژگی جلوگیری می کند. توجه داشته باشید که حتی اگر مجوزهای مرورگر فقط یک بار در هر مبدأ اعطا شود ، مجوزهای سطح سیستم از طرف دیگر باید یک بار در هر برنامه اعطا شود ، صرف نظر از اینکه چندین برنامه به همان منشاء اشاره دارند.
• تنظیمات کاربر: تنظیمات نیز در هر منبعی تنظیم شده است. به عنوان مثال ، اگر دو برنامه اندازه فونت های مختلف داشته باشند ، و کاربر می خواهد بزرگنمایی را فقط در یکی از آنها تنظیم کند تا آن را جبران کند ، آنها بدون استفاده از تنظیمات در برنامه های دیگر قادر به انجام این کار نخواهند بود.

این چالش ها تشویق این رویکرد را دشوار می کند. با این وجود ، اگر نمی توانید از منشأ جداگانه (به عنوان مثال زیر دامنه) استفاده کنید ، همانطور که در بخش استفاده از مبدا جداگانه مورد بحث قرار گرفته است ، از دو گزینه همان منبعی که ارائه کردیم ، با استفاده از مسیرهای غیر همپوشانی به شدت توصیه می شود ، بیش از مسیرهای همپوشانی/تو در تو.

همانطور که گفته شد ، چالش های مورد بحث در این بخش برای هر دو رویکرد همان منشی مشترک است. در بخش بعدی ما به جزئیات بیشتر می پردازیم که چرا استفاده از مسیرهای همپوشانی/تو در تو کمترین استراتژی توصیه شده است.

چالش های اضافی برای راه های همپوشانی/تو در تو

مسئله اضافی با رویکرد مسیرهای همپوشانی/تو در تو (جایی که https://example.com/ برنامه بیرونی است و https://example.com/app/ برنامه داخلی است) ، این است که تمام URL های موجود در برنامه داخلی در واقع بخشی از برنامه بیرونی و برنامه درونی در نظر گرفته می شوند.

در عمل این موارد زیر را ارائه می دهد:

• ارتقاء نصب: اگر کاربر از برنامه داخلی (به عنوان مثال ، در یک مرورگر وب) بازدید کند ، وقتی برنامه بیرونی قبلاً در دستگاه کاربر نصب شده است ، مرورگر بنرهای تبلیغاتی نصب را نشان نمی دهد ، و رویداد قبل از نصب پیش بینی نمی شود. دلیل این امر این است که مرورگر بررسی می کند و می بیند که آیا صفحه فعلی متعلق به برنامه ای است که از قبل نصب شده است ، و نتیجه می گیرد که این است. راه حل برای این کار نصب برنامه داخلی به صورت دستی (از طریق گزینه منوی "ایجاد میانبر") یا نصب برنامه داخلی ابتدا ، قبل از برنامه بیرونی است.
• اعلان و API نشان : اگر برنامه بیرونی نصب شود اما برنامه داخلی نیست ، اعلان ها و نشان های حاصل از برنامه داخلی به اشتباه به برنامه بیرونی (که نزدیکترین دامنه محصور یک برنامه نصب شده است) نسبت داده می شود. این ویژگی در مواردی که هر دو برنامه بر روی دستگاه کاربر نصب شده اند به درستی کار می کند.
• ضبط پیوند : برنامه بیرونی ممکن است URL هایی را که متعلق به برنامه داخلی است ، ضبط کند. این امر به ویژه در صورت نصب برنامه بیرونی اما برنامه داخلی وجود ندارد. به طور مشابه ، پیوندهایی در برنامه بیرونی که به برنامه داخلی پیوند می خورند ، ضبط را به برنامه داخلی پیوند نمی دهند ، زیرا در محدوده برنامه بیرونی در نظر گرفته می شوند. علاوه بر این ، در Chromeos و Android ، اگر این برنامه ها به فروشگاه Play (به عنوان فعالیت های معتبر وب ) اضافه شوند ، برنامه بیرونی تمام پیوندها را ضبط می کند. حتی اگر برنامه داخلی نصب شود ، سیستم عامل باز هم انتخابی را برای باز کردن آنها در برنامه بیرونی به کاربر ارائه می دهد.

نتیجه گیری

در این مقاله به روشهای مختلفی پرداختیم که توسعه دهندگان می توانند چندین برنامه وب مترقی مرتبط با یکدیگر را در همان دامنه بسازند.

به طور خلاصه ، ما اکیداً توصیه می کنیم از منشأ دیگری (به عنوان مثال با استفاده از زیر دامنه) برای میزبانی PWA های مستقل استفاده کنید. میزبانی آنها در همان منشأ چالش های بسیاری را نشان می دهد ، به این دلیل که مرورگر این برنامه ها را کاملاً برنامه های متمایز نمی داند.

• منشاء جداگانه: توصیه می شود
• همان منشاء ، مسیرهای غیر همپوشانی: توصیه نمی شود
• همان منشأ ، مسیرهای همپوشانی/تو در تو: به شدت توصیه نمی شود

اگر استفاده از منشاء مختلف ، با استفاده از مسیرهای غیر همپوشانی امکان پذیر نباشد (به عنوان مثال https://example.com/app1/ و https://example.com/app2/ آن را به شدت با استفاده از مسیرهای همپوشانی یا تو در تو ، مانند https://example.com/ (برای APP بیرونی) و https://example.com/app/ app/ استفاده می کنید.

منابع اضافی

• برنامه های وب پیشرو در سایت های چند منشور

با تشکر فراوان از بررسی ها و پیشنهادات فنی آنها: جو مدلی ، دومینیک NG ، آلن کاتتر ، دانیل مورفی ، پنی مک لاچلان ، توماس اشتاینر و داروین هوانگ

عکس توسط تیم موشولدر در Unsplash