Passa al contenuto principale

limiti di tariffa

Chastify limita il traffico API dell'estensione per proteggere sessioni di blocco, archiviazione, dispositivi e sistemi di notifica.

I limiti di frequenza si applicano sia al traffico del bridge iframe instradato tramite Chastify sia alle chiamate backend effettuate con chiavi API per sviluppatori.

Benne di estensione attuali

SecchioLimiteEndpoint tipici
Lettura300/minsession.get, state.get, metadata.get, letture file, stato azione regolare
Scrittura120/minScrittura dello stato del backend, aggiornamenti dei metadati, configurazione delle azioni regolari, creazione di esecuzioni verificate dal server
Carica10/minCaricamento dei file di runtime e di installazione
Azione30/minBlocca azioni, comandi dispositivo, registri personalizzati, notifiche personalizzate, liquidazione dei risultati verificati dal server
Token30/minGenerazione del token di avvio/autenticazione della sessione Iframe

I limiti vengono valutati su un intervallo di un minuto.

note

Queste sono le impostazioni predefinite della piattaforma. Gli amministratori/proprietari del sito Chastify possono configurare delle eccezioni per singola estensione, sia per le estensioni ufficiali che per quelle con un volume di traffico insolitamente elevato. Le eccezioni vengono memorizzate nella configurazione dell'app dell'estensione e temporaneamente memorizzate nella cache di Redis per una rapida ricerca del percorso della richiesta.

informazioni

I bucket di caricamento e di azione sono intenzionalmente più ristretti rispetto ai bucket di lettura/stato. I caricamenti consumano spazio di archiviazione e larghezza di banda. Le azioni possono influire sullo stato di blocco, sui dispositivi, sulle notifiche e sulla cronologia visibile all'utente.

Come vengono contate le chiavi

Le chiavi per la limitazione della velocità includono:

  • ID utente Chastify autenticato quando l'interfaccia utente di prima parte chiama un endpoint
  • ID della chiave API dello sviluppatore quando il backend chiama gli endpoint della sessione di estensione
  • Indirizzo IP per percorsi anonimi o non autenticati
  • il target sessionId o lockId quando disponibile

Ciò significa che una singola sessione di estensione rumorosa non dovrebbe consumare l'intero budget globale dell'API di estensione.

Il tuo iframe o backend dovrebbe trattare 429 Too Many Requests come una normale condizione che consente di riprovare.

Utilizzare il backoff esponenziale per i guasti ripetuti:

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");
}

Guida al bridge Iframe

Per i client iframe bridge:

  • Memorizza nella cache i risultati di session.get per tutta la durata della pagina, a meno che non siano necessari nuovi dati di blocco.
  • Archivia localmente le modifiche temporanee all'interfaccia utente e invia le modifiche attendibili al tuo backend.
  • Evitate cicli di polling veloci. Preferite letture attivate dall'utente o intervalli di aggiornamento lenti.

Esempio di salvataggio backend con debounce:

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);
}

Guida all'estensione del backend

Per le chiamate al backend con una chiave API per sviluppatori:

  • Le azioni privilegiate devono essere verificate dal server e attivate dall'utente.
  • Utilizza PUT/PATCH /api/extensions/sessions/:sessionId/state esclusivamente dal tuo backend con le credenziali dell'API per sviluppatori.
  • Non riprovare le azioni di blocco alla cieca se il primo tentativo potrebbe essere andato a buon fine.
  • Rendi idempotente l'insediamento di gioco/sfida con un ID di esecuzione.
  • Carica i file solo quando l'utente li invia esplicitamente.
  • Se hai bisogno di telemetria ad alta frequenza, memorizza i tuoi dati esterni.
warning

Non aumentare mai i limiti delle azioni per compensare le chiamate del browser non verificate. Il codice iframe del browser non è considerato affidabile. Le mutazioni sensibili devono essere validate dal backend prima di chiamare Chastify.

Quale categoria devo aspettarmi?

Esempi comuni:

  • GET /api/extensions/sessions/:sessionId utilizza il bucket di lettura.
  • GET /api/extensions/sessions/:sessionId/state utilizza il bucket di lettura.
  • PUT/PATCH /api/extensions/sessions/:sessionId/state utilizza il bucket di scrittura.
  • POST /api/extensions/sessions/:sessionId/files utilizza il bucket di caricamento.
  • POST /api/extensions/sessions/:sessionId/action utilizza il bucket delle azioni.
  • POST /api/extensions/sessions/:sessionId/device-command utilizza il bucket delle azioni.
  • POST /api/extensions/sessions/:sessionId/logs/custom utilizza il bucket delle azioni.
  • POST /api/extensions/sessions/:sessionId/notifications/custom utilizza il bucket delle azioni.
  • GET /api/extensions/sessions/:sessionId/auth utilizza il bucket dei token.

Futuri secchi granulari

Le categorie attuali sono ampie. Chastify potrebbe suddividerle ulteriormente con la crescita dell'API per sviluppatori, ad esempio:

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

I limiti per singola estensione possono essere aumentati dagli amministratori/proprietari del sito Chastify quando un'estensione ufficiale o approvata ad alto volume ne ha una necessità legittima. Progettare i client in modo che la gestione di 429 sia generica e non dipenda da nomi di bucket specifici o impostazioni predefinite fisse della piattaforma.