Controleer backlinks van pagina's via een API en cache dit op een eerlijke manier
Onze index wordt één keer per maand bijgewerkt, dus de meeste opvragingen kunnen uit het geheugen worden bediend. Een recept voor caches die credits besparen zonder gebruikers verouderde onwaarheden te tonen.
Redactieteam AlfaLinks ·
De regel
Cache tot de volgende indexverversing, niet voor een vaste uur
Omdat de gegevens ongeveer maandelijks veranderen, levert een uur-TTL niets op behalve kosten. Een op maand gebaseerde sleutel geeft de hele maand hetzelfde antwoord en wordt in één keer ongeldig gemaakt.
Sleutel: actie + domein + params + indexmaand
TTL: tot het einde van de maand, plus een dag genade
Cache een foutrespons nooit
Waarom een korte TTL gewoon een donatie aan je creditsaldo is
Teams die nieuw zijn in linkgegevens kopiëren gewoonten van ranktrackers. Gewoonte één: een uurcache, omdat posities veranderen. Linkgrafieken veranderen zelden.
Een backlinks-oproep van 2 credits kost $0.0002. Dat klinkt als niets, totdat een lijstweergave er 50 per pagina-lading activeert over 400 actieve werkruimtes, die elke uur herhaalt voor identieke antwoorden.
De berekeningen hieronder zijn een voorbeeld, geen meting van iemands verkeer. Ga uit van 400 werkruimtes, 20 domeinweergaven elk per dag, 2 credits per weergave, en een 1-uur cache die misschien een vijfde van de tijd treft. De meeste weergaven raken nog steeds de API. Met een maand-sleutel zou hetzelfde verkeer de API slechts één keer per domein en maand bereiken, dus het verschil is het hele punt van het recept.
Zoekopdrachttools hebben versere gegevens nodig, en daarvoor blijven de grote suites de betere keuze. Voor linkcontext is maandelijks het product.
TTL per actie
Voorgesteld, niet verplicht. Alle acties lezen dezelfde maandelijkse index.
Actie
Credits
Voorgestelde TTL
Waarom
overzicht, statistieken
0
Tot einde maand
Gratis, maar je server bespaart nog steeds latentie
bulk_dr
1
Tot einde maand
Hele klantentabel in één oproep
refdomains, backlinks
2
Tot einde maand, per pagina-param
Neem pagina, per, sort op in de sleutel
anchors, toppages
2
Tot einde maand
Stabiel tussen verversingen
search, keyword
3
7 dagen
Zelden herhaald, goedkoop om caching over te slaan
Voorbeeld van verzoek: de cache opwarmen voor een klantentabel
Roep bulk_dr één keer per klant aan, niet één keer per rij. Tot 2.000 domeinen passen in één POST-lichaam en kosten één credit.
bash
curl -X POST "https://alfalinks.net/api.php?action=bulk_dr&key=sk_live_..." \
-d "domains=stripe.com,notion.so,linear.app,figma.com,vercel.com"
# billed once, whatever the row count
Bouw de cache in vijf stappen
Elke stap heeft één taak. Sla er één over en de foutmelding verschijnt later, meestal als een rekening.
01
Kies de sleutel
Gebruik de actie, het domein, de paginerings- en sorteerparameters, en de indexmaand. Sla alles over wat een gebruiker kan wijzigen zonder het antwoord te veranderen, zoals een weergavekleur of een tabbladnaam.
02
Sla de verwerkte respons op
Bewaar de gedecodeerde JSON met de ok-vlag en gegevens, niet de ruwe bytes. Een latere weergave kan dan de hele tabel uit het geheuzen herbouwen zonder een tweede oproep.
03
Verloop bij einde maand
Stel het verloopt in op het einde van de indexmaand, plus de dag van genade uit de regel hierboven. Gebruik dezelfde regel voor elke actie, zodat de logica in één functie zit en niet op vijf plaatsen.
04
Log het saldo bij elke oproep
Lees het _credits-object bij elke geauthenticeerde respons en schrijf het resterende saldo naar je eigen logboek. Een langzame daling in die regel is vaak het eerste teken dat een cachesleutel fout is.
05
Houd de trefferpercentage in de gaten
Volg hoe vaak een weergave uit de cache wordt bediend. Een laag percentage betekent dat de sleutel te specifiek is, of dat gebruikers bij elk bezoek een nieuw domein openen. Beide bevindingen zijn nuttig wanneer je de begroting plant.
Is verouderde data een productkeuze of een bug?
Een linkcijfer kan een maand oud zijn en toch correct zijn voor de index waaruit het komt. Of je scherm dit zegt, is de echte vraag. De meeste supporttickets over oude cijfers zijn labelproblemen. Labels lossen ze meestal op.
Geef elk cijfer zijn indexmaand. Toon het aan gebruikers. Zodra ze de datum kunnen zien, ziet het cijfer er niet meer uit als een gebroken feed, en die kleine lijn doet meer dan een kortere TTL ooit zou kunnen.
Hoe oud is te oud voor een linkcijfer?
Onze index wordt ongeveer één keer per maand ververst, dus een cijfer dat op de eerste dag is gecached, beschrijft dezelfde index als er een is die op de laatste dag is gecached. Er verandert niets in het antwoord binnen de maand. Probleem begint wanneer een gebruiker een link van gisteren verwacht, en dan is de oplossing een duidelijk label, zoals besproken in score labels.
Hebben gratis overzichtoproepen überhaupt een cache nodig?
De overzichtactie kost geen credits, dus de cache hier beschermt snelheid in plaats van het saldo. Je server betaalt nog steeds voor elke heen-en-weerreis, en een pagina die vijftig keer per minuut wordt geopend, zal dat voelen. Sla ook de gratis antwoorden op, met dezelfde maand-sleutel, en de pagina blijft snel terwijl je proxy stil blijft. De public lookup notes verklaren hetzelfde idee voor bezoekers.
Moet een verse link de cache ooit omzeilen?
Meestal nee. Een omzeiling kost credits voor een antwoord dat waarschijnlijk identiek is aan het gecachte. Als een klant erop aandringt, leg dan de indexmaand uit en bied één handmatige verversing per werkruimte per maand aan, in plaats van een open knop die iedereen in een lus kan drukken.
Bescherming tegen stampede en andere kleine dingen
Single-flight: als tien gebruikers hetzelfde domein openen, maak één upstream-aanroep en deel de belofte.
Verwarm op de eerste van de maand met een achtergrondtaak, niet om 9 uur wanneer gebruikers aankomen.
Sla de respons _credits.remaining op en waarschuw onder een drempelwaarde die je kiest.
Cache het negatieve resultaat 'domein niet gevonden' voor een dag, niet een maand.
Stel de cacheleeftijd bloot in de UI zodat support 'wanneer is dit opgehaald?' kan beantwoorden.
Waarom een cache krabben voor linkcontroles verslaat
Teams die backlinks van pagina's op schaal moeten controleren, beginnen vaak met scripts die zoekmachines direct bevragen. Die scripts stagneren. Ze zien er op dag één goedkoop uit, daarom houden teams ze veel langer vast dan ze zouden moeten. Een cache voor een stabiele API is meestal het goedkopere ontwerp, met minder onderdelen om te bewaken.
Het verschil toont zich in engineeringuren meer dan in de eerste factuur. Houd de cache saai, en de meeste van dieuren gebeuren niet.
Zoekmachines throttle geautomatiseerde queries, dus een script dat schoon loopt voor vijftig URL's kan stagneren bij vijftigduizend. Retries, proxy-pools en willekeurige vertragingen voegen allemaal kosten toe die niet op een creditlijn verschijnen, en ze breken zonder waarschuwing wanneer de target zijn responsen wijzigt.
Hoe houd je een lang lijstjob herstartbaar?
Schrijf elk voltooid domein naar de cache terwijl je gaat. Als de taak halverwege stopt, slaat een herstart elk domein over dat al een opgeslagen antwoord heeft en pakt hij op waar hij gebleven was. Niets wordt twee keer aangerekend voor dezelfde maand, omdat de sleutel het antwoord al bevat.
Voer de taak uit in een stabiel tempo in plaats van in één burst. De gespreide aanroepen houden de logs leesbaar en maken elke verandering in creditgebruik makkelijk uit te leggen.
Wat kost een lijst met 22.000 URL's met een cache?
Stel dat je 22.000 linkende URL's voor één klant moet controleren. Veel van hen delen een domein, dus dedupe eerst naar domeinen. Die 22.000 links kunnen teruggebracht worden tot een paar duizend unieke domeinen, en één bulk_dr-oproep neemt tot 2.000 van hen voor één credit. Sla elk resultaat op per domein en maand, en de lijst wordt helemaal geen per-URL-taak meer meer. Houd de rekenkunde in een korte notitie naast de taak, zodat de volgende persoon het kan herhalen met een andere lijstgrootte. Een cijfer met de berekening ernaast is makkelijker te vertrouwen dan een totaal op zichzelf.
Waar dit aansluit
De cache is de middenlaag in de counter setup. Zodra het werkt, wordt de kosten per seat voorspelbaar en kun je een plan prijzen rondom het met de per-seat comparison. Korte pagina's verdienen een duidelijk einde. Deze heeft het.
Cachevragen die we zien in code review
Moet de cache ook in de browser leven?
Een korte browsercache helpt bij navigatie met de back-knop, maar de gedeelde cache op je server doet de echte besparing. Houd client-side opslag tot minuten, omdat gebruikers op verschillende machines anders verschillende cijfers zouden zien voor hetzelfde domein op dezelfde dag.
Wat als een klant zegt dat een nieuwe link ontbreekt?
Controleer de indexmaand die in je UI wordt getoond. Als de link werd toegevoegd na de laatste verversing, zal hij verschijnen na de volgende. Bied een notitie aan, geen terugbetaling, omdat er niets kapot is.
Kan ik de cache op verzoek omzeilen?
Dat kan, maar elke omzeiling kost credits voor een antwoord dat waarschijnlijk identiek is. Bied het alleen aan aan beheerders, en rate-limit het per werkruimte om per ongeluk gemaakt loops te vermijden.
Paginering en de cachesleutel
Paginering bijt iedereen wel eens. Neem het op in de sleutel.
De backlinks en refdomains acties retourneren tot 1.000 rijen per oproep, met page en per tussen 10 en 5000, en diepe paginering is beperkt tot 50.000 rijen, dus een sleutel zonder die parameters zal pagina één voor elk verzoek bedienen.
Sortering hoort ook in de sleutel. Een gebruiker die omschakelt van DR aflopend naar alfabetisch verwacht een andere lijst, en de cache moet dit voldoen zonder een nieuwe upstream-aanroep wanneer de volledige set al is opgeslagen.
Een snelle test vangt de meeste sleutelfouten. Vraag pagina twee op, verander de sortering, en controleer dan dat de gecachte pagina twee verschilt van de gecachte pagina één. Als dat niet zo is, mist de sleutel een parameter. Vroeg gevonden, kost het minuten. Een klant ziet het nooit. Voer de test opnieuw uit vóór elke release, omdat een nieuwe sorteringsoptie de gebruikelijke reden is dat de sleutel breekt. Schrijf het in je release checklist.
Plan de exportknop apart: één achtergrondtaak, één opgeslagen bestand, en één melding wanneer het klaar is.
