چالش‌ها و راه‌حل‌ها برای ساخت برنامه‌های وب پیش‌رونده در سایت‌های چند مبدأیی.
منتشر شده: ۱۹ آگوست ۲۰۱۹
در گذشته، استفاده از معماری‌های چند مبدأیی مزایایی داشت. برای برنامه‌های وب پیش‌رونده، این رویکرد چالش‌های زیادی را ایجاد می‌کند. به طور خاص، سیاست مبدأ یکسان ، محدودیت‌هایی را برای اشتراک‌گذاری مواردی مانند سرویس ورکرها و حافظه‌های پنهان، مجوزها و دستیابی به یک تجربه مستقل در چندین مبدأ اعمال می‌کند.
کاربردهای خوب و بد چندین مبدأ را کشف کنید و چالش‌ها و راه‌حل‌های ساخت برنامه‌های وب پیش‌رونده در سایت‌های چند مبدأ را توضیح دهید.
کاربردهای خوب و بد از ریشه‌های چندگانه
چند دلیل موجه برای استفاده سایت‌ها از معماری چند مبدأ وجود دارد که عمدتاً مربوط به ارائه مجموعه‌ای مستقل از برنامه‌های وب یا ایجاد تجربیاتی است که کاملاً از یکدیگر جدا هستند. همچنین کاربردهایی وجود دارد که باید از آنها اجتناب شود.
خوبی‌ها
ابتدا به دلایل مفید نگاهی بیندازید:
محلی‌سازی / زبان: استفاده از یک دامنه سطح بالای کشوری ، برای جدا کردن سایت‌هایی که قرار است در کشورهای مختلف ارائه شوند (مثلاً
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 نمی‌تواند register() با آدرس سرویس ورکر در https://section.example.com فراخوانی کند.
نکته‌ی دیگر این است که یک سرویس ورکر فقط می‌تواند صفحاتی را که تحت مبدا و مسیری که به آن تعلق دارد میزبانی می‌شوند، کنترل کند. این بدان معناست که اگر سرویس ورکر در https://www.example.com میزبانی شود، فقط می‌تواند URLها را از آن مبدا (طبق مسیر تعریف شده در پارامتر scope ) کنترل کند، اما هیچ صفحه‌ای را در زیردامنه‌های دیگر مانند، مثلاً صفحات موجود در https://section.example.com کنترل نخواهد کرد.
در این حالت، تنها راه حل، استفاده از چندین سرویس ورکر (یکی برای هر مبدا) است.
ذخیره سازی
شیء Cache، indexedDB و localStorage نیز به یک منبع واحد محدود شده‌اند. این بدان معناست که دسترسی به حافظه‌های نهان متعلق به https://www.example.com ، مثلاً از طریق https://www.section.example.com ، امکان‌پذیر نیست.
در اینجا چند کاری که می‌توانید برای مدیریت صحیح حافظه‌های پنهان در سناریوهایی مانند این انجام دهید، آورده شده است:
استفاده از حافظه پنهان مرورگر: استفاده از بهترین شیوه‌های سنتی حافظه پنهان مرورگر همیشه توصیه می‌شود. این تکنیک مزیت اضافه استفاده مجدد از منابع ذخیره شده در سراسر مبدا را فراهم می‌کند، که نمی‌توان آن را با حافظه پنهان سرویس‌دهنده انجام داد. برای بهترین شیوه‌ها در مورد نحوه استفاده از حافظه پنهان HTTP با سرویس‌دهنده‌ها، می‌توانید به این پست نگاهی بیندازید.
نصب سرویس ورکرها را سبک نگه دارید: اگر چندین سرویس ورک دارید، از اینکه کاربران هر بار که به یک منبع جدید می‌روند، هزینه نصب زیادی بپردازند، خودداری کنید. به عبارت دیگر: فقط منابعی را که کاملاً ضروری هستند، از قبل کش کنید.
مجوزها
مجوزها همچنین به مبدأها محدود می‌شوند. این بدان معناست که اگر کاربری مجوزی را به مبدأ https://section.example.com اعطا کند، آن مجوز به مبدأهای دیگر، مانند https://www.example.com ، منتقل نمی‌شود.
از آنجایی که هیچ راهی برای اشتراک‌گذاری مجوزها بین مبداها وجود ندارد، تنها راه حل در اینجا درخواست مجوز برای هر یک از زیردامنه‌هایی است که در آنها به یک ویژگی خاص نیاز است (مثلاً موقعیت مکانی). برای مواردی مانند web push، می‌توانید یک کوکی را برای ردیابی اینکه آیا مجوز توسط کاربر در زیردامنه دیگری پذیرفته شده است یا خیر، نگهداری کنید تا از درخواست مجدد آن جلوگیری شود.
نصب
برای نصب یک PWA، هر مبدأ باید مانیفست مخصوص به خود را با یک start_url مرتبط با خودش داشته باشد. این بدان معناست که کاربری که اعلان نصب را در یک مبدأ مشخص (مثلاً: https://section.example.com ) دریافت می‌کند، نمی‌تواند PWA را با start_url در مبدأ دیگری (مثلاً: https://www.example.com ) نصب کند. به عبارت دیگر، کاربرانی که اعلان نصب را در یک زیردامنه دریافت می‌کنند، فقط می‌توانند PWAها را برای زیرصفحات نصب کنند، نه برای URL اصلی برنامه.
همچنین این مشکل وجود دارد که اگر هر زیردامنه معیارهای نصب را داشته باشد، یک کاربر می‌تواند هنگام پیمایش سایت چندین پیام نصب دریافت کند و از کاربر بخواهد PWA را نصب کند.
برای کاهش این مشکل، می‌توانید مطمئن شوید که اعلان فقط در مبدا اصلی نمایش داده می‌شود. وقتی کاربری از زیردامنه ای بازدید می‌کند که معیارهای نصب را دارد:
- به رویداد
beforeinstallpromptگوش دهید . - با فراخوانی
event.preventDefault()از نمایش اعلان جلوگیری کنید .
به این ترتیب، مطمئن می‌شوید که اعلان در قسمت‌های ناخواسته سایت نمایش داده نمی‌شود، در حالی که می‌توانید به نمایش آن ادامه دهید، برای مثال، در صفحه اصلی (مثلاً صفحه اصلی).
حالت مستقل
هنگام پیمایش در یک پنجره مستقل، مرورگر وقتی کاربر از محدوده تعیین‌شده توسط مانیفست PWA خارج می‌شود، رفتار متفاوتی خواهد داشت. این رفتار به نسخه و فروشنده هر مرورگر بستگی دارد. به عنوان مثال، آخرین نسخه‌های کروم وقتی کاربر در حالت مستقل از محدوده خارج می‌شود، یک تب سفارشی کروم باز می‌کنند.
در بیشتر موارد، هیچ راه حلی برای این مشکل وجود ندارد، اما می‌توان برای بخش‌های کوچکی از تجربه کاربری که در زیردامنه‌ها میزبانی می‌شوند (مثلاً: گردش‌های کاری ورود به سیستم) یک راه حل موقت اعمال کرد:
- آدرس اینترنتی جدید،
https://login.example.com، می‌تواند درون یک iframe تمام صفحه باز شود. - پس از اتمام کار درون iframe (برای مثال، فرآیند ورود به سیستم)، می‌توان از postMessage() برای ارسال هرگونه اطلاعات حاصل از iframe به صفحه والد استفاده کرد.
- به عنوان آخرین مرحله، به محض دریافت پیام توسط صفحه اصلی، می‌توان شنونده‌ها را از حالت ثبت خارج کرد و در نهایت iframe از DOM حذف می‌شود.
نتیجه‌گیری
سیاست Same-origin محدودیت‌های زیادی را برای سایت‌هایی که بر روی چندین Origin ساخته شده‌اند و می‌خواهند به یک تجربه PWA منسجم دست یابند، اعمال می‌کند. به همین دلیل، برای ارائه بهترین تجربه به کاربران، اکیداً توصیه می‌کنیم که سایت‌ها را به Originهای مختلف تقسیم نکنید.
برای سایت‌های موجودی که از قبل به این روش ساخته شده‌اند، درست کار کردن PWA های چندمنبعی می‌تواند چالش برانگیز باشد، اما ما برخی از راه‌حل‌های بالقوه را بررسی کرده‌ایم. هر کدام می‌توانند با معایبی همراه باشند، بنابراین هنگام تصمیم‌گیری در مورد اینکه کدام رویکرد را برای وب‌سایت خود انتخاب کنید، از قضاوت خود استفاده کنید.
هنگام ارزیابی یک استراتژی بلندمدت یا طراحی مجدد سایت، مهاجرت به یک منبع واحد را در نظر بگیرید، مگر اینکه دلیل مهمی برای حفظ معماری چند منبعی وجود داشته باشد.
با تشکر فراوان از بررسی‌ها و پیشنهادات فنی‌شان: پنی مک‌لاکلن، پاول کاول، دومینیک نگ، آلبرتو مدینا، پیت لوپاژ، جو مدلی، چنی تسای، مارتین شیرل و آندره باندارا.