شاید اصلاً به سرویسورکر نیاز نداری
فرانتاند
جاوااسکریپتخلاصهٔ کاملتر
نویسنده میگه خودش از اولین کاربرهای سرویسورکر بوده و دقیقاً همون بلایی سرش اومده که خیلیها تعریف میکنن: یه سرویسورکر با استراتژی کش بد، نسخهٔ قدیمی اپ رو به کاربرها سرو میکنه و برای درستش کردن باید یه worker جدید بفرستی و روزها صبر کنی تا کلاینتها برش دارن، چون خود worker خراب تصمیم میگیره کِی آپدیت چک شه.
اولین نمونهای که بررسی میکنه بوت آنی اسلکه: کش کردن کل مجموعهٔ assetها و بازسازی state ردکس تا UI قبل از هر درخواست شبکه رندر شه. به گفتهٔ نویسنده بخش asset این ماجرا کمی بزرگنمایی شده؛ اگه فایلها هش محتوایی داشته باشن و با Cache-Control: public, max-age=31536000, immutable سرو شن، کش HTTP همون کار رو خیلی سادهتر انجام میده. چیزی که کش HTTP بهت نمیده بوتِ بدون شبکهست، ولی سؤال واقعی اینه که اصلاً به پشتیبانی آفلاین نیاز داری یا نه.
مورد دوم جالبتره: بعد از هر دیپلوی، باندل قدیمی روی کلاینت به چانکی اشاره میکنه که دیگه وجود نداره و ۴۰۴ میگیره. هر چی بیشتر دیپلوی کنی این بیشتر آزارت میده. راهحل پیشنهادی مقالهٔ اصلی، کش کردن کل اپ با سرویسورکر بود؛ نویسنده میگه این عملاً فلسفهٔ code splitting رو نابود میکنه، چون با هر بیاعتبار شدن کش باید کل اپ دوباره دانلود شه.
جایگزین سادهترش اینه که فایلهای استاتیک قدیمی رو بهجای حذف، یه مدت تو باکت نگه داری. با اسمگذاری هشدار، هیچ دیپلوی چیزی رو بازنویسی نمیکنه و نسخههای قدیم و جدید کنار هم زندگی میکنن. ضمناً چون سرویسورکر همیشه تو پسزمینه زنده نیست، منطق چک کردن نسخه هرحال باید تو خود صفحه باشه — پس اینجا هم سرویسورکر لازم نیست.
دربارهٔ بازنویسی مانیفست ویدیو تو Mux، نویسنده میگه این منطق اصلاً جاش سمت کلاینت نیست؛ باگی که تو مقاله ذکر شده (پلیر قبل از اینکه worker کنترل رو بگیره شروع به fetch میکنه) خودش علامت همینه. فقط یه فایل متنی مانیفست باید بازنویسی شه، پس بردنش سمت سرور هم مقاومتره هم تستش راحتتره.
دربارهٔ Partytown هم یادآوری میکنه که نسخهٔ سرویسورکری در واقع فالبکه؛ کتابخونه اگه Atomics و SharedArrayBuffer در دسترس باشن سراغ اونها میره. البته SharedArrayBuffer فقط زیر cross-origin isolation کار میکنه و هدرهاش معمولاً embedهای شخص ثالث رو میشکنن، برای همین در عمل فالبک بیشتر از چیزی که فکر میکنی استفاده میشه.
جمعبندی نویسنده: کارهای باحال زیادی با سرویسورکر میشه کرد، ولی فقط سه چیز واقعاً جایگزین ندارن — پشتیبانی آفلاین، نوتیفیکیشن پوش و background sync. بیرون از اینها، هنوز به مسئلهای برنخورده که سرویسورکر بهترین جواب براش باشه.
نکات کلیدی:
- بیشتر کاربردهای رایج سرویسورکر با کش HTTP و فایلهای هشدار هم حل میشن
- کش کردن کل اپ با سرویسورکر، مزیت code splitting رو از بین میبره
- برای چانکهای ۴۰۴ شده، نگه داشتن فایلهای قدیمی تو باکت کافیه
- منطق بازنویسی مانیفست بهتره سمت سرور یا لبه اجرا شه
- فقط آفلاین، پوش نوتیفیکیشن و background sync جایگزین واقعی ندارن
