Ce este cache-ul? Un ghid simplu pentru cei care construiesc aplicații

Cache-ul înseamnă să păstrezi o copie gata a ceva ce a fost lent sau costisitor de obținut, astfel încât următoarea cerere pentru acel lucru să poată primi răspuns rapid din copia respectivă. Copia salvată se numește cache. Browserul tău ține în cache imagini, ca un site să se încarce mai repede la a doua vizită; un server ține în cache rezultatul unei interogări lente din baza de date, ca să nu o ruleze pentru fiecare vizitator.

Cache-ul face aplicațiile mai rapide și mai ieftine de rulat. Marele lui compromis este că o copie poate deveni perimată.

De ce contează cache-ul când construiești cu AI

Vei întâlni cache-ul în aplicațiile construite cu AI în trei moduri:

• „Am actualizat aplicația, dar văd încă versiunea veche.” Acesta este cel mai frecvent moment legat de cache și de obicei este inofensiv — browserul sau un CDN îți arată o copie salvată.
• Viteza. Dacă o pagină e lentă pentru că recalculează aceleași numere pentru fiecare vizitator, cache-uirea rezultatului îi poate da senzația că se încarcă instant.
• Costul. Mulți constructori de aplicații și hosturi taxează calculul, timpul din baza de date și apelurile API externe. Dacă o mie de vizitatori declanșează aceeași cerere costisitoare, cache-ul te lasă să plătești o singură dată.

Să știi elementele de bază te ajută să ceri cache acolo unde ajută și să-l recunoști când el e motivul pentru care ceva pare greșit.

O analogie din viața de zi cu zi

Gândește-te la bucătăria unei cafenele aglomerate.

În fiecare dimineață, bucătarul ar putea prepara fiecare cafea din boabe proaspăt măcinate, la comandă. Asta e lent. În schimb, ține un ibric de cafea filtrată gata pe plită. Majoritatea clienților primesc o ceașcă în câteva secunde — asta este un cache hit. Când ibricul se golește, cineva face unul nou — un cache miss.

Dar cafeaua care stă prea mult se strică, așa că cafeneaua are o regulă: aruncă orice ibric mai vechi de 30 de minute. Această regulă este timpul de expirare al cache-ului. Nimeni nu ar păstra același ibric toată ziua, și nimeni nu ar prepara dinainte comanda cuiva cu lapte de ovăz și trei zaharuri — unele lucruri nu ar trebui puse deloc în cache.

Unde trăiesc cache-urile

O singură încărcare de pagină poate trece prin mai multe cache-uri, de la cel mai apropiat de utilizator la cel mai îndepărtat:

Un CDN (content delivery network) este practic o rețea mondială de cache-uri pentru fișierele site-ului tău.

Cum decide un cache ce păstrează

Fiecare cache trebuie să răspundă la aceleași întrebări:

• Ce poate fi pus în cache? Date publice, partajate (o imagine de produs, un articol de blog) — da. Date private (pagina contului unui utilizator, mesajele lui) — niciodată într-un cache partajat.
• Pentru cât timp? Acesta este TTL (time to live). Un logo poate fi păstrat un an; un nivel de stoc, 30 de secunde.
• Cum se actualizează? Fie copia expiră și este adusă din nou, fie aplicația o elimină deliberat când datele se schimbă — numit invalidare.

Pentru site-uri web, serverul le spune browserelor și CDN-urilor cum să ție în cache fiecare fișier, folosind antetul Cache-Control. De exemplu, Cache-Control: max-age=3600 înseamnă „poți refolosi această copie o oră”.

Unelte moderne de build se ocupă de partea cea mai grea pentru fișierele statice cu cache busting: de fiecare dată când un fișier se schimbă, primește un nume nou cu o amprentă, precum app.3f9a2c.js. Browserele pot ține în cache vechiul nume mult timp, pentru că versiunea nouă are pur și simplu alt nume.

Un exemplu practic: un catalog de produse

Ai un magazin online mic. Pagina principală afișează 50 de produse cu prețuri și niveluri de stoc din baza de date, plus o listă „în trend” care cere un calcul lent peste toate comenzile.

1. Imaginile și scripturile sunt păstrate în cache de browser și de CDN mult timp. Fiecare build nou dă fișierelor schimbate nume noi, astfel că actualizările apar în continuare.
2. Lista în trend se calculează o dată la 10 minute și se salvează într-un cache de aplicație. Fiecare vizitator din acele 10 minute primește instant rezultatul salvat.
3. Prețurile sunt păstrate în cache pentru puțin timp, iar cache-ul se golește de fiecare dată când editezi un produs, astfel că clienții nu văd mult timp un preț vechi.
4. Stocul la checkout nu se pune niciodată în cache. Când cineva apasă „Cumpără”, aplicația verifică baza de date reală, astfel că nu poate vinde un produs care tocmai s-a epuizat.
5. Pagina coșului și a contului nu sunt păstrate niciodată în cache-uri partajate, pentru că sunt personale.

Rezultatul: pagina principală e rapidă, baza de date face mult mai puțină muncă, iar nimic care contează pentru bani sau confidențialitate nu rămâne perimat.

Termeni cheie

Concepții greșite frecvente

• „Cache-ul este mereu bun.” Pui în cache lucrul greșit și apar bug-uri reale: prețuri vechi, postări noi care nu apar sau — cel mai rău caz — pagina privată a unui utilizator afișată altuia. Folosește cache-ul deliberat.
• „Dacă văd versiunea veche, actualizarea mea a eșuat.” De obicei nu a eșuat. Încearcă o reîncărcare forțată (Ctrl+Shift+R sau Cmd+Shift+R pe Mac) sau o fereastră privată înainte să presupui că ceva e stricat.
• „Cache-ul repară o aplicație lentă.” Ascunde lentoarea pentru cererile repetate. Prima cerere rămâne lentă, iar dacă problema de fond este un index lipsă din baza de date, repară și asta.
• „Ar trebui să pun în cache totul cât mai mult timp.” Timpii lungi de cache se potrivesc fișierelor care primesc nume noi când se schimbă. Pentru paginile HTML și date, timpii scurți sunt mai siguri.
• „Golirea cache-ului meu repară lucrurile pentru toată lumea.” Golește doar browserul tău. Vizitatorii și cache-urile CDN își păstrează propriile copii.

Ce să ceri constructorului tău de aplicații cu AI

• „Care părți ale acestei aplicații sunt lente și care ar putea fi puse în cache în siguranță?”
• „Pune în cache [lista în trend / rezultatul API] pentru [N] minute și golește-l când datele de bază se schimbă.”
• „Asigură-te că nicio pagină cu date personale sau de cont nu poate fi păstrată în cache de un CDN sau de un cache partajat.”
• „Setează timpi lungi de cache pentru fișierele statice cu amprentă și timpi scurți pentru HTML.”
• „Pune în cache răspunsurile de la [API extern], ca să nu-l apelăm la fiecare încărcare de pagină — și spune-mi cât de perimate ar putea deveni datele.”
• „Văd o versiune veche după publicare. Este cache-ul browserului meu sau ceva nu a fost implementat?”

Cache-ul în Mythex

După ce publici o actualizare a unei aplicații Mythex, documentația notează că cache-urile CDN pot rămâne în urmă puțin, iar o reîncărcare forțată a URL-ului public arată versiunea nouă — vezi Cum publici. Pagina Limite de hosting recomandă și cache-uirea activelor statice, pentru că hosting-ul, timpul din baza de date și lățimea de bandă se plătesc din soldul tău de credite. Orice dincolo de atât — cache-uirea rezultatelor interogărilor sau ale răspunsurilor API — este ceva ce ceri agentului să construiască în aplicația ta.

Lectură recomandată: ce este un CDN, cum faci site-ul tău mai rapid și ce este limitarea ratei.

Întrebări