¿Cómo gestionáis los datos en Firebase en proyectos para clientes?

Una duda para los que trabajáis con clientes y usáis Firebase.

¿Cómo gestionáis los datos? ¿Tiráis de la consola o acabáis montando paneles de administración a medida en cada proyecto?

Lo pregunto porque me he visto ya varias veces repitiendo lo mismo, y la verdad es que es bastante coñazo tener que montar algo ad hoc cada vez solo para poder gestionar los datos cómodamente.

Al final me dio por montar un plugin en WordPress para gestionar Firestore desde ahí y no tener que rehacer todo cada vez. Os dejo por aquí el enlace por si alguien quiere echarle un ojo:
👉 https://wordpress.org/plugins/backoffice-manager-for-firebase/

Pero no tengo claro si esto es algo que realmente os pasa o solo me estoy liando yo 😅

Si alguno trabaja con Firebase en proyectos reales, me vendría genial saber cómo lo estáis resolviendo.

Suelo trabajar directamente en consola, igual no me pasa o no son tantas las modificaciones que hago que no había pensado en esto

Exactamente que problema estas teniendo con los datos? Entiendo que montas muchos dashboards pero no logro comprender si el problema es del montaje de los datos o los datos en si

En mi caso viene más por experiencia propia que por un problema puntual.

He lanzado un par de apps con Firebase y, sobre todo en una de ellas, la gestión de datos se ha ido complicando bastante. La montamos directamente sobre la consola de Firebase y, a medida que crecía, hacer cambios, gestionar contenido o tocar usuarios se volvió bastante incómodo,. sobretodo porque mi amigo (que no es dev), y por falta de tiempo mío, tuvo q hacerse cargo de los datos y acabó liándola.

Como solución, al final terminé creando pequeñas webs internas para gestionar la base de datos (listados, CRUD, usuarios, etc.) con restricciones en la entrada de datos, pero es algo que ya he hecho dos veces y me da la sensación de que estoy repitiendo siempre lo mismo.

Por eso estoy explorando si ese proceso se puede simplificar con algo más genérico que puedas montar rápido sin tener que desarrollar todo desde cero cada vez.

Una de las ideas que estoy probando es apoyarme en WordPress, que al final ya te da todo el frontend y la gestión de usuarios bastante resuelta, y puede encajar bien sobre todo para perfiles menos técnicos.

No se, ¿qué opináis?

Shurwebs dijo:

En mi caso viene más por experiencia propia que por un problema puntual.

He lanzado un par de apps con Firebase y, sobre todo en una de ellas, la gestión de datos se ha ido complicando bastante. La montamos directamente sobre la consola de Firebase y, a medida que crecía, hacer cambios, gestionar contenido o tocar usuarios se volvió bastante incómodo,. sobretodo porque mi amigo (que no es dev), y por falta de tiempo mío, tuvo q hacerse cargo de los datos y acabó liándola.

Como solución, al final terminé creando pequeñas webs internas para gestionar la base de datos (listados, CRUD, usuarios, etc.) con restricciones en la entrada de datos, pero es algo que ya he hecho dos veces y me da la sensación de que estoy repitiendo siempre lo mismo.

Por eso estoy explorando si ese proceso se puede simplificar con algo más genérico que puedas montar rápido sin tener que desarrollar todo desde cero cada vez.

Una de las ideas que estoy probando es apoyarme en WordPress, que al final ya te da todo el frontend y la gestión de usuarios bastante resuelta, y puede encajar bien sobre todo para perfiles menos técnicos.

No se, ¿qué opináis?

Hacer clic para expandir...

Si el problema real es que tu amigo necesita gestionar la info sin liarla, FireCMS es una solución, y es lo que probaría primero.

Si quieres resolver el problema más general de no volver a construir un admin desde cero nunca más, Refine es la herramienta ideal y aprovechando que ya dominas React.

WordPress lo dejaría solo para proyectos donde el producto en sí sea contenido editorial (blog, landings, e-commerce con WooCommerce). Para backoffice de una app mobile/web, es introducir un stack entero que no te aporta.

jzambrano12 dijo:

Si el problema real es que tu amigo necesita gestionar la info sin liarla, FireCMS es una solución, y es lo que probaría primero.

Si quieres resolver el problema más general de no volver a construir un admin desde cero nunca más, Refine es la herramienta ideal y aprovechando que ya dominas React.

WordPress lo dejaría solo para proyectos donde el producto en sí sea contenido editorial (blog, landings, e-commerce con WooCommerce). Para backoffice de una app mobile/web, es introducir un stack entero que no te aporta.

Hacer clic para expandir...

Tiene sentido, gracias por las recomendaciones — les echo un ojo.

Y sí, justo ese es el caso que estoy viendo: gente no técnica que necesita gestionar datos sin liarla.

En mi caso he acabado montando pequeños paneles varias veces solo para eso, y estoy intentando ver si hay una forma más simple de resolverlo sin tener que rehacer lo mismo cada vez.

No sos el único, eso pasa todo el tiempo con Firebase. La consola sirve para cosas puntuales, pero en cuanto el proyecto crece o el cliente quiere tocar datos sin romper nada se queda cortísima.

Lo más común que vas a ver es que al principio todos tiran de consola, pero en proyectos reales casi siempre terminan armando algún tipo de backoffice. A veces es algo simple y rápido, otras veces un panel más completo según el cliente. El problema es justo el que decís, terminás rehaciendo lo mismo mil veces.

Hay varios enfoques que se suelen usar. Algunos se arman un template interno de admin y lo reutilizan en todos los proyectos, cambiando solo las colecciones y reglas. Otros usan herramientas tipo Retool, Appsmith o similares para no codear todo desde cero. Y después está la opción que hiciste vos, que es abstraerlo en una herramienta propia o plugin, que de hecho es bastante lógica si ya te cansaste de repetir.

Tu idea tiene sentido, sobre todo si apuntás a gente que trabaja con WordPress o clientes que ya están cómodos ahí. El punto clave es ver si resolvés algo más allá de “evitar hacer el panel”, por ejemplo control de permisos, validaciones, edición segura de datos, logs, etc. Ahí es donde realmente suma valor.

En resumen, no te estás liando, es un problema bastante común. Lo que cambia es cómo cada uno lo resuelve según el tipo de cliente y el stack que maneja, pero casi nadie se queda solo con la consola cuando escala un poco.

Justo por eso seguí tirando del hilo estas semanas 😅

Al final terminé convirtiéndolo en plugin y lo publiqué en el repo de WordPress para probar si el problema resonaba también fuera de mis proyectos:


Todavía está muy early y sigo iterando bastante (sobre todo onboarding/permisos/UX), pero me está sirviendo justo para validar si realmente este pain es tan común como parecía o solo era cosa mía.

Y sinceramente, viendo varias respuestas como la tuya, parece que no soy el único que acabó rehaciendo el mismo backoffice varias veces.

Al final siempre terminas en el mismo dilema con Firebase porque aunque la consola oficial es potente para nosotros los desarrolladores, a un cliente no le puedes soltar ahí dentro ni loco, es un peligro y no entienden nada, en mi experiencia montar un panel de administración a medida desde cero para cada proyecto es un auténtico dolor de cabeza y consume un tiempo tremendo que casi nunca se presupuesta bien por eso me parece un acierto brutal la idea de conectar Firestore con WordPress mediante un plugin

Sí pasa bastante. La consola de Firebase sirve para desarrollo o revisiones puntuales, pero para cliente final se queda corta rápido.

En proyectos reales suelo separar 3 casos:

1. Datos operativos simples
   Si el cliente solo necesita editar textos, estados, categorías, usuarios o registros básicos, prefiero montar un panel pequeño o reutilizar un backoffice existente.
2. Datos sensibles o con lógica de negocio
   Aquí no dejaría al cliente tocar Firestore directamente desde la consola. Es fácil romper estructura, borrar campos o saltarse validaciones. Mejor un panel con formularios controlados, roles y validación.
3. Proyectos que van a crecer
   Ahí intentaría no repetir paneles ad hoc. Tiene sentido tener una base reutilizable: CRUD genérico, roles, logs, filtros, exportación y permisos por colección.

Lo de gestionarlo desde WordPress puede tener sentido si el cliente ya usa WP y está cómodo ahí. Firestore es muy flexible y eso mismo puede ser peligroso cuando lo toca alguien no técnico.

cristhian1a dijo:

Al final siempre terminas en el mismo dilema con Firebase porque aunque la consola oficial es potente para nosotros los desarrolladores, a un cliente no le puedes soltar ahí dentro ni loco, es un peligro y no entienden nada, en mi experiencia montar un panel de administración a medida desde cero para cada proyecto es un auténtico dolor de cabeza y consume un tiempo tremendo que casi nunca se presupuesta bien por eso me parece un acierto brutal la idea de conectar Firestore con WordPress mediante un plugin

Hacer clic para expandir...

alej_vid dijo:

Sí pasa bastante. La consola de Firebase sirve para desarrollo o revisiones puntuales, pero para cliente final se queda corta rápido.

En proyectos reales suelo separar 3 casos:

1. Datos operativos simples
   Si el cliente solo necesita editar textos, estados, categorías, usuarios o registros básicos, prefiero montar un panel pequeño o reutilizar un backoffice existente.
2. Datos sensibles o con lógica de negocio
   Aquí no dejaría al cliente tocar Firestore directamente desde la consola. Es fácil romper estructura, borrar campos o saltarse validaciones. Mejor un panel con formularios controlados, roles y validación.
3. Proyectos que van a crecer
   Ahí intentaría no repetir paneles ad hoc. Tiene sentido tener una base reutilizable: CRUD genérico, roles, logs, filtros, exportación y permisos por colección.

Lo de gestionarlo desde WordPress puede tener sentido si el cliente ya usa WP y está cómodo ahí. Firestore es muy flexible y eso mismo puede ser peligroso cuando lo toca alguien no técnico.

Hacer clic para expandir...

Justamente esa era la idea detrás del plugin: que usuarios no técnicos puedan gestionar los datos sin tocar Firestore en crudo.

La consola de Firebase está muy bien para nosotros como desarrolladores, pero no me imagino dejando ahí a un cliente. Es demasiado fácil borrar algo que no toca, modificar una estructura o simplemente perderse entre colecciones.

Ahora mismo el plugin permite navegar y modificar documentos desde WordPress de forma bastante más controlada, pero estoy dándole vueltas a un paso más.

Una idea que tengo es permitir crear CPTs a partir de colecciones de Firestore, de forma que para el usuario final sea prácticamente transparente. Es decir, que edite documentos como si fueran entradas normales de WordPress, con sus campos, permisos y flujo habitual.

No tengo claro todavía si es una buena idea o si acabaría complicando demasiado el producto.

¿Lo veis útil? ¿Hay alguna otra funcionalidad que echaríais de menos?

Se me ocurren cosas como gestión de Storage, FCM, importación/exportación, permisos por colección, etc., pero prefiero escuchar primero qué os haría realmente falta en proyectos reales.

Por ahora estoy tirando de necesidades propias, pero la verdad es que me vendrían fenomenal otras opiniones.