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

چگونه می توان چندین 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