Com superar les limitacions de Firebase amb un backend a mida d’èxit.

Fa un temps us parlàvem sobre un projecte que vam heretar de L’illa Diagonal, el centre comercial de referència a Barcelona, on tenen una app per iOS i per Android. Aquest projecte estava implementat amb Firebase com a backend, tant per a l’autenticació i la gestió d’usuaris com per a l’emmagatzematge de dades i fitxers, com per a consultar i fer operacions de gestió. Quan vam analitzar les necessitats reals del projecte i les perspectives de futur, ràpidament vam veure que calia replantejar l’estratègia tecnològica: continuar amb Firebase o apostar per migrar cap a un backend a mida. En l’article vam comparar les diferents opcions, valorant-ne els avantatges i inconvenients, però ara us recollim quina va ser la nostra decisió i com ha afectat actualment al projecte.

Des del primer moment, i després d’aquesta anàlisi, vam decidir migrar la base de dades i el sistema de fitxers a un backend propi. Tot i que això va suposar un esforç inicial important, molt aviat vam comprovar que havia estat la decisió encertada: el sistema es va tornar més estable, coherent i fàcil de gestionar. Ara, després de més d’un any treballant-hi intensament i amb una aplicació que no ha parat de créixer en funcionalitats i requisits, el backend a mida s’ha consolidat com la peça clau que ens ha permès evolucionar el projecte amb garanties i flexibilitat. En aquest article recollim quins van ser els punts decisius i com ha evolucionat el projecte des d’aleshores.

Firebase Firestore + Cloud Functions vs PostgreSQL + Django

Quan vam heretar el codi, una de les primeres coses que vam detectar van ser problemes greus de consistència de dades. L’esquema de la base de dades havia canviat diverses vegades, però les dades no s’havien migrat correctament. Cada plataforma de l’app utilitzava els seus propis camps, molt semblants entre ells, però no els mateixos. Altres sistemes externs escrivien sense validar regles de negoci i, fins i tot, hi havia registres modificats manualment pel client. El resultat era una base de dades desendreçada, difícil de mantenir i sense garanties d’escalabilitat.

La situació es va fer encara més evident quan el client va començar a demanar noves consultes, i exportacions per analitzar les dades i utilitzar-les per altres funcionalitats. El problema no era únicament que les dades estiguessin desendreçades, sinó que ara les necessitats requerien consultes complexes que havien de ser molt ràpides. Aquí vam veure les limitacions d’una base de dades no relacional com Firestore. Per poder incorporar aquestes noves funcionalitats i créixer, era imprescindible migrar a un sistema més robust i eficient.

El pas següent va ser analitzar a fons les estructures existents i els processos (Cloud Functions) que hi accedien per replicar-los en PostgreSQL i, al mateix temps, preparar la migració de tot el backend cap a Django. Era un repte de gran envergadura, perquè implicava mantenir en marxa els sistemes connectats i les apps que ja estaven als markets sense que l’usuari final notés cap interrupció. Tot i això, no era la primera vegada que afrontàvem una migració així: l’experiència prèvia ens va permetre fer-ho amb confiança i seguretat.

Un cop finalitzada la migració, l’escenari va canviar completament. El nou backend ens va donar estabilitat, tant Android com iOS utilitzaven la mateixa informació, totes les modificacions quedaven validades per les regles de negoci i les consultes es resolien de manera ràpida i consistent.

Firebase vs panel de administración a medida

Firebase ofereix una eina per consultar, filtrar i visualitzar dades, però és genèrica i força limitada: no s’adaptava a necessitats concretes ni a l’operativa diària del projecte. El client havia de copiar moltes dades a Excel per poder-les explotar o sovint manipulava aquestes dades sense cap control de manera que podia trencar parts del sistema sense adonar-se.

Per cobrir aquest problema, i es una solució que apliquem a la majoria de projectes, vam integrar un panell d’administració web. Aquest panell és un producte propi que hem anat desenvolupant i millorant al llarg dels anys, que fem servir de manera transversal en diversos projectes i que sempre adaptem a les particularitats de cada client.

Ens permet generar llistes amb múltiples columnes, aplicar filtres i cercadors avançats, afegir accions i exportacions o dissenyar formularis perquè els usuaris puguin consultar i gestionar dades amb facilitat. Això va donar al client una visió clara de la informació que necessitava i un control molt més fi sobre la seva operativa diària.

Durant aquest any l’hem anat ampliant amb nous camps, taules i funcionalitats, a la vegada que l’aplicació mòbil també creixia. L’èxit d’aquest part la veiem quan el client és capaç de tenir el control de la informació del projecte i com li permet incorporar noves operatives per al seu dia a dia i noves funcionalitats pels seus usuaris.

Firebase Authentication vs autenticació pròpia

Pel que fa al sistema d’autenticació, en aquest cas vam optar per mantenir Firebase Authentication. La raó és senzilla: ofereix una integració molt àgil amb serveis com Google o Apple, així com mecanismes ja preparats per a la validació de correu electrònic, SMS, recuperació de contrasenya i altres funcionalitats bàsiques que hauríem hagut de reimplementar des de zero en un backend propi. Com que aquesta part ja resolia bé les necessitats del projecte i estava plenament integrada, no tenia sentit migrar-la ni assumir l’esforç addicional que hauria comportat.

Tot i així, no vam deixar-ho tal qual. El backend propi es connecta amb Firebase Auth per poder aplicar regles de negoci i controls específics del domini, assegurant que qualsevol acció sobre la base de dades passi pel nostre sistema. D’aquesta manera mantenim la simplicitat i la potència de Firebase Auth, però sense perdre el control centralitzat de la lògica del projecte.

Firebase Storage vs servidor propi

Una altra part important de la migració del projecte va ser el sistema de fitxers. En aquest cas, el pes de la decisió no va ser només tècnic, sinó també econòmic. Tots els fitxers de l’aplicació es trobaven a Firebase Storage, però els objectius del projecte implicaven créixer de manera significativa en volum de fitxers, i això plantejava un problema: a mesura que augmentava l’ús, també ho feia el cost del servei. Aquest és un dels inconvenients d’utilitzar un backend as a service: quedes lligat al producte i el pressupost del projecte depèn directament de l’evolució dels preus del proveïdor.

Per resoldre-ho, vam migrar el sistema a un servidor propi al cloud. On vam poder definir la nostra pròpia estructura d’organització i aplicar polítiques específiques de seguretat i permisos, adaptades a les necessitats del client. Això ens va permetre reduir notablement el cost, guanyar un control total sobre els fitxers i les operacions de gestió dels fitxers.

Un altre avantatge de disposar d’un sistema propi és la integració amb la resta del backend: els fitxers ja no són un element aïllat gestionat per un tercer, sinó que formen part de la mateixa lògica del sistema. Això facilita la consistència amb la resta de dades i assegura que cada arxiu estigui correctament vinculat a la seva informació corresponent.

Conclusions

Després d’un any, la migració a un backend a mida ens va aportar estabilitat i coherència. El panell d’administració propi va donar més control i visibilitat. Firebase Auth es va mantenir, però integrat amb el backend per aplicar la lògica de negoci i reforçar les regles del sistema. Finalment, la gestió de fitxers en servidor propi va reduir costos i va afegir flexibilitat. Ara treballem en un projecte molt més madur i amb un nivell de qualitat tècnica que ens fa sentir còmodes i confiats de cara al futur.

És cert que plataformes com Firebase simplifiquen la feina del desenvolupador i permeten oblidar-se de moltes tasques d’infraestructura. Però en el nostre cas això no és un obstacle: l’experiència acumulada en el desenvolupament d’apps i software al llarg dels anys, el fet que la majoria de projectes ja segueixin una arquitectura ben definida i coherent, i la disponibilitat d’eines i productes interns preparats per integrar-se i adaptar-se fàcilment, fan que el desenvolupament d’un backend a mida sigui una opció encara més sòlida. Tot plegat ens permet oferir solucions robustes, escalables i adaptades a les necessitats reals de cada projecte, sense les limitacions ni dependències d’un BaaS.

El fet d’escollir les solucions tècniques més adequades parteix d’entendre bé les necessitats i reptes dels clients, i de saber traduir-los en solucions sòlides i flexibles que assegurin l’evolució i l’èxit del projecte al llarg del temps. Aquest enfocament acaba generant la confiança necessària per acompanyar els clients en el seu camí tecnològic.