Performance با Caching — Part 2

Load Strategy، Expiration و تصمیم‌هایی که دیر گرفته می‌شن

در Part 1 درباره‌ی خودِ caching حرف زدیم و دیدیم ابزارهایی مثل TanStack Query چطور runtime caching رو برای ما هندل می‌کنن.
اما تو پروژه‌های واقعی، مشکل معمولاً این نیست که cache نداریم؛
مشکل اینه که نمی‌دونیم چی رو، کی و تا چه زمانی cache کنیم.

اینجاست که load strategy و expiration وارد بازی می‌شن.

Performance فقط «چقدر سریع» نیست، «کی چی لود می‌شه» است

یکی از اشتباه‌های رایج اینه که همه‌چیز رو با هم لود می‌کنیم،
بعد سعی می‌کنیم با cache یا memoization اوضاع رو بهتر کنیم.

در حالی که ترتیب درست معمولاً اینه:

1. اول تصمیم بگیریم چی واقعاً بحرانیه

2. بعد مشخص کنیم چی می‌تونه دیرتر بیاد

3. و در نهایت، برای هرکدوم استراتژی cache تعریف کنیم

Lazy-loading: وقتی واقعاً لازم نیست الان بیاد

Lazy-loading یعنی:

چیزی رو لود نکن، مگر اینکه کاربر واقعاً بهش نیاز داشته باشه.

مثلاً:

• یک tab ثانویه

• یک modal سنگین

• یک صفحه‌ی تنظیمات که شاید ۱۰٪ کاربران ببینن

در SPAها، lazy-loading اگر با cache ترکیب نشه، تبدیل می‌شه به:

«هر بار دیر لود می‌شه»

اما وقتی درست استفاده بشه:

• بار اول lazy-load

• دفعات بعد از cache

و این دقیقاً جاییه که ابزارهایی مثل TanStack Query به ما کمک مکنه.

Preload: وقتی می‌دونی قراره لازم بشه

Preload یعنی:

«می‌دونم کاربر به‌زودی اینو می‌خواد، بذار زودتر بیارمش»

مثال‌های رایج:

• دیتای صفحه‌ی بعد از کلیک

• اطلاعاتی که بعد از login بلافاصله استفاده می‌شن

• routeهایی که احتمال ورود بهشون بالاست

در این حالت:

• preload بدون cache = مصرف بی‌دلیل شبکه

• preload + cache = تجربه‌ی خیلی نرم

Cache Expiration: مهم‌ترین بخشی که معمولاً نادیده گرفته می‌شه

یکی از خطرناک‌ترین حالت‌ها:

cache درست کار می‌کنه، ولی داده‌ها قدیمی‌ان

اینجاست که مفهوم stale مهم می‌شه.

در TanStack Query:

• داده می‌تونه cache باشه

• ولی stale باشه

• و در background آپدیت بشه

مثال ساده:

useQuery(['products'], fetchProducts, {
  staleTime: 5 * 60 * 1000
})

یعنی:

• تا ۵ دقیقه داده «قابل اعتماد» حساب می‌شه

• بعد از اون:

  • داده سریع از cache نمایش داده می‌شه

  • ولی fetch جدید در پس‌زمینه انجام می‌شه

این یعنی:

• UX سریع

• بدون نمایش دیتای خیلی قدیمی

• بدون blocking UI

Invalidation: وقتی تغییر اتفاق می‌افته

بعضی داده‌ها رو نمی‌شه فقط با زمان کنترل کرد.
مثلاً:

• بعد از submit فرم

• بعد از update پروفایل

• بعد از تغییر وضعیت یک entity

اینجا cache باید آگاهانه invalidate بشه

queryClient.invalidateQueries(['user'])

این یعنی:

«می‌دونم چیزی تغییر کرده، برو دوباره fetch کن»

و این تفاوت بزرگیه بین:

• cache تصادفی

• cache معماری‌شده

جمع‌بندی Part 2

• Performance فقط به cache داشتن نیست

• Load strategy (lazy vs preload) به اندازه‌ی cache مهمه

• Cache بدون expiration = بدهی فنی

• ابزارها مشکل رو حل نمی‌کنن، تصمیم‌های درست حل می‌کنن

اگر از اول بدونی چی قراره کی استفاده بشه،
caching خودش تبدیل می‌شه به یک مزیت معماری، نه یک patch.

.