Vad är caching? En lättförståelig guide för appbyggare

Caching innebär att spara en färdig kopia av något som var långsamt eller dyrt att hämta, så att nästa förfrågan kan besvaras snabbt från kopian. Den sparade kopian kallas en cache. Din webbläsare cachar bilder så att en sajt laddas snabbare vid ditt andra besök; en server cachar resultatet av en långsam databasfråga så att den inte behöver köra den för varje besökare.

Caching gör appar snabbare och billigare att köra. Dess stora avvägning är att en kopia kan bli inaktuell.

Varför caching spelar roll när du bygger med AI

Du stöter på caching i AI-byggda appar på tre sätt:

• "Jag uppdaterade appen men ser fortfarande den gamla versionen." Detta är det vanligaste caching-momentet, och det är oftast ofarligt – din webbläsare eller ett CDN visar en sparad kopia.
• Hastighet. Om en sida är långsam för att den räknar om samma siffror för varje besökare kan caching av resultatet få den att kännas omedelbar.
• Kostnad. Många AI-byggare och hosting-tjänster tar betalt för beräkning, databastid och externa API-anrop. Om tusen besökare utlöser samma dyra förfrågan låter caching dig betala för den en gång.

Att känna till grunderna låter dig be om caching där den hjälper och upptäcka den när den är orsaken till att något ser fel ut.

En vardaglig liknelse

Tänk dig ett upptaget cafés kök.

Varje morgon kan kocken brygga varje kaffe från nymalda bönor när det beställs. Det är långsamt. I stället håller han en kanna bryggkaffe redo på värmeplattan. De flesta gäster får en kopp på några sekunder – det är en cache-träff. När kannan tar slut bryggs en ny – en cache-miss.

Men kaffe som står för länge blir gammalt, så caféet har en regel: kasta varje kanna som är äldre än 30 minuter. Den regeln är cachens utgångstid. Ingen skulle behålla samma kanna hela dagen, och ingen skulle förbryggt en kunds specialbeställning med havremjölk och tre sockerbitar – vissa saker bör inte cachas alls.

Var cacher finns

En enda sidladdning kan passera flera cacher, från närmast användaren till längst bort:

Ett CDN (content delivery network) är i grunden ett världsomspännande nätverk av cacher för din sajts filer.

Hur en cache bestämmer vad som ska sparas

Varje cache måste svara på samma frågor:

• Vad kan cachas? Offentlig, delad data (en produktbild, ett blogginlägg) – ja. Privat data (en användares kontosida, deras meddelanden) – aldrig i en delad cache.
• Hur länge? Detta är TTL (time to live). En logotyp kanske cachas i ett år; en lagersaldo i 30 sekunder.
• Hur uppdateras den? Antingen går kopian ut och hämtas på nytt, eller så tar appen medvetet bort den när datat ändras – kallat invalidering.

För webbplatser berättar servern för webbläsare och CDN:er hur varje fil ska cachas via headern Cache-Control. Till exempel betyder Cache-Control: max-age=3600 "du får återanvända den här kopian i en timme".

Moderna byggverktyg hanterar den svåraste delen för statiska filer med cache busting: varje gång en fil ändras får den ett nytt namn med ett fingeravtryck, som app.3f9a2c.js. Webbläsare kan cacha det gamla namnet länge, eftersom den nya versionen helt enkelt har ett annat namn.

Ett praktiskt exempel: en produktkatalog

Du har en liten nätbutik. Startsidan visar 50 produkter med priser och lagersaldo från databasen, plus en lista över "trendande" produkter som kräver en långsam beräkning över alla beställningar.

1. Bilder och skript cachas av webbläsaren och CDN:et under lång tid. Varje ny build ger ändrade filer nya namn, så uppdateringar syns ändå.
2. Trendlistan beräknas en gång var 10:e minut och sparas i en applikationscache. Varje besökare under dessa 10 minuter får det sparade resultatet direkt.
3. Priser cachas en kort tid, och cachen rensas när du ändrar en produkt, så kunderna aldrig ser ett gammalt pris särskilt länge.
4. Lager vid kassan cachas aldrig. När någon klickar på "Köp" kontrollerar appen den riktiga databasen, så den kan inte sälja en vara som precis tagit slut.
5. Varukorgen och kontosidorna lagras aldrig i delade cacher, eftersom de är personliga.

Resultatet: startsidan är snabb, databasen gör betydligt mindre arbete, och inget som spelar roll för pengar eller integritet är någonsin inaktuellt.

Nyckeltermer

Vanliga missuppfattningar

• "Caching är alltid bra." Att cacha fel saker orsakar riktiga buggar: gamla priser, saknade nya inlägg eller – värsta fallet – en användares privata sida som visas för en annan. Cacha medvetet.
• "Om jag ser den gamla versionen misslyckades min uppdatering." Oftast gjorde den inte det. Prova en hård uppdatering (Ctrl+Shift+R, eller Cmd+Shift+R på Mac) eller ett privat fönster innan du antar att något är trasigt.
• "Caching åtgärdar en långsam app." Det döljer långsamhet för upprepade förfrågningar. Den första förfrågan är fortfarande långsam, och om grundproblemet är ett saknat databasindex ska även det åtgärdas.
• "Jag bör cacha allt så länge som möjligt." Långa cachetider passar filer som får nya namn när de ändras. För HTML-sidor och data är kortare tider säkrare.
• "Om jag rensar min cache fixar det för alla." Det rensar bara din webbläsare. Besökare och CDN-cacher har fortfarande sina egna kopior.

Vad du ska fråga din AI-byggare

• "Vilka delar av appen är långsamma, och vilka kan cachas säkert?"
• "Cacha [trendlistan / API-resultatet] i [N] minuter, och rensa det när den underliggande datan ändras."
• "Se till att ingen sida med personlig data eller kontodata kan cachas av ett CDN eller en delad cache."
• "Ställ långa cachetider för filer med fingeravtryck och korta för HTML."
• "Cacha svar från [externt API] så att vi inte anropar det vid varje sidladdning – och berätta hur inaktuella data kan bli."
• "Jag ser en gammal version efter publicering. Är det min webbläsarcache, eller är något inte driftsatt?"

Caching i Mythex

Efter att du publicerat en uppdatering av en Mythex-app noterar dokumentationen att CDN-cacher kan släpa efter en kort stund, och en hård uppdatering av den publika webbadressen visar den nya versionen – se Så publicerar du. Sidan Hosting-gränser rekommenderar också att statiska tillgångar cachas, eftersom hosting, databastid och bandbredd betalas från ditt kreditsaldo. Allt utöver det – till exempel caching av frågeresultat eller API-svar – är något du ber agenten bygga in i din app.

Relaterad läsning: vad ett CDN är, hur du gör din webbplats snabbare och vad rate limiting är.

Frågor