چالش‌ها و راه‌حل‌های ساختن «برنامه‌های وب پیشرو» در سایت‌های چندمبدأ.
تاریخ انتشار: ۱۹ اوت ۲۰۱۹
در گذشته، استفاده از معماری‌های چندمبدأ مزایایی داشت. برای «برنامه‌های وب پیشرو»، این رویکرد چالش‌های زیادی را به‌همراه دارد. به‌ویژه، خط‌مشی same-origin، محدودیت‌هایی را برای هم‌رسانی مواردی مانند سرویس‌کارها و حافظه‌های پنهان، اجازه‌ها، و برای دستیابی به تجربه مستقل در چندین مبدأ اعمال می‌کند.
با کاربردهای خوب و بد چند مبدأ آشنا شوید و چالش‌ها و راه‌حل‌های ساختن «برنامه‌های وب پیشرو» در سایت‌های چندمبدأ را توضیح دهید.
استفاده‌های خوب و بد از چند مبدأ
چند دلیل قانونی برای سایت‌ها وجود دارد که از معماری چندمبدأ استفاده کنند، که بیشتر مربوط به ارائه مجموعه‌ای مستقل از برنامه‌های وب یا ایجاد تجربه‌هایی است که کاملاً از یکدیگر جدا شده‌اند. همچنین مواردی وجود دارد که باید از آن‌ها اجتناب شود.
خوب
ابتدا به دلایل مفید نگاهی بیندازید:
بومی‌سازی / زبان: استفاده از دامنه سطح بالای کد کشور برای جدا کردن سایت‌هایی که در کشورهای مختلف ارائه می‌شوند (مثلاً
https://www.google.com.ar)، یا استفاده از زیردامنه‌ها برای تقسیم سایت‌هایی که مکان‌های مختلف را هدف قرار می‌دهند (مثلاً:https://newyork.craigslist.org) یا برای ارائه محتوا به زبانی خاص (مثلاًhttps://en.wikipedia.org).برنامه‌های وب مستقل: استفاده از زیردامنه‌های مختلف برای ارائه تجربه‌هایی که هدف آن‌ها تفاوت قابل‌توجهی با سایت در مبدأ اصلی دارد. برای مثال، در یک سایت خبری، برنامه وب جدول کلمات متقاطع می‌تواند به‌طور عمدی از
https://crosswords.example.comارائه شود و به‌عنوان یک برنامه وب پیشرو مستقل نصب و استفاده شود، بدون اینکه نیاز باشد منابع یا عملکردی را با وب‌سایت اصلی هم‌رسانی کند.
بد
اگر هیچ‌کدام از این کارها را انجام نمی‌دهید، احتمالاً استفاده از معماری چندمبدأیی هنگام ساختن «برنامه‌های وب پیش‌رونده» یک نقطه‌ضعف خواهد بود.
باوجوداین، بسیاری از سایت‌ها بدون دلیل خاصی یا به‌دلایل «قدیمی» همچنان به این شکل ساختاردهی می‌شوند. یک نمونه استفاده از زیردامنه‌ها برای جدا کردن بخش‌هایی از سایت است که باید بخشی از یک تجربه یکپارچه باشند.
برای مثال، الگوهای زیر به‌شدت منع می‌شوند:
بخش‌های سایت: جدا کردن بخش‌های مختلف سایت در زیردامنه‌ها. در سایت‌های خبری، دیدن صفحه اصلی در
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.
برای مواردی که انتقال به یک مبدأ واحد امکان‌پذیر نیست، در ادامه فهرستی از چالش‌ها و (درصورت امکان) راه‌حل‌های جایگزین ارائه شده است که می‌توان هنگام ساخت «برنامه‌های وب پیش‌رونده» درنظر گرفت.
چالش‌ها و راه‌حل‌های «برنامه‌های وب پیشرو» در مبدأهای مختلف
هنگام ساختن وب‌سایت در چند مبدأ، ارائه تجربه «برنامه وب پیشرو» یکپارچه چالش‌برانگیز است، عمدتاً به‌دلیل خط‌مشی همان مبدأ که محدودیت‌هایی را اعمال می‌کند. بیایید آن‌ها را یکی‌یکی بررسی کنیم.
عامل‌های خدماتی
مبدأ نشانی وب اسکریپت کارگر سرویس باید با مبدأ صفحه فراخواننده register() یکسان باشد. این یعنی، برای مثال، صفحه‌ای در https://www.example.com نمی‌تواند register() را با نشانی وب کارگر سرویس در https://section.example.com فراخوانی کند.
نکته دیگر این است که عامل خدماتی فقط می‌تواند صفحه‌هایی را کنترل کند که تحت مبدأ و مسیری که به آن تعلق دارد میزبانی می‌شوند. این یعنی اگر عامل خدماتی در https://www.example.com میزبانی شود، فقط می‌تواند نشانی‌های وب آن مبدأ را کنترل کند (طبق مسیر تعریف‌شده در پارامتر دامنه)، اما هیچ صفحه‌ای را در زیردامنه‌های دیگر، مثلاً زیردامنه‌های موجود در 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، منتقل نخواهد شد.
ازآنجایی‌که هیچ راهی برای هم‌رسانی اجازه‌ها در بین مبدأها وجود ندارد، تنها راه‌حل در اینجا درخواست اجازه در هر زیردامنه‌ای است که ویژگی خاصی (مثلاً مکان) در آن موردنیاز است. برای مواردی مانند ارسال وب، می‌توانید کوکی را حفظ کنید تا ردیابی کنید که آیا اجازه توسط کاربر در زیردامنه دیگری پذیرفته شده است یا نه، تا از درخواست مجدد آن جلوگیری شود.
نصب
برای نصب «برنامه وب پیش‌رونده»، هر مبدأ باید مانیفست خودش را با start_url داشته باشد که نسبت به خودش است. این یعنی کاربری که پیام‌واره نصب را در مبدأ مشخصی (مثلاً https://section.example.com) دریافت می‌کند نمی‌تواند «برنامه وب پیش‌رونده» را با start_url در مبدأ دیگری (مثلاً https://www.example.com) نصب کند.
به‌عبارت دیگر، کاربرانی که پیام‌واره نصب را در زیردامنه‌ای دریافت می‌کنند فقط می‌توانند «برنامه‌های وب پیش‌رونده» را برای زیرصفحه‌ها نصب کنند، نه برای نشانی وب اصلی برنامه.
همچنین این مشکل وجود دارد که اگر هر زیردامنه با معیارهای نصب مطابقت داشته باشد و از کاربر بخواهد PWA را نصب کند، ممکن است کاربر یکسان هنگام پیمایش در سایت چندین پیام‌واره نصب دریافت کند.
برای کاهش این مشکل، می‌توانید مطمئن شوید که پیام‌واره فقط در مبدأ اصلی نشان داده می‌شود. وقتی کاربری از زیردامنه‌ای بازدید می‌کند که معیارهای نصب را برآورده می‌کند:
- به رویداد
beforeinstallpromptگوش دهید. - جلوگیری از نمایش پیام‌واره، با فراخوانی
event.preventDefault().
به این ترتیب، مطمئن می‌شوید که پیام‌واره در بخش‌های ناخواسته سایت نشان داده نمی‌شود، درحالی‌که می‌توانید همچنان آن را مثلاً در مبدأ اصلی (مانند صفحه اصلی) نشان دهید.
حالت مستقل
هنگام پیمایش در پنجره مستقل، وقتی کاربر از محدوده تعیین‌شده توسط مانیفست برنامه وب پیش‌رونده خارج می‌شود، مرورگر رفتار متفاوتی خواهد داشت. این رفتار به نسخه و فروشنده هر مرورگر بستگی دارد. برای مثال، جدیدترین نسخه‌های Chrome وقتی کاربر در حالت مستقل از محدوده خارج می‌شود، برگه سفارشی Chrome را باز می‌کنند.
در اکثر موارد، راه‌حلی برای این مشکل وجود ندارد، اما می‌توان برای بخش‌های کوچکی از تجربه که در زیردامنه‌ها میزبانی می‌شوند (برای مثال: گردش‌های کاری ورود به سیستم) راه‌حل موقتی اعمال کرد:
- نشانی وب جدید،
https://login.example.com، می‌تواند در iframe تمام‌صفحه باز شود. - پس‌از تکمیل شدن تکلیف در iframe (برای مثال، فرایند ورود به سیستم)، می‌توان از postMessage() استفاده کرد تا هرگونه اطلاعات حاصل از iframe به صفحه اصلی برگردانده شود.
- به‌عنوان آخرین مرحله، وقتی پیام توسط صفحه اصلی دریافت شد، شنوندگان می‌توانند لغو ثبت‌نام شوند و درنهایت iframe از DOM برداشته شود.
نتیجه‌گیری
خط‌مشی هم‌مبدأ محدودیت‌های زیادی را برای سایت‌هایی که بر روی چندین مبدأ ساخته شده‌اند و می‌خواهند به تجربه منسجم «برنامه وب پیشرو» دست یابند اعمال می‌کند. به همین دلیل، برای ارائه بهترین تجربه به کاربران، اکیداً توصیه می‌کنیم سایت‌ها را به مبدأهای مختلف تقسیم نکنید.
برای سایت‌های موجود که قبلاً به این روش ساخته شده‌اند، ممکن است چالش‌برانگیز باشد که PWAهای چندمبدأ به‌درستی کار کنند، اما ما برخی راه‌حل‌های بالقوه را بررسی کرده‌ایم. هرکدام از این روش‌ها ممکن است معایبی داشته باشند، بنابراین هنگام تصمیم‌گیری درباره اینکه کدام رویکرد را در وب‌سایت خود اتخاذ کنید، از قضاوت خود استفاده کنید.
هنگام ارزیابی استراتژی بلندمدت یا طراحی مجدد سایت، انتقال به یک مبدأ واحد را درنظر بگیرید، مگراینکه دلیل مهمی برای حفظ معماری چندمبدأ وجود داشته باشد.
با تشکر فراوان از این افراد برای بررسی‌های فنی و پیشنهادهایشان: پنی مک‌لاکلان، پل کاول، دومینیک ان‌جی، آلبرتو مدینا، پیت لی‌پیج، جو مدلی، چنی تسای، مارتین شیرل، و آندره باندارا.