Hastighedsgrænser

Chastify hastighedsbegrænser udvidelses-API-trafik for at beskytte låsesessioner, lagring, enheder og notifikationssystemer.

Hastighedsgrænser gælder for både iframe-bridge-trafik, der dirigeres via Chastify, og backend-kald foretaget med Developer API-nøgler.

Nuværende forlængelsesspande

Spand	Grænse	Typiske slutpunkter
Læs	300/min	session.get, state.get, metadata.get, fillæsninger, status for almindelig handling
Skriv	120/min	Skrivninger til backend-tilstand, opdateringer af metadata, konfiguration med regelmæssige handlinger, oprettelse af serververificeret kørsel
Upload	10/min	Upload af kørsels- og opsætningsfiler
Handling	30/min	Låsehandlinger, enhedskommandoer, brugerdefinerede logfiler, brugerdefinerede meddelelser, serververificeret resultatafregning
Token	30/min	Iframe-sessionsstart/generering af godkendelsestoken

Grænser evalueres over et tidsrum på et minut.

note

Dette er platformens standardindstillinger. Chastify-administratorer/webstedsejere kan konfigurere tilsidesættelser pr. udvidelse for officielle eller usædvanligt store udvidelser. Tilsidesættelser gemmes i udvidelsesappens konfiguration og cachelagres kortvarigt i Redis for hurtig søgning efter anmodningsstier.

info

Upload- og handlingskategorierne er bevidst strammere end læse-/tilstandskategorierne. Uploads bruger lagerplads og båndbredde. Handlinger kan påvirke låsetilstand, enheder, notifikationer og brugerens synlighedshistorik.

Sådan tælles nøgler

Nøgler til hastighedsgrænser inkluderer:

• autentificeret Chastify-bruger-id, når førsteparts-brugergrænsefladen kalder et slutpunkt
• Nøgle-id for udvikler-API'en, når din backend kalder slutpunkter for udvidelsessessioner
• IP-adresse til anonyme eller ikke-godkendte stier
• målet sessionId eller lockId, når det er tilgængeligt

Det betyder, at én støjende udvidelsessession ikke bør forbruge hele det globale udvidelses-API-budget.

Anbefalet klientadfærd

Din iframe eller backend bør behandle 429 Too Many Requests som en normal betingelse for gentagelse.

Brug eksponentiel backoff ved gentagne fejl:

async function callWithBackoff<T>(fn: () => Promise<T>, attempts = 4): Promise<T> {
  let delayMs = 500;

  for (let attempt = 1; attempt <= attempts; attempt += 1) {
    try {
      return await fn();
    } catch (error: any) {
      const status = error?.status ?? error?.response?.status;
      if (status !== 429 || attempt === attempts) throw error;

      await new Promise((resolve) => setTimeout(resolve, delayMs));
      delayMs *= 2;
    }
  }

  throw new Error("request_failed");
}

Vejledning til iframe-broen

For iframe bridge-klienter:

• Cache session.get-resultater i hele sidens levetid, medmindre du har brug for nye låsedata.
• Gem midlertidige ændringer i brugergrænsefladen lokalt, og send pålidelige ændringer til din backend.
• Undgå hurtige polling-løkker. Foretræk brugerudløste læsninger eller langsomme opdateringsintervaller.

Eksempel på debounced backend-lagring:

let saveTimer: number | undefined;

function scheduleStateSave(data: Record<string, unknown>) {
  window.clearTimeout(saveTimer);
  saveTimer = window.setTimeout(() => {
    fetch("/your-extension-backend/state", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(data),
    }).catch(console.error);
  }, 500);
}

Vejledning til backend-udvidelser

For backend-kald med en Developer API-nøgle:

• Hold privilegerede handlinger serververificerede og brugerudløste.
• Brug kun PUT/PATCH /api/extensions/sessions/:sessionId/state fra din backend med Developer API-legitimationsoplysninger.
• Gentag ikke låsehandlinger blindt, hvis det første forsøg muligvis var lykkedes.
• Gør spil-/udfordringsafgørelse idempotent med et kørsels-id.
• Upload kun filer, når brugeren eksplicit indsender en fil.
• Gem dine egne eksterne optegnelser, hvis du har brug for telemetri med højere frekvens.

warning

Hæv aldrig handlingsgrænser for at kompensere for ubekræftede browserkald. Browserens iframe-kode er ikke betroet. Følsomme mutationer bør valideres af din backend, før Chastify kaldes.

Hvilken spand skal jeg forvente?

Almindelige eksempler:

• GET /api/extensions/sessions/:sessionId bruger læse-bucketen.
• GET /api/extensions/sessions/:sessionId/state bruger læse-bucketen.
• PUT/PATCH /api/extensions/sessions/:sessionId/state bruger skrive-bucketen.
• POST /api/extensions/sessions/:sessionId/files bruger upload-bucketen.
• POST /api/extensions/sessions/:sessionId/action bruger handlingsbuckeden.
• POST /api/extensions/sessions/:sessionId/device-command bruger handlingsbuckeden.
• POST /api/extensions/sessions/:sessionId/logs/custom bruger handlingsbuckeden.
• POST /api/extensions/sessions/:sessionId/notifications/custom bruger handlingsbuckeden.
• GET /api/extensions/sessions/:sessionId/auth bruger token-bucketen.

Fremtidens granulære spande

De nuværende buckets er brede. Chastify kan opdele dem yderligere, efterhånden som Developer API'en vokser, for eksempel:

• state.write
• metadata.write
• lock.action
• notifications.custom
• device.command
• files.upload

Grænserne pr. udvidelse kan øges af Chastify-administratorer/webstedsejere, når en officiel eller godkendt udvidelse med høj volumen har et legitimt behov. Design klienter, så 429-håndteringen er generisk og ikke afhænger af nøjagtige bucketnavne eller faste platformstandarder.