Come evitare bollette a sorpresa su Firebase: una checklist

Firebase ha una pagina intitolata Avoid surprise bills. È un buon punto di partenza e copre tre cose: testare il codice, tenere d'occhio l'uso, impostare i budget. Qui sotto trovi lo stesso percorso come checklist, nello stesso ordine, con ciò che ogni passo lascia aperto e i passi che la pagina non menziona.

Una cosa da tenere a mente fin dall'inizio: "Firebase pricing plans apply to the entire project, not just to individual apps registered in the project." (i piani tariffari di Firebase si applicano all'intero progetto, non solo alle singole app registrate). Ogni app del progetto (web, iOS, Android, una build di test puntata sulla produzione) si somma alla stessa bolletta.

Google consiglia la Local Emulator Suite, che esegue Firestore, Cloud Functions, Realtime Database e altro sulla tua macchina, così che "you don't incur any Firebase costs that might result from testing against services in production" (tu non abbia costi Firebase dovuti ai test sui servizi di produzione). Durante i test, indica due schemi da tenere d'occhio:

• "Forgetting to add a limit to a database query with millions of results" (dimenticare un limite su una query con milioni di risultati)
• "Combinations of Cloud Functions that cause excessive fan-out workloads or even infinite loops" (combinazioni di Cloud Functions che causano un fan-out eccessivo o persino loop infiniti)

Cosa resta aperto: l'emulatore mostra cosa fa il tuo codice, non cosa ne faranno utenti reali o uno sconosciuto. Non vede un listener che si riabbona a ogni schermata dell'app vera, né un bot che chiama la tua funzione. Per gli schemi di lettura che sfuggono ai test, vedi come trovare cosa sta leggendo il tuo Firestore.

Il secondo passo di Google: "You need to know what normal usage patterns look like for your app" (devi sapere com'è l'uso normale della tua app). Ogni prodotto ha una scheda Usage nella console Firebase, e Settings, Usage and billing mostra l'intero progetto rispetto alla quota gratuita.

Due precisazioni. I numeri si aggiornano con ritmi diversi: "Cloud Firestore and Cloud Storage usage are calculated daily" (l'uso di Firestore e Storage è calcolato ogni giorno) e "Cloud Functions usage is calculated monthly" (quello di Cloud Functions ogni mese). E la dashboard di Firestore è una stima: "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (la dashboard non è una vista esatta delle operazioni fatturate, e l'uso fatturato è probabilmente più alto) (documentazione sull'uso di Firestore).

Cosa resta aperto: qualcuno deve guardare. Una dashboard mostra il picco a chi la apre, e alle 3 di notte nessuno la apre. Se la bolletta è già più alta del previsto, come trovare cosa ti viene addebitato percorre i report di fatturazione fino allo SKU e al giorno.

Passando a Blaze, Firebase ti chiede di creare un budget. Fallo, ma sappi cos'è: "Budget alerts do not pause services." (gli avvisi di budget non mettono in pausa i servizi). Esistono "so that you can take action, if needed" (perché tu possa intervenire, se serve).

Cosa resta aperto: l'avviso arriva ore dopo la spesa, e qualcuno deve comunque intervenire. Il perché, con le parole di Google: perché gli avvisi di budget non fermano la bolletta.

I budget con spend cap sono l'opzione più recente: quando un servizio raggiunge il 100% del budget, Cloud Billing "pauses that service for the rest of the month" (mette in pausa quel servizio per il resto del mese). Coprono solo Firebase AI Logic, App Hosting, Cloud Functions for Firebase ed Extensions.

Cosa resta aperto: Firestore, Realtime Database, Cloud Storage e Hosting non sono coperti. E Google avverte: "Spend caps are not "hard caps"." (gli spend cap non sono «limiti rigidi»). L'applicazione "can be delayed by several minutes" (può ritardare di diversi minuti), e ciò che si spende in quell'intervallo viene fatturato normalmente.

La pagina di Google parla di tenere d'occhio i costi. La maggior parte delle bollette a cinque cifre delle nostre storie dell'orrore è arrivata da altrove: qualcosa fuori dall'app che chiamava servizi a pagamento. Tre cose da fare prima del lancio:

• Limita le tue chiavi API. Limita ogni chiave alle API e alle app che ne hanno bisogno, e tieni la Gemini API fuori da qualsiasi chiave distribuita nella tua app: come limitare una chiave API Firebase.
• Attiva App Check e regole di sicurezza rigorose. Così solo la tua app raggiunge il database e le funzioni callable: attacchi denial of wallet.
• Limita le istanze delle tue funzioni. Una funzione fuori controllo costa di più quante più istanze ottiene. Imposta un massimo: come limitare la spesa su Firebase.

La pagina di Google va nella stessa direzione: suggerisce di usare le notifiche di budget per disattivare la fatturazione del progetto. Puoi costruirlo da solo con una funzione sul topic Pub/Sub del budget (guida passo passo), ma leggi prima cosa succede quando la fatturazione si ferma: spegne tutti i servizi a pagamento del progetto.

Oppure lascia fare a FireShield. Agisce su ogni notifica di budget appena arriva, può inviare un webhook di Soft Kill perché la tua app si degradi da sola prima che la fatturazione venga staccata, e su Pro sorveglia l'uso di ogni servizio in cerca di picchi, così una spesa fuori controllo emerge entro l'ora e non nel prossimo report dei costi.

1. Testa nella Local Emulator Suite, con un limite su ogni query.
2. Conosci il tuo uso normale per prodotto, e controllalo dopo ogni release.
3. Crea un budget, sapendo che invia solo avvisi.
4. Attiva gli spend cap per AI Logic, App Hosting, Cloud Functions ed Extensions.
5. Limita le chiavi API, attiva App Check, limita le istanze delle funzioni.
6. Collega qualcosa che agisca sul budget senza aspettare una persona.