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

چالش‌ها و راه‌حل‌های ایجاد برنامه‌های وب پیشرفته در سایت‌های چند منبع.

Demián Renzulli

زمینه

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

استفاده های خوب و بد با منشأ چندگانه

چند دلیل قانونی وجود دارد که سایت‌ها از معماری چند منبعی استفاده می‌کنند، که بیشتر مربوط به ارائه مجموعه‌ای مستقل از برنامه‌های کاربردی وب یا ایجاد تجربیاتی است که کاملاً از یکدیگر جدا هستند. استفاده هایی نیز وجود دارد که باید از آنها اجتناب کرد.

خوب

بیایید ابتدا دلایل مفید را بررسی کنیم:

• محلی‌سازی / زبان: استفاده از دامنه سطح بالای کد کشور ، برای جدا کردن سایت‌هایی که در کشورهای مختلف ارائه می‌شوند (به عنوان مثال 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 اسکریپت service worker باید با مبدا صفحه فراخوانی register() یکسان باشد. این به این معنی است که، برای مثال، صفحه‌ای در https://www.example.com نمی‌تواند register() با یک نشانی اینترنتی service worker در 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 منتقل نخواهد شد.

از آنجایی که هیچ راهی برای به اشتراک گذاشتن مجوزها در بین مبداها وجود ندارد، تنها راه حل در اینجا این است که برای هر یک از زیر دامنه ها که در آن ویژگی خاصی مورد نیاز است (مثلاً مکان) مجوز درخواست کنید. برای مواردی مانند فشار وب، می‌توانید یک کوکی برای ردیابی اینکه آیا مجوز توسط کاربر در زیر دامنه دیگری پذیرفته شده است، نگهداری کنید تا از درخواست مجدد آن اجتناب کنید.

نصب و راه اندازی

برای نصب یک PWA، هر مبدأ باید مانیفست خاص خود را با یک start_url که مربوط به خودش است داشته باشد. این بدان معناست که کاربری که درخواست نصب را در یک مبدأ مشخص دریافت می‌کند (یعنی: https://section.example.com ) نمی‌تواند PWA را با یک start_url در یک منبع دیگر (یعنی: https://www.example.com نصب کند. https://www.example.com ). به عبارت دیگر، کاربرانی که درخواست نصب را در یک زیر دامنه دریافت می‌کنند، فقط می‌توانند PWA را برای صفحات فرعی نصب کنند، نه برای URL اصلی برنامه.

همچنین این مشکل وجود دارد که یک کاربر می‌تواند هنگام پیمایش در سایت چندین درخواست نصب دریافت کند، در صورتی که هر زیر دامنه معیارهای نصب را داشته باشد و از کاربر بخواهد PWA را نصب کند.

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

1. به رویداد beforeinstallprompt گوش دهید .
2. جلوگیری از ظاهر شدن فرمان ، فراخوانی event.preventDefault() .

به این ترتیب، مطمئن می‌شوید که درخواست در قسمت‌های ناخواسته سایت نشان داده نمی‌شود، در حالی که می‌توانید به نمایش آن، به عنوان مثال، در مبدا اصلی (مثلاً صفحه اصلی) ادامه دهید.

حالت مستقل

هنگام حرکت در یک پنجره مستقل، وقتی کاربر خارج از محدوده تعیین شده توسط مانیفست PWA حرکت می کند، مرورگر رفتار متفاوتی خواهد داشت. این رفتار به هر نسخه مرورگر و فروشنده بستگی دارد. برای مثال، آخرین نسخه‌های Chrome، زمانی که کاربر در حالت مستقل از محدوده خارج می‌شود، یک برگه سفارشی Chrome را باز می‌کند.

در بیشتر موارد، هیچ راه حلی برای این وجود ندارد، اما می‌توان راه‌حلی برای بخش‌های کوچک تجربه که در زیر دامنه‌ها میزبانی می‌شوند، اعمال کرد (به عنوان مثال: گردش‌های کاری ورود به سیستم):

1. URL جدید، https://login.example.com ، می تواند در داخل یک iframe تمام صفحه باز شود.
2. هنگامی که کار در iframe کامل شد (به عنوان مثال، فرآیند ورود به سیستم)، می توان از postMessage() برای ارسال هرگونه اطلاعات حاصل از iframe به صفحه اصلی استفاده کرد.
3. به عنوان آخرین مرحله، هنگامی که پیام توسط صفحه اصلی دریافت شد، شنوندگان را می توان از ثبت نام خارج کرد و در نهایت iframe را از DOM حذف کرد.

نتیجه

سیاست همان مبدأ محدودیت‌های زیادی را برای سایت‌هایی که بر پایه چندین منبع ساخته شده‌اند و می‌خواهند به یک تجربه PWA منسجم دست یابند، اعمال می‌کند. به همین دلیل، برای ارائه بهترین تجربه به کاربران، ما قویاً توصیه می کنیم که سایت ها را به مبداهای مختلف تقسیم نکنید.

برای سایت‌های موجود که قبلاً به این روش ساخته شده‌اند، کارکرد صحیح PWA‌های چند منبعی می‌تواند چالش برانگیز باشد، اما ما برخی از راه‌حل‌های بالقوه را بررسی کرده‌ایم. هر کدام می تواند با معاوضه هایی همراه باشد، بنابراین هنگام تصمیم گیری در مورد رویکردی که در وب سایت خود دارید، از قضاوت خود استفاده کنید.

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

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