Cómo superar las limitaciones de Firebase con un backend a medida exitoso.

Hace un tiempo os hablábamos sobre un proyecto que heredamos de L’illa Diagonal, el centro comercial de referencia en Barcelona, donde tienen una app para iOS y para Android. Este proyecto estaba implementado con Firebase como backend, tanto para la autenticación y la gestión de usuarios como para el almacenamiento de datos y archivos, así como para consultar y hacer operaciones de gestión. Cuando analizamos las necesidades reales del proyecto y las perspectivas de futuro, rápidamente vimos que era necesario replantear la estrategia tecnológica: continuar con Firebase o apostar por migrar hacia un backend a medida. En el artículo comparamos las diferentes opciones, valorando sus ventajas e inconvenientes, pero ahora os recogemos cuál fue nuestra decisión y cómo ha afectado actualmente al proyecto.

Desde el primer momento, y tras este análisis, decidimos migrar la base de datos y el sistema de archivos a un backend propio. Aunque esto supuso un esfuerzo inicial importante, muy pronto comprobamos que había sido la decisión acertada: el sistema se volvió más estable, coherente y fácil de gestionar. Ahora, después de más de un año trabajando intensamente y con una aplicación que no ha dejado de crecer en funcionalidades y requisitos, el backend a medida se ha consolidado como la pieza clave que nos ha permitido evolucionar el proyecto con garantías y flexibilidad. En este artículo recogemos cuáles fueron los puntos decisivos y cómo ha evolucionado el proyecto desde entonces.

Firebase Firestore + Cloud Functions vs PostgreSQL + Django

Cuando heredamos el código, una de las primeras cosas que detectamos fueron problemas graves de consistencia de datos. El esquema de la base de datos había cambiado varias veces, pero los datos no se habían migrado correctamente. Cada plataforma de la app utilizaba sus propios campos, muy similares entre sí, pero no idénticos. Otros sistemas externos escribían sin validar reglas de negocio e incluso había registros modificados manualmente por el cliente. El resultado era una base de datos desordenada, difícil de mantener y sin garantías de escalabilidad.

La situación se hizo aún más evidente cuando el cliente empezó a solicitar nuevas consultas y exportaciones para analizar los datos y utilizarlos en otras funcionalidades. El problema no era únicamente que los datos estuvieran desordenados, sino que ahora las necesidades requerían consultas complejas que debían ser muy rápidas. Aquí vimos las limitaciones de una base de datos no relacional como Firestore. Para poder incorporar estas nuevas funcionalidades y crecer, era imprescindible migrar a un sistema más robusto y eficiente.

El siguiente paso fue analizar a fondo las estructuras existentes y los procesos (Cloud Functions) que accedían a ellas para replicarlos en PostgreSQL y, al mismo tiempo, preparar la migración de todo el backend hacia Django. Fue un reto de gran envergadura, porque implicaba mantener en funcionamiento los sistemas conectados y las apps que ya estaban en los markets sin que el usuario final notara ninguna interrupción. Aun así, no era la primera vez que afrontábamos una migración así: la experiencia previa nos permitió hacerlo con confianza y seguridad.

Una vez finalizada la migración, el escenario cambió completamente. El nuevo backend nos proporcionó estabilidad: tanto Android como iOS utilizaban la misma información, todas las modificaciones quedaban validadas por las reglas de negocio y las consultas se resolvían de manera rápida y consistente.

Firebase vs panel de administración a medida

Firebase ofrece una herramienta para consultar, filtrar y visualizar datos, pero es genérica y bastante limitada: no se adaptaba a necesidades concretas ni a la operativa diaria del proyecto. El cliente tenía que copiar muchos datos a Excel para poder explotarlos o, a menudo, manipulaba esos datos sin ningún control, de manera que podía romper partes del sistema sin darse cuenta.

Para cubrir este problema, y como solución que aplicamos en la mayoría de proyectos, integramos un panel de administración web. Este panel es un producto propio que hemos ido desarrollando y mejorando a lo largo de los años, que utilizamos de manera transversal en diversos proyectos y que siempre adaptamos a las particularidades de cada cliente.

Nos permite generar listas con múltiples columnas, aplicar filtros y buscadores avanzados, añadir acciones y exportaciones o diseñar formularios para que los usuarios puedan consultar y gestionar datos con facilidad. Esto proporcionó al cliente una visión clara de la información que necesitaba y un control mucho más fino sobre su operativa diaria.

Durante este año lo hemos ido ampliando con nuevos campos, tablas y funcionalidades, al mismo tiempo que la aplicación móvil también crecía. El éxito de esta parte se ve cuando el cliente es capaz de tener el control de la información del proyecto y cómo le permite incorporar nuevas operativas para su día a día y nuevas funcionalidades para sus usuarios.

Firebase Authentication vs autenticación propia

En cuanto al sistema de autenticación, en este caso optamos por mantener Firebase Authentication. La razón es sencilla: ofrece una integración muy ágil con servicios como Google o Apple, así como mecanismos ya preparados para la validación de correo electrónico, SMS, recuperación de contraseña y otras funcionalidades básicas que habríamos tenido que reimplementar desde cero en un backend propio. Dado que esta parte ya resolvía bien las necesidades del proyecto y estaba plenamente integrada, no tenía sentido migrarla ni asumir el esfuerzo adicional que ello habría comportado.

Aun así, no la dejamos tal cual. El backend propio se conecta con Firebase Auth para poder aplicar reglas de negocio y controles específicos del dominio, asegurando que cualquier acción sobre la base de datos pase por nuestro sistema. De esta manera mantenemos la simplicidad y la potencia de Firebase Auth, pero sin perder el control centralizado de la lógica del proyecto.

Firebase Storage vs servidor propio

Otra parte importante de la migración del proyecto fue el sistema de archivos. En este caso, el peso de la decisión no fue solo técnico, sino también económico. Todos los archivos de la aplicación se encontraban en Firebase Storage, pero los objetivos del proyecto implicaban crecer de manera significativa en volumen de archivos, y esto planteaba un problema: a medida que aumentaba el uso, también lo hacía el coste del servicio. Este es uno de los inconvenientes de utilizar un backend as a service: quedas ligado al producto y el presupuesto del proyecto depende directamente de la evolución de los precios del proveedor.

Para solucionarlo, migramos el sistema a un servidor propio en la nube, donde pudimos definir nuestra propia estructura de organización y aplicar políticas específicas de seguridad y permisos, adaptadas a las necesidades del cliente. Esto nos permitió reducir notablemente el coste, ganar un control total sobre los archivos y las operaciones de gestión de los mismos.

Otra ventaja de disponer de un sistema propio es la integración con el resto del backend: los archivos ya no son un elemento aislado gestionado por un tercero, sino que forman parte de la misma lógica del sistema. Esto facilita la consistencia con el resto de datos y asegura que cada archivo esté correctamente vinculado a su información correspondiente.

Conclusiones

Después de un año, la migración a un backend a medida nos aportó estabilidad y coherencia. El panel de administración propio dio más control y visibilidad. Firebase Auth se mantuvo, pero integrado con el backend para aplicar la lógica de negocio y reforzar las reglas del sistema. Finalmente, la gestión de archivos en servidor propio redujo costes y añadió flexibilidad. Ahora trabajamos en un proyecto mucho más maduro y con un nivel de calidad técnica que nos hace sentir cómodos y confiados de cara al futuro.

Es cierto que plataformas como Firebase simplifican el trabajo del desarrollador y permiten olvidarse de muchas tareas de infraestructura. Pero en nuestro caso, esto no es un obstáculo: la experiencia acumulada en el desarrollo de apps y software a lo largo de los años, el hecho de que la mayoría de proyectos ya sigan una arquitectura bien definida y coherente, y la disponibilidad de herramientas y productos internos preparados para integrarse y adaptarse fácilmente, hacen que el desarrollo de un backend a medida sea una opción aún más sólida.

Todo esto nos permite ofrecer soluciones robustas, escalables y adaptadas a las necesidades reales de cada proyecto, sin las limitaciones ni dependencias de un BaaS. La elección de las soluciones técnicas más adecuadas parte de entender bien las necesidades y retos de los clientes y de saber traducirlos en soluciones sólidas y flexibles que aseguren la evolución y el éxito del proyecto a lo largo del tiempo. Este enfoque genera la confianza necesaria para acompañar a los clientes en su camino tecnológico.