React և Next.js քեշավորում․ գործնական ուղեցույց

Քեշավորում ժամանակակից React-ում և Next.js-ում․ ինչպես ճիշտ կիրառել

Քեշավորումը վեբ հավելվածների աշխատանքն արագացնելու ամենաարդյունավետ միջոցներից մեկն է։ Սակայն React-ի cache()-ի և Next.js-ի նոր Cache Components-ի դեպքում նույնքան կարևոր է հասկանալ՝ ինչ քեշավորել, որքան ժամանակ պահպանել տվյալները և երբ անվավեր դարձնել քեշը։

Քեշավորումը միշտ կարևոր դեր է ունեցել վեբ ծրագրավորման մեջ։ Անկախ նրանից՝ կառուցում ենք բլոգ, էլեկտրոնային առևտրի հարթակ, կառավարման վահանակ, թե ռեստորանների կառավարման համակարգ, հաճախ ստիպված ենք լինում նույն տվյալները բազմիցս ստանալ։

Ինչո՞ւ ամեն անգամ հարցում ուղարկել տվյալների բազա, եթե տվյալները չեն փոխվել։

Ինչո՞ւ յուրաքանչյուր այցելուի համար կրկին կանչել նույն API-ն, եթե խոսքը մի քանի օր առաջ հրապարակված բլոգային հոդվածի մասին է։

Եվ ամենակարևորը՝ ինչպե՞ս արագացնել հավելվածը՝ առանց հնացած կամ մեկ օգտատիրոջը պատկանող տվյալները մյուսին սխալմամբ տրամադրելու։

Ժամանակակից React-ն ու Next.js-ն առաջարկում են քեշավորման մի քանի մեխանիզմներ։ Սակայն դրանք լուծում են տարբեր խնդիրներ, և սխալ մեխանիզմի ընտրությունը կարող է առաջացնել դժվար հայտնաբերվող սխալներ։

Եկեք ուսումնասիրենք, թե ինչպես են դրանք աշխատում, երբ կիրառել յուրաքանչյուրը և ինչպես օգտագործել իրական օրինակներում։

1. Նախ հասկանանք քեշավորման տարբեր տեսակները

Մինչ կոդ գրելը՝ պետք է հասկանալ մի կարևոր տարբերություն․ բոլոր քեշերն ունեն նույն աշխատանքի սկզբունքը կամ պահպանման ժամկետը չէ, որ ունեն։

React-ն ու Next.js-ն առաջարկում են տարբեր մեխանիզմներ, որոնք կարող են նման թվալ, բայց տարբեր կերպ են աշխատում։

ՄեխանիզմԻնչ է անումՕգտագործման օրինակReact cache()Նույն սերվերային հարցման ընթացքում օգնում է խուսափել կրկնվող աշխատանքիցԿրկնվող տվյալների բազայի հարցումներNext.js 'use cache'Քեշավորում է ֆունկցիայի, բաղադրիչի կամ route-ի արդյունքը՝ տարբեր հարցումների միջև վերօգտագործելու համարԲլոգի հոդվածներ, ապրանքների կատալոգcacheLife()Սահմանում է քեշի թարմության և պահպանման վարքագիծըՈրոշել՝ որքան հաճախ թարմացնել բովանդակությունըcacheTag()Քեշավորված տվյալները կապում է պիտակների հետՓոխկապակցված տվյալների անվավերացումupdateTag()Server Action-ից անմիջապես անվավեր է դարձնում նշված տվյալների քեշըԹարմացված հոդվածը անմիջապես տեսնելըrevalidateTag()Թարմացնում է նշված քեշավորված տվյալները՝ ներառյալ հնացած տվյալները ժամանակավորապես սպասարկելու հնարավորությունըՀրապարակված բովանդակության թարմացումrevalidatePath()Վերավավերացնում է կոնկրետ էջի կամ route-ի հետ կապված քեշավորված տվյալներըԷջի թարմացում տվյալների փոփոխությունից հետո

Այս մեխանիզմները փոխկապակցված են, բայց փոխարինելի չեն։

Օրինակ՝ React-ի cache()-ը չի ստեղծում բոլոր հարցումների համար ընդհանուր, երկարաժամկետ քեշ։ Իսկ Next.js-ի 'use cache'-ը կարող է թույլ տալ վերօգտագործել արդյունքները տարբեր հարցումների ընթացքում։

Հենց այս տարբերությունն է որոշում՝ որ լուծումն ընտրել։

2. React cache()․ խուսափենք նույն աշխատանքը կրկնելուց

Սկսենք React-ի cache() API-ից։

Պատկերացնենք՝ ապրանքի էջն ունի երեք Server Component.

• Ապրանքի տվյալներ

• Ապրանքի հասանելիություն

• Նմանատիպ ապրանքների առաջարկություններ

Երեք բաղադրիչներին էլ անհրաժեշտ է նույն ապրանքի տվյալը։ Եթե յուրաքանչյուր բաղադրիչ առանձին հարցում կատարի տվյալների բազային, կարող ենք կրկնվող աշխատանք ունենալ։

Կարող ենք ստեղծել քեշավորված ֆունկցիա ընդհանուր մոդուլում։

// lib/products.ts
import { cache } from 'react';
import { db } from '@/lib/db';

export const getProduct = cache(async (productId: string) => {
  return db.query.products.findFirst({
    where: (products, { eq }) =>
      eq(products.id, productId),
  });
});

Այժմ տարբեր Server Component-ներ կարող են օգտագործել նույն ֆունկցիան։

// app/products/[id]/page.tsx
import { getProduct } from '@/lib/products';

export default async function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;

  const product = await getProduct(id);

  if (!product) {
    return <p>Ապրանքը չի գտնվել։</p>;
  }

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.price}</p>
    </main>
  );
}

Եթե նույն սերվերային հարցման ընթացքում մի քանի Server Component նույն արգումենտներով կանչեն այս ֆունկցիան, React-ը կարող է կրկին օգտագործել արդյունքը՝ տվյալների բազային նորից հարցում ուղարկելու փոխարեն։

Որո՞նք են առավելությունները

• Տվյալների բազայի կրկնվող հարցումների նվազեցում։

• Նույն հաշվարկը կրկին կատարելու անհրաժեշտության նվազեցում։

• Արդյունքների վերօգտագործում տարբեր բաղադրիչների միջև։

• Այս խնդրի համար առանձին մշտական քեշավորման ծառայություն ներդնելու անհրաժեշտության բացակայություն։

Ո՞րն է սահմանափակումը

React-ի cache()-ը սահմանափակված է սերվերային հարցման շրջանակով։ Արդյունքը ինքնաբերաբար չի պահպանվում հաջորդ այցելուի համար։

Եթե 1000 այցելու բացում է նույն ապրանքի էջը, միայն cache()-ի օգտագործումը չի ապահովում, որ բոլոր հարցումները կօգտագործեն մեկ ընդհանուր, երկարաժամկետ քեշ։

Օգտագործիր React cache()-ը մեկ սերվերային render-ի ընթացքում կրկնվող աշխատանքից խուսափելու համար, ոչ թե երկարաժամկետ քեշավորման նպատակով։

Կարևոր է նաև քեշավորված ֆունկցիան սահմանել ընդհանուր մոդուլում, այլ ոչ թե ստեղծել դրա նոր տարբերակը յուրաքանչյուր բաղադրիչի ներսում։ Հակառակ դեպքում տարբեր բաղադրիչները կարող են չօգտագործել նույն քեշավորումը։

3. Next.js 'use cache'․ պահպանենք արդյունքները տարբեր հարցումների միջև

Այժմ դիտարկենք ժամանակակից Next.js-ի քեշավորման հնարավորությունները։

Next.js 16-ում Cache Components-ը կարելի է միացնել cacheComponents կարգավորման միջոցով։

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

Այս հնարավորությունը միացնելուց հետո կարող ենք օգտագործել 'use cache' հրահանգը՝ ֆունկցիայի կամ բաղադրիչի արդյունքը քեշավորելու համար։

Դիտարկենք բլոգի օրինակ։

Հոդվածը հրապարակվելուց հետո այն սովորաբար հաճախ չի փոխվում։ Ուստի անհրաժեշտ չէ յուրաքանչյուր այցելուի համար կրկին հարցում ուղարկել տվյալների բազա։

// lib/posts.ts
import { cacheLife, cacheTag } from 'next/cache';
import { db } from '@/lib/db';

export async function getPost(slug: string) {
  'use cache';

  cacheLife('hours');
  cacheTag('posts', `post-${slug}`);

  return db.query.posts.findFirst({
    where: (posts, { eq }) => eq(posts.slug, slug),
  });
}

Այժմ կարող ենք այս ֆունկցիան օգտագործել էջում։

// app/blog/[slug]/page.tsx
import { getPost } from '@/lib/posts';

export default async function BlogPostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = await getPost(slug);

  if (!post) {
    return <h1>Հոդվածը չի գտնվել</h1>;
  }

  return (
    <article>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
    </article>
  );
}

Այս ֆունկցիայի արդյունքը կարող է վերօգտագործվել տարբեր հարցումների ընթացքում՝ ամեն այցելուի համար տվյալների բազայի հարցումը կրկնելու փոխարեն։

cacheLife('hours')-ը սահմանում է քեշի թարմության քաղաքականությունը, իսկ cacheTag()-ը հնարավորություն է տալիս հետագայում անվավեր դարձնել համապատասխան քեշավորված տվյալները։

Ճշգրիտ վարքագիծը կախված է ընտրված քեշավորման պրոֆիլից։ Որոշ դեպքերում հնացած արժեքը կարող է տրամադրվել՝ միաժամանակ սկսելով դրա թարմացումը։

Առավելությունները

• Ավելի արագ պատասխաններ հաճախակի բացվող էջերի համար։

• Տվյալների բազայի և API-ի հարցումների նվազեցում։

• Սերվերի բեռնվածության նվազեցում։

• Ավելի լավ մասշտաբայնություն, երբ շատ օգտատերեր նույն տվյալներն են պահանջում։

Սահմանափակումները

• Տվյալները կարող են հնանալ մինչև քեշի վերավավերացումը։

• Քեշի բանալիներն ու ֆունկցիայի արգումենտները պետք է ճիշտ նախագծվեն։

• Քեշի պահպանումն ու կայունությունը կախված են deployment միջավայրից և կարգավորումներից։

• Անհատականացված տվյալների դեպքում անհրաժեշտ է կանխել տարբեր օգտատերերի տվյալների խառնվելը։

Հանրային բլոգային հոդվածների համար սա հաճախ հարմար լուծում է։ Օգտատիրոջ անձնական տվյալների համար անհրաժեշտ է շատ ավելի զգույշ մոտեցում։

4. cacheLife()․ որոշենք՝ որքան ժամանակ պահպանել տվյալները

Տվյալների քեշավորումը խնդրի միայն կեսն է։ Պետք է նաև որոշել՝ երբ տվյալները պետք է համարվեն հնացած կամ հեռացվեն քեշից։

Next.js-ն առաջարկում է cacheLife() մեխանիզմը։

import { cacheLife } from 'next/cache';

export async function getCategories() {
  'use cache';

  cacheLife('days');

  return db.query.categories.findMany();
}

Եթե կատեգորիաները հազվադեպ են փոխվում, դրանց ավելի երկար քեշավորումը կարող է նվազեցնել տվյալների բազայի ավելորդ հարցումները։

Իսկ ապրանքների կատալոգի համար կարող է պահանջվել ավելի կարճ թարմության միջակայք։

export async function getProducts() {
  'use cache';

  cacheLife('hours');

  return db.query.products.findMany();
}

Next.js-ն առաջարկում է պատրաստի պրոֆիլներ, ինչպիսիք են 'minutes', 'hours', 'days' և 'weeks'։ Անհրաժեշտության դեպքում հնարավոր է սահմանել նաև սեփական պրոֆիլները։

Կարևորն այն է, որ cacheLife()-ը պարզապես քեշը միացնելու կամ անջատելու միջոց չէ։ Այն սահմանում է տվյալների թարմության քաղաքականությունը։

Ինչպե՞ս ընտրել քեշի տևողությունը

Տվյալների տեսակՀնարավոր մոտեցումՀրապարակված բլոգային հոդվածներԱվելի երկար քեշավորումԱպրանքների կատալոգՄիջին տևողություն և փոփոխությունից հետո անվավերացումԿատեգորիաների ցանկԵրկար քեշավորում, եթե փոփոխությունները հազվադեպ ենՀաճախ թարմացվող dashboardԿարճ քեշավորում կամ հարցման պահին տվյալների ստացումՕգտատիրոջ անձնական տվյալներԽուսափել ընդհանուր քեշավորումից, եթե մեկուսացումը երաշխավորված չէ

Սրանք մեկնարկային առաջարկներ են, ոչ թե բոլոր նախագծերի համար պարտադիր կանոններ։

Ճիշտ ընտրությունը կախված է տվյալների փոփոխման հաճախականությունից և հնացած տվյալների տրամադրման ռիսկից։

5. cacheTag()․ անվավեր դարձնենք միայն փոփոխված տվյալների քեշը

Սա քեշավորման ամենաօգտակար հնարավորություններից մեկն է իրական նախագծերում։

Պատկերացնենք՝ ադմինիստրատորը խմբագրում է բլոգային հոդվածը։ Մենք չենք ցանկանում ամբողջ կայքի քեշավորումն անջատել միայն այն պատճառով, որ մեկ հոդված է փոխվել։

Փոխարենը կարող ենք քեշավորված տվյալները կապել պիտակների հետ։

import { cacheLife, cacheTag } from 'next/cache';

export async function getPost(slug: string) {
  'use cache';

  cacheLife('days');
  cacheTag('posts', `post-${slug}`);

  return db.query.posts.findFirst({
    where: (posts, { eq }) => eq(posts.slug, slug),
  });
}

Այս օրինակում ունենք երկու պիտակ։

• posts — ընդհանուր պիտակ՝ հոդվածների տվյալների համար։

• post-${slug} — կոնկրետ հոդվածի պիտակ։

Երբ ադմինիստրատորը փոփոխում է հոդվածը, կարող ենք անվավեր դարձնել համապատասխան քեշավորված տվյալները։

// app/blog/actions.ts
'use server';

import { updateTag } from 'next/cache';
import { db } from '@/lib/db';

export async function updatePost(
  slug: string,
  title: string,
  content: string
) {
  // Այստեղ կատարում ենք տվյալների բազայի թարմացումը։

  updateTag(`post-${slug}`);
  updateTag('posts');
}

Տվյալների բազայի իրական թարմացման հարցումը կախված է քո օգտագործած ORM-ից և տվյալների կառուցվածքից։ Վերևի օրինակը ցույց է տալիս քեշի անվավերացման տրամաբանությունը։

updateTag()-ը նախատեսված է Server Action-ների համար և թույլ է տալիս անմիջապես անվավեր դարձնել նշված պիտակներով քեշավորված տվյալները։ Հաջորդ հարցման ժամանակ տվյալները կարող են կրկին ստացվել թարմացված վիճակով։

Սա հատկապես օգտակար է՝

• Բովանդակության կառավարման համակարգերում։

• Ադմինիստրատիվ վահանակներում։

• Էլեկտրոնային առևտրի հարթակներում։

• Այն դեպքերում, երբ օգտատերը տվյալը թարմացնելուց հետո անմիջապես պետք է տեսնի փոփոխությունը։

Սկզբունքը պարզ է․ քեշավորիր այնտեղ, որտեղ դա օգտակար է, և անվավեր դարձրու միայն այն տվյալների քեշը, որոնք փոխվել են։

6. updateTag() vs. revalidateTag()․ ո՞րն օգտագործել

Այս երկու API-ները հեշտ է շփոթել, սակայն դրանք նախատեսված են տարբեր վարքագծերի համար։

Օգտագործիր updateTag(), երբ փոփոխությունը պետք է անմիջապես տեսանելի լինի

Օրինակ՝ ադմինիստրատորը խմբագրում է հոդվածը և ցանկանում է պահպանելուց անմիջապես հետո տեսնել նոր բովանդակությունը։

'use server';

import { updateTag } from 'next/cache';

export async function publishPost(slug: string) {
  // Հոդվածը պահպանվել է տվյալների բազայում։

  updateTag(`post-${slug}`);
}

updateTag()-ը նախատեսված է Server Action-ներում օգտագործելու և քեշի անհապաղ ժամկետանցման համար։

Օգտագործիր revalidateTag(), երբ ընդունելի է հնացած տվյալը ժամանակավորապես տրամադրելը

Հանրային բլոգի կամ ապրանքների կատալոգի դեպքում հնարավոր է ընդունելի լինի ցուցադրել առկա քեշավորված տարբերակը՝ միաժամանակ թարմացնելով այն ֆոնային ռեժիմով։

'use server';

import { revalidateTag } from 'next/cache';

export async function refreshPublishedPosts() {
  revalidateTag('posts', 'max');
}

'max' պրոֆիլն օգտագործում է stale-while-revalidate մոտեցումը։ Այսինքն՝ հնարավոր է տրամադրվի հին տարբերակը, մինչ սերվերը ստանում է թարմ տվյալները։

Սա կարող է բարելավել արձագանքման արագությունը, բայց ճիշտ ընտրություն չէ, եթե օգտատերը պետք է անմիջապես տեսնի հենց նոր պահպանած տվյալը։

Երկրորդ արգումենտը կարևոր է․ ժամանակակից Next.js-ում պետք է ընտրել վերավավերացման համապատասխան վարքագիծը՝ revalidateTag()-ը պարզապես բոլոր դեպքերում անհապաղ թարմացում համարելու փոխարեն։

7. Իսկ ի՞նչ է կատարվում fetch()-ի քեշավորման դեպքում

Շատ ծրագրավորողներ Next.js-ի քեշավորմանը ծանոթացել են fetch()-ի կարգավորումներից։

Օրինակ՝

const response = await fetch(
  'https://api.example.com/products',
  {
    cache: 'force-cache',
  }
);

Այս տարբերակը բացահայտ պահանջում է քեշավորման վարքագիծ։

Իսկ Cache Components-ը միացված Next.js նախագծում կարող ենք հարցում կատարող ֆունկցիան տեղադրել 'use cache' շրջանակի մեջ և կառավարել դրա պահպանման տևողությունը cacheLife()-ով։

import { cacheLife } from 'next/cache';

export async function getProductsFromApi() {
  'use cache';

  cacheLife('hours');

  const response = await fetch(
    'https://api.example.com/products'
  );

  if (!response.ok) {
    throw new Error('Չհաջողվեց ստանալ ապրանքները');
  }

  return response.json();
}

Այս մոտեցումները պատկանում են տարբեր քեշավորման մեխանիզմների, ուստի կարևոր է հասկանալ՝ որ շերտն է պատասխանատու տվյալների պահպանման համար։

Մի՛ ենթադրիր, որ ցանկացած fetch() հարցում ինքնաբերաբար քեշավորվում է։ Վարքագիծը կախված է Next.js-ի տարբերակից, կարգավորումներից և օգտագործվող մեխանիզմից։

Cache Components օգտագործելիս 'use cache'-ը հնարավորություն է տալիս հստակ սահմանել այն ֆունկցիան կամ բաղադրիչը, որի արդյունքը ցանկանում ենք քեշավորել։

8. Քեշավորման ամենավտանգավոր սխալը․ օգտատիրոջ անհատական տվյալները

Քեշավորումը կարող է զգալիորեն արագացնել հավելվածը, բայց սխալ քեշավորման սահմանները կարող են անվտանգության խնդիր առաջացնել։

Դիտարկենք հետևյալ օրինակը։

// Մի կիրառիր այս մոտեցումը անձնական տվյալների համար
// առանց օգտատերերի մեկուսացումը երաշխավորելու։

export async function getCurrentUserProfile() {
  'use cache';

  // Այստեղ ստանում ենք ընթացիկ օգտատիրոջ տվյալները։
}

Խնդիրն այն է, որ քեշավորված ֆունկցիաները չպետք է անուղղակիորեն կախված լինեն հարցմանը հատուկ տեղեկություններից, օրինակ՝ cookies-ից կամ headers-ից։

Next.js-ը խորհուրդ է տալիս հարցմանը հատուկ արժեքները ստանալ քեշավորված շրջանակից դուրս և անհրաժեշտության դեպքում փոխանցել դրանք որպես արգումենտներ։

Օրինակ՝ եթե օգտատիրոջ ID-ն ստացվել է և վավերացվել վստահելի նույնականացման գործընթացում, կարող ենք այն փոխանցել քեշավորված ֆունկցիային։

import { cacheLife } from 'next/cache';

export async function getPublicUserProfile(userId: string) {
  'use cache';

  cacheLife('minutes');

  return db.query.users.findFirst({
    where: (users, { eq }) => eq(users.id, userId),
    columns: {
      id: true,
      displayName: true,
      avatarUrl: true,
    },
  });
}

Այս օրինակը հարմար է միայն այն տվյալների համար, որոնք անվտանգ է քեշավորել և վերօգտագործել՝ համաձայն հավելվածի հասանելիության կանոնների։

Օգտատիրոջ ID-ն պետք է ստացվի վստահելի և վավերացված նույնականացման գործընթացից։ Քեշավորված արդյունքը չպետք է բացահայտի անձնական տվյալներ։

ID-ն որպես արգումենտ փոխանցելը օգնում է տարբերակել քեշի գրառումները, բայց չի փոխարինում թույլտվությունների ստուգմանը։

Անձնական հաշվի տվյալների, իրավունքների կամ ֆինանսական տեղեկությունների համար ամենաանվտանգ լուծումը կարող է լինել ընդհանուր երկարաժամկետ քեշավորումից հրաժարվելը։

Երբեք մի՛ ենթադրիր, որ միայն քեշի բանալին տվյալներն անվտանգ է դարձնում։

9. Ե՞րբ չարժե քեշավորել

Քեշավորումը միշտ չէ, որ ճիշտ լուծում է։

Վերանայիր քեշավորման անհրաժեշտությունը, երբ՝

• Տվյալները հաճախ են փոխվում և միշտ պետք է թարմ լինեն։

• Հնացած տվյալ տրամադրելու գինը բարձր է։

• Քեշի անվավերացման բարդությունն ավելի մեծ է, քան դրա օգուտը։

• Արդյունքը կախված է հարցմանը հատուկ տեղեկություններից, որոնք անվտանգ հնարավոր չէ վերօգտագործել։

• Քեշավորված արդյունքը կարող է բացահայտել տվյալներ, որոնք չպետք է հասանելի լինեն այլ օգտատերերի։

Օրինակ՝ ռեստորանների կառավարման հավելվածում կարելի է քեշավորել հանրային մենյուն, ռեստորանի նկարագրությունը և կատեգորիաները։

Սակայն սեղանների ընթացիկ հասանելիությունը, նոր պատվերները, վճարման կարգավիճակը և հաճախորդների անձնական տվյալները պահանջում են շատ ավելի զգույշ մոտեցում։

Հանրային մենյուի փոփոխությունը կարող է որոշ ժամանակ անց տեսանելի դառնալ։ Վճարման կարգավիճակը նույն կերպ դիտարկել չի կարելի։

Նպատակը ամեն ինչ քեշավորելը չէ։ Նպատակն է հասկանալ՝ որ տվյալները կարելի է անվտանգ վերօգտագործել, իսկ որոնք պետք է ստանալ կամ ստուգել յուրաքանչյուր հարցման ժամանակ։

10. Քեշավորման գործնական ռազմավարություն նոր Next.js նախագծի համար

Եթե այսօր կառուցեի նոր հավելված ժամանակակից Next.js-ով, կաշխատեի հետևյալ հերթականությամբ։

Քայլ 1․ Տարբերակել տվյալները։

Առանձնացնել հանրային բովանդակությունը, հազվադեպ փոփոխվող տվյալները, ընթացիկ գործառնական տվյալները և օգտատիրոջ անձնական տեղեկությունները։

Քայլ 2․ Ընտրել ամենապարզ համապատասխան մեխանիզմը։

Օգտագործել React cache()՝ մեկ հարցման ընթացքում կրկնվող աշխատանքից խուսափելու համար։ Ընտրել Next.js 'use cache'-ը, երբ արդյունքը կարելի է վերօգտագործել տարբեր հարցումների միջև։

Քայլ 3․ Սահմանել տվյալների թարմության քաղաքականությունը։

Ընտրել համապատասխան cacheLife() պրոֆիլ՝ հաշվի առնելով տվյալների փոփոխման հաճախականությունը։

Քայլ 4․ Ավելացնել պիտակներ, երբ տվյալների թարմացման գործընթացը հստակ է։

Օգտագործել cacheTag()՝ քեշավորված տվյալները կապելու այն բովանդակության հետ, որին դրանք վերաբերում են։

Քայլ 5․ Տվյալները փոփոխելուց հետո անվավեր դարձնել համապատասխան քեշը։

Օգտագործել updateTag()՝ Server Action-ում անմիջապես թարմացված տվյալը տեսնելու համար, կամ revalidateTag()՝ այն դեպքերում, երբ ընդունելի է stale-while-revalidate մոտեցումը։

Քայլ 6․ Չափել արդյունքները։

Համեմատել պատասխանի ժամանակը, տվյալների բազայի հարցումների քանակը, հասանելի քեշի վիճակագրությունը և թարմացված բովանդակության ճշտությունը։

Քայլ 7․ Ստուգել սահմանային դեպքերը։

Փորձարկել՝ ինչ է տեղի ունենում բովանդակությունը փոփոխելիս, ջնջելիս, հրապարակելիս և տարբեր օգտատերերի հաշիվներով մուտք գործելիս։

Քեշավորումը չի ավարտվում տվյալները պահպանելու պահին։ Այն ավարտված է, երբ հավելվածը ճիշտ տվյալներն է տրամադրում ճիշտ ժամանակին։

Եզրակացություն

Ժամանակակից React-ն ու Next.js-ը ծրագրավորողներին ավելի մեծ վերահսկողություն են տալիս քեշավորման նկատմամբ։

React-ի cache()-ն օգնում է խուսափել նույն սերվերային հարցման ընթացքում կրկնվող աշխատանքից։ Next.js-ի 'use cache'-ը թույլ է տալիս վերօգտագործել արդյունքները տարբեր հարցումների ընթացքում, իսկ cacheLife(), cacheTag(), updateTag() և revalidateTag() մեխանիզմներն օգնում են կառավարել տվյալների թարմությունը։

Սակայն այս API-ները փոխարինելի չեն, և ամեն ինչ քեշավորելը ինքնաբերաբար չի բարելավում հավելվածը։

Լավ քեշավորման ռազմավարությունը սկսվում է երեք հարցից։

1. Կարո՞ղ ենք այս տվյալներն անվտանգ վերօգտագործել։

2. Որքա՞ն կարող են դրանք հնանալ՝ մինչև դա խնդիր դառնա։

3. Ի՞նչ պետք է տեղի ունենա, երբ տվյալները փոխվեն։

Եթե նախ պատասխանենք այս հարցերին, ճիշտ մեխանիզմի ընտրությունն ու իրականացումը շատ ավելի հեշտ կլինի։

Իմ հիմնական սկզբունքը պարզ է․

Քեշավորիր այն, ինչ կարելի է վերօգտագործել։ Անվավեր դարձրու այն, ինչ փոխվել է։ Երբեք մի՛ զոհաբերիր ճշտությունը՝ հանուն արագության։

Որովհետև ամենաարագ աշխատող հավելվածը այն չէ, որն ամենաշատ տվյալներն է քեշավորում։ Դա այն հավելվածն է, որը ճիշտ, անվտանգ և արդյունավետ կերպով տրամադրում է անհրաժեշտ տվյալները։

Օգտակար հղումներ

• React cache() — պաշտոնական փաստաթղթեր

• Next.js 'use cache' — պաշտոնական փաստաթղթեր

• Next.js Cache Components

• Next.js cacheLife()

• Next.js cacheTag()

• Next.js updateTag()

• Next.js revalidateTag()