برنامه‌های وبی پیشرو – پوسته‌ی برنامه (App shell)

رایج‌ترین معماری برای بارگذاری سریع PWA و قابل اتّکا بودن آن معماری پوسته‌ی برنامه (یا app shell) است.

پوسته‌ی برنامه شامل حدّاقل کد HTML، CSS و JavaScript لازم برای رابط کاربری برنامه است. اگر پوسته‌ی برنامه، یعنی همین فایل‌های html و css و js و تصاویر، در حافظه Cache ذخیره شود و در حالت ‌Offline مورد استفاده قرار بگیرد برنامه خیلی سریع و با کارایی خوب اجرا خواهد شد. این به آن معناست که پس از اوّلین باری که کاربر برنامه را باز کند از دفعات بعدی هیچ درخواستی به سرور برای بارگذاری پوسته‌ی برنامه ارسال نمی‌شود و تنها برای محتوایی که بروز بودنش در لحظه مهم است به سرور درخواست ارسال می‌کنیم.

پوسته‌ی برنامه درمقابل محتوای برنامه
پوسته‌ی Cacheشده در دفعات بعدی بسیار سریع بالا می‌آید.

الگوی پوسته‌ی برنامه در اپلیکیشن‌های غیر وبی فراوان استفاده می‌شود! در اصل وقتی شما فایل نصبی یک اپلیکیشن را از مارکت‌های نرم‌افزاری دانلود می‌کنید، پوسته‌ی آن برنامه را دانلود کرده اید!

پوسته‌ی برنامه اسکلت اصلی رابط کاربری و مؤلفه‌های لازم برای اجرای برنامه را در خود دارد، ولی محتوا را نه.

مزایای معماری پوسته‌ی برنامه

  • عملکرد مطمئن و سرعت بالای همیشگی. در این روش پس از اوّلین بارگذاری تمام محتوای استاتیک برنامه‌ی وبی Cache می‌شود، که شامل فایل‌های HTML، CSS، JavaScript و تصاویر می‌شود. حالا از این پس برنامه در دفعات بعدی بسیار سریع بالا خواهد آمد.
  • شبیه شدن به برنامه‌های غیر وبی: با استفاده از این الگو می‌توان همانند برنامه‌های غیر وبی تجربه‌ی کاربری نرم و روانی ایجاد کرد. در این روش، جابجایی بین صفحات و تعاملات شبیه برنامه‌های غیر وبی می‌شود، آن هم با پشتیبانی کامل از حالت Offline.
  • صرفه‌جویی در حجم اینترنت مصرفی: در این معماری قسمت‌هایی از برنامه که تغییر نمی‌کند در همان بار اوّل در حافظه‌ی Cache ذخیره می‌شود و در دفعات بعدی چیز تکراری دانلود نمی‌شود، به همین دلیل مصرف اینترنت کاهش پیدا کند.

پیاده‌سازی معماری App shell

اگر برنامه‌ی تحت وب به صورت تک‌صفحه‌ای (SPA) نوشته شود استفاده از این الگو بسیار آسان می‌شود (مثلاً اگر با فریم‌ورک‌هایی مثل React، Vue، Svelte یا Solid ساخته شود). برای پیاده‌سازی این معماری کافیست در این گونه برنامه‌ها یک Service Worker ثبت کنیم که در هنگام نصب، تمام فایل‌های ایستا را Cache کند و در دفعات بعدی از Cache بخواند.

امّا مشکل اینجاست که با اضافه و حذف کردن هر فایل مجبوریم کد Service Worker را هم اصلاح کنیم. این کار برای بروزرسانی برنامه هم می‌تواند مشکل ایجاد کند و باعث می‌شود کاربر همچنان نسخه‌ی قدیمی برنامه را ببیند، از این رو Google ابزار و کتابخانه‌ای را تحت عنوان WorkBox به وجود آورده است تا این فرآیند را آسان کند.

WorkBox دارای ابزاری تحت خط فرمان است که با دریافت تنظیمات، به صورت خودکار لیست تمام فایل‌های استاتیک برنامه را استخراج می‌کند و لیست آن فایل‌ها را به همراه hash محتوایشان به Service Worker تزریق می‌کند.

WorkBox علاوه بر ابزار تحت خط فرمان، پلاگین‌هایی هم برای ابزارهای بیلد مختلف از جمله Webpack و Create React App و Vue CLI دارد تا اگر از اینگونه ابزارها در تولید پروژه‌ی خود استفاده می‌کنید یکپارچه‌تر کار کنید.

سپس Workbox در زمان نصب سرویس‌ورکر تمام فایل‌های استاتیک را Cache می‌کند، و در نتیجه پوسته‌ی برنامه کاملاً Cache خواهد شد.

فرآیند بروزرسانی پوسته‌ی برنامه

WorkBox در صورت تغییر در فایل‌های برنامه لیست جدیدی تولید می‌کند که در اصل همان لیست قبلی است که به آن مواردی اضافه یا حذف شده است یا hash برخی فایل‌ها تغییر پیدا کرده است. در این صورت برای بروزرسانی برنامه تنها فایل‌های جدید و تغییریافته بارگیری می‌شود، و پس از آن برنامه بروز خواهد بود.

این روش برای بروزرسانی خیلی بهتر از روش بروزرسانی اپلیکیشن‌های غیر وبی است؛ اگر در اپلیکیشن غیر وبی قرار باشد فقط یکی از عکس‌های به‌کار رفته در اپلیکیشن عوض شود و نسخه‌ی جدیدی منتشر شود، کاربر مجبور است کلّ آن اپلیکیشن را دوباره دانلود کند، ولی در PWAهایی که از روش فوق استفاده می‌کنند فقط همان عکسی که عوض شده است دانلود و Cache می‌شود و پس از آن برنامه بروز شده است 😎

این کار حجم مصرفی اینترنت برای بروزرسانی را کاهش می‌دهد و سرعت بروزرسانی را زیاد می‌کند.

البته در این نوع برنامه‌ها بروزرسانی کاملاً بدون چالش هم نیست! پس از انتشار نسخه‌ی جدید اگر کاربری برنامه را باز کند پوسته‌ی برنامه از Cache خوانده می‌شود و در نتیجه پوسته‌ی قدیمی برنامه را می‌بیند، البته به صورت همزمان مرورگر Service Worker را بروز می‌کند، تغییرات را متوجّه می‌شود و در پس‌زمینه Cache را بروز می‌کند، امّا به هر حال کاربر همچنان در حال مشاهده‌ی نسخه‌ی قدیمی برنامه است، مگر اینکه یک بار دیگر برنامه‌ی وبی را به صورت کامل ببندد و دوباره باز کند تا Service Worker جدید هم از وضعیّت «انتظار» بیرون بیاید و «فعال» شود.

یکی از الگوهای رایج در چنین مواقعی این است که پس از بروز کردن Cache در پس‌زمینه برای نسخه‌ی جدید، در رابط کاربری به نحوی به کاربر می‌فهمانند نسخه‌ی جدیدی از این برنامه منتشر شده است و او در حال مشاهده‌ی نسخه‌ی قدیمی آن است و اگر می‌خواهد به نسخه‌ی جدید برود روی دکمه‌ای کلیک کند، سپس با کلیک روی آن دکمه Service Worker جدید را از حالت انتظار بیرون می‌آورند و فعّال می‌کنند و پس از آن صفحه را بازنشانی می‌کنند تا پوسته‌ی جدید با Service Worker جدید از Cache خوانده شود.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *