Firebase în producție: ce folosim, ce evităm și lecțiile care dor

Aproape tot ce livrăm — site-uri, jocuri, aplicații cu conturi și plăți — rulează pe Firebase: hosting multi-site, Authentication, Realtime Database, Firestore, Cloud Functions, Remote Config. Nu pentru că Firebase ar fi perfect, ci pentru că pentru un studio mic raportul dintre ce primești și ce administrezi rămâne imbatabil. Articolul acesta e lista de lecții pe care le-am plătit cu incidente reale — inclusiv una în care un deploy aparent nevinovat a șters o funcție din producție.

Lecția 1: deploy-urile de funcții se fac țintit, întotdeauna

Incidentul care ne-a schimbat procedurile: două site-uri diferite împart același proiect Firebase, iar funcțiile lor trăiesc în codebase-uri separate. Un coleg a rulat un banal firebase deploy --only functions dintr-unul din repo-uri. Firebase a interpretat comanda ca „starea completă dorită a funcțiilor" și a șters funcția de submitere a formularului de contact care aparținea celuilalt site. Fără eroare, fără avertisment vizibil — formularul de contact a murit în tăcere.

Regula de atunci, scrisă în documentația internă cu majuscule: niciodată --only functions, întotdeauna --only functions:numeFunctie. Și, complementar: emulatorul rulează suita completă de teste înainte de orice deploy de funcții. Costul respectării regulii: câteva secunde per deploy. Costul încălcării ei: un formular mort până observă cineva.

Lecția 2: serverul e singura sursă de adevăr pentru bani

În jocurile noastre există o economie de jetoane: jucătorii cumpără pachete, deblochează personaje, primesc recompense. Prima versiune ținea prețurile în clientul jocului. A doua versiune — cea corectă — le ține exclusiv în configurația funcțiilor de pe server: clientul trimite doar id-uri („vreau să deblochez suit:aegis"), serverul decide prețul, verifică soldul și scrie tranzacția idempotent.

Motivul e simplu: tot ce e în client e editabil de utilizator. Orice preț, orice validare, orice „are deja acest item" verificat doar în client e o invitație. Aceeași regulă se aplică la webhook-uri de plăți: idempotente (același eveniment primit de două ori nu creditează de două ori) și fail-closed (orice dubiu înseamnă refuz, nu acceptare).

Lecția 3: Remote Config e mai valoros decât pare

Două utilizări care ne-au scutit de release-uri de urgență:

Maintenance mode pentru web. Un flag în Remote Config, citit cu realtime updates, cu comportament fail-open: dacă configul nu se poate încărca, site-ul rămâne funcțional. Putem pune orice produs în mentenanță în secunde, fără deploy.
Versiune minimă pentru aplicațiile native. Gate-ul de versiune („aplicația ta e prea veche, actualizează") e condus din Remote Config, nu hardcodat. Când o versiune veche are un bug serios, o blocăm de la distanță — fără să așteptăm review-ul din store.

Lecția 4: regulile de securitate sunt produsul, nu o anexă

Realtime Database și Firestore îți expun datele direct către clienți — singura barieră sunt regulile. Practicile care ne-au rămas după un audit intern:

Regulile se scriu deny-by-default: nimic nu e citibil sau scriibil până nu există un motiv explicit.
Regulile au teste automate (rulate pe emulator) exact ca orice alt cod. O regulă fără test e o regulă care se va strica la următoarea modificare.
Token-urile de identitate nu au ce căuta în URL-uri (ajung în log-uri); SDK-ul le trimite corect în headere.
Datele sensibile nu se ating din client nici măcar „doar la citire" — trec prin funcții care aplică logica de autorizare pe server.

Lecția 5: hosting-ul are detalii care se văd în SEO și în viteză

cleanUrls + redirect-uri 301 din prima zi — altfel acumulezi și /pagina.html și /pagina în index, cu tot cu conținut duplicat.
Cache diferențiat pe tip de fișier: HTML cu no-cache (se validează la fiecare request), CSS/JS cu max-age scurt și cache-busting prin query de versiune, imagini cu max-age lung. Ne-a scăpat de clasicul „am dat deploy dar utilizatorii văd versiunea veche".
Multi-site în același proiect funcționează bine (site-ul principal, subdomeniul de jocuri și alte produse împart proiectul), dar cere țintire explicită la deploy — vezi Lecția 1, care se aplică identic la hosting: --only hosting:numeSite.

Ce evităm conștient

Logică de business în client — orice atinge bani, solduri sau permisiuni stă în funcții.
Funcții „la grămadă" — funcțiile multor produse în același codebase fără separare clară; e rețeta incidentului de la Lecția 1.
Dependența de un singur mediu — totul trebuie să ruleze și pe emulator; dacă un flux se poate testa doar în producție, fluxul e prost proiectat.
Optimizarea prematură a costurilor — free tier-ul și blaze-ul la volum mic sunt generoase; ne uităm la facturi lunar, nu ne arhitecturăm după ele din prima zi.

Concluzie

Firebase rămâne alegerea noastră implicită pentru produse noi: viteza de la idee la producție e reală. Dar „backend-as-a-service" nu înseamnă „backend fără disciplină" — înseamnă că disciplina se mută în reguli de securitate testate, deploy-uri țintite, configurare la distanță și o graniță fermă între ce decide clientul și ce decide serverul. Toate lecțiile de mai sus au costat ceva când le-am învățat; sperăm că citite gratis dor mai puțin.

Construiești pe Firebase și vrei o a doua opinie pe arhitectură? Scrie-ne la contact@hashcoreai.com.

Almost everything we ship — websites, games, apps with accounts and payments — runs on Firebase: multi-site hosting, Authentication, Realtime Database, Firestore, Cloud Functions, Remote Config. Not because Firebase is perfect, but because for a small studio the ratio between what you get and what you have to administer remains unbeatable. This article is the list of lessons we paid for with real incidents — including one where a seemingly innocent deploy deleted a production function.

Lesson 1: function deploys are targeted, always

The incident that changed our procedures: two different sites share the same Firebase project, and their functions live in separate codebases. A colleague ran an innocuous firebase deploy --only functions from one of the repos. Firebase interpreted the command as "the complete desired state of functions" and deleted the contact form submission function that belonged to the other site. No error, no visible warning — the contact form died silently.

The rule since then, written in our internal docs in capital letters: never --only functions, always --only functions:functionName. And, complementary to it: the emulator runs the full test suite before any function deploy. The cost of following the rule: a few seconds per deploy. The cost of breaking it: a dead form until someone notices.

Lesson 2: the server is the only source of truth for money

Our games have a token economy: players buy packs, unlock characters, receive rewards. The first version kept prices in the game client. The second version — the correct one — keeps them exclusively in the server-side function configuration: the client only sends ids ("I want to unlock suit:aegis"), the server decides the price, checks the balance and writes the transaction idempotently.

The reason is simple: everything in the client is editable by the user. Any price, any validation, any "already owns this item" checked only client-side is an invitation. The same rule applies to payment webhooks: idempotent (the same event received twice doesn't credit twice) and fail-closed (any doubt means refusal, not acceptance).

Lesson 3: Remote Config is more valuable than it looks

Two uses that have saved us from emergency releases:

Maintenance mode for the web. A Remote Config flag, read with realtime updates, with fail-open behaviour: if the config can't load, the site stays up. We can put any product into maintenance in seconds, without a deploy.
Minimum version for native apps. The version gate ("your app is too old, please update") is driven from Remote Config, not hardcoded. When an old version has a serious bug, we block it remotely — without waiting for store review.

Lesson 4: security rules are the product, not an appendix

Realtime Database and Firestore expose your data directly to clients — the rules are the only barrier. The practices that stuck after an internal audit:

Rules are written deny-by-default: nothing is readable or writable until there's an explicit reason.
Rules have automated tests (run on the emulator) just like any other code. An untested rule is a rule that will break on the next change.
Identity tokens don't belong in URLs (they end up in logs); the SDK sends them correctly in headers.
Sensitive data isn't touched from the client even "just for reading" — it goes through functions that apply authorisation logic on the server.

Lesson 5: hosting has details that show up in SEO and speed

cleanUrls + 301 redirects from day one — otherwise you accumulate both /page.html and /page in the index, duplicate content included.
Per-file-type caching: HTML with no-cache (validated on every request), CSS/JS with a short max-age plus version-query cache-busting, images with a long max-age. It cured the classic "we deployed but users see the old version."
Multi-site in one project works well (the main site, the games subdomain and other products share the project), but it demands explicit targeting on deploy — see Lesson 1, which applies identically to hosting: --only hosting:siteName.

What we consciously avoid

Business logic in the client — anything touching money, balances or permissions lives in functions.
Piled-up functions — many products' functions in one codebase without clear separation; that's the recipe for Lesson 1's incident.
Depending on a single environment — everything must also run on the emulator; if a flow can only be tested in production, the flow is badly designed.
Premature cost optimisation — the free tier and low-volume Blaze are generous; we review bills monthly rather than architecting around them from day one.

Conclusion

Firebase remains our default choice for new products: the speed from idea to production is real. But "backend-as-a-service" doesn't mean "backend without discipline" — it means the discipline moves into tested security rules, targeted deploys, remote configuration, and a firm boundary between what the client decides and what the server decides. Every lesson above cost something when we learned it; we hope that read for free, it hurts less.

Building on Firebase and want a second opinion on your architecture? Write to us at contact@hashcoreai.com.