عندما تحدث طلبات بحث متطابقة عدة مرات في نفس الشاشة.

يتم استخدام ذاكرة التخزين المؤقت للمتصفح مع createCsrCache من Core، ويتم إضافة callApiSsrCache من /next فقط عند الحاجة إلى ذاكرة التخزين المؤقت لبيانات خادم Next.js.

تعد ذاكرة التخزين المؤقت أيضًا جزءًا من commonService.

كود callApiClientCache/callApiServerCache في هذه الصفحة يشرح فقط جزء ذاكرة التخزين المؤقت من محول HTTP المشترك للمشروع. يمكن تكوين الخدمة المولدة لاستيراد هذه الوظيفة، لذا فإن رؤية الهيكل الكامل لـ rxjsHttpService.ts/commonService.ts أولاً يجعل موقع ودور كل غلاف أكثر وضوحًا.

الكود الكامل لـ commonService/rxjsHttpService

تحقق من التكوين الكامل لملف واحد بدءًا من createHttpClient حتى session auth وCSR/SSR cache wrapper.

ذاكرة التخزين المؤقت CSR (ذاكرة التخزين المؤقت للعميل)

createCsrCache<CacheName>()يوفر callApiCsrCache(callApiFn, serviceArgs, cacheOptions) وremoveCsrCache(cacheName).

في بيئة الخادم، يتم استدعاء callApi الأصلي دون إنشاء خريطة ذاكرة التخزين المؤقت CSR. في المتصفح، يتم مشاركة نتائج Observable بنفس مفتاح الذاكرة المؤقتة باستخدام shareReplay.

محول Next.js: callApiSsrCache

مساعد SSR يستخدم next/cache (unstable_cache) في Next.js. إذا كان GET وcacheTime > 0، يتم استخدام force-cache + revalidate، بينما يتم تنفيذ الطلبات الأخرى باستخدام no-store.

يمكن حقن Cookie/Authorization لكل طلب باستخدام headersProvider.
إذا كان هناك onServer401 في 401، يتم تنفيذه.

لا تخزن البيانات حسب المستخدم في الذاكرة المؤقتة.

استجابة المصادقة

لا تضع الاستجابات التي تختلف حسب التفويض مثل الملف الشخصي، الأذونات، ومعلومات الدفع في الذاكرة المؤقتة المشتركة. هذه الطلبات هي عادية. callApiاستخدمcacheTime: 0أو من الأفضل معالجتها كـ no-store.

عند تجميع المتصفح/الخادم في غلاف مشروع واحد.

يمكن أيضًا تجميع الخدمة العامة بحيث يتفرع المتصفح إلى createCsrCache، والخادم إلى callApiSsrCache. هذه هي نمط تكوين المشروع وليست هيكلًا أساسيًا لـ Core.

commonService.ts

عند استخدام غلاف ذاكرة التخزين المؤقت في الخدمة المولدة تلقائيًا، يجب ربط هذا الغلاف فقط بنقاط النهاية التي تحتاج إلى وظيفة ذاكرة التخزين المؤقت، بينما يتم استخدام callApi العادي لبقية الطلبات.