پایداری صفحه‌بندی آرشیو

مسئله تجاری

یک آرشیو می‌تواند سریع به‌نظر برسد و باز هم سر مرز صفحه‌ها خراب شود: محصول تکراری، لودری که تمام نمی‌شود، درخواست‌های صفحه‌بندی‌ای که ۴۰۴ می‌گیرند، یا اسکریپت درون‌خطی سنگین. نتیجه هم تجربه‌ی مرور بد است، هم فشار بی‌دلیل روی سرور.

آنچه تحویل دادم

• انتقال runtime سنگین اسکرول بی‌نهایت از خروجی درون‌خطی فوتر به یک اسِت MU قابل کش.
• رفتار پایان قطعی: آرشیو وقتی به آخرین صفحه‌ی واقعی رسید، تمیز می‌ایستد.
• ترتیب قطعی آرشیو به‌عنوان آخرین معیار تساوی‌شکن، تا سر مرز صفحه‌ها محصول تکراری نیفتد.

رویکرد فنی

• تکرار مرزی تقریباً همیشه مسئله‌ی ترتیب است، نه مسئله‌ی کوئری. وقتی دو محصول امتیاز مرتب‌سازی یکسان دارند، ترتیبشان بین دو درخواست جابه‌جا می‌شود و یکی در هر دو صفحه می‌آید.
• یک تساوی‌شکن قطعی همین را از ریشه حل می‌کند، به‌جای حذف تکراری‌ها در سمت کلاینت.
• بیرون بردن runtime از فوتر درون‌خطی یعنی مرورگر می‌تواند کشش کند؛ روی کاتالوگی که مرور طولانی دارد، بیشترین اثر را همین می‌گذارد.

نتیجه و شواهد

نتیجه، مرور آرشیوی است که می‌شود به آن اتکا کرد؛ در عین حال سلکتورهای پروداکشن، قواعد URL صفحه‌بندی، جزئیات کاتالوگ و سورس پیاده‌سازی خصوصی می‌مانند.

اهمیت برای کارفرما

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

یادداشت‌های تحویل

نقش من این بود که مسیر پرترافیک کاتالوگ را با تغییرهای کوچک و برگشت‌پذیر محافظت کنم؛ تغییرهایی که رفتار فرانت‌اند و ترتیب دیتابیس را بهتر کنند بدون دست‌زدن به طراحی سایت.

• رابط کاربری آرشیو دست‌نخورده ماند.
• پایداری عملیاتی روی مرزهای صفحه‌بندی بهتر شد.
• شواهد عمومی پاک‌سازی‌شده و قابل بازبینی ماند.