Como vocês gerenciam dados no Firebase em projetos para clientes?

Uma dúvida para os que trabalham com clientes e usam Firebase.

Como vocês gerenciam os dados? Usam o console ou acabam montando painéis de administração sob medida em cada projeto?

Pergunto porque já me vi várias vezes repetindo a mesma coisa, e a verdade é que é bastante chato ter que montar algo ad hoc toda vez só para poder gerenciar os dados confortavelmente.

No final, resolvi montar um plugin no WordPress para gerenciar o Firestore a partir de lá e não ter que refazer tudo toda vez. Deixo aqui o link caso alguém queira dar uma olhada:
👉 https://wordpress.org/plugins/backoffice-manager-for-firebase/

Mas não tenho certeza se isso é algo que realmente acontece com vocês ou se só eu estou me complicando 😅

Se alguém trabalha com Firebase em projetos reais, seria ótimo saber como vocês estão resolvendo isso.

Costumo trabalhar diretamente no console, talvez não aconteça comigo ou não sejam tantas as modificações que faço, por isso não tinha pensado nisso

Qual é exatamente o problema que você está tendo com os dados? Entendo que você monta muitos dashboards, mas não consigo compreender se o problema é a montagem dos dados ou os dados em si

No meu caso, vem mais por experiência própria do que por um problema pontual.

Lancei alguns apps com Firebase e, principalmente em um deles, o gerenciamento de dados foi ficando bastante complicado. Montamos diretamente no console do Firebase e, à medida que crescia, fazer alterações, gerenciar conteúdo ou mexer em usuários tornou-se bastante desconfortável, principalmente porque meu amigo (que não é dev), e por falta de tempo meu, teve que assumir os dados e acabou fazendo besteira.

Como solução, no final acabei criando pequenos sites internos para gerenciar o banco de dados (listagens, CRUD, usuários, etc.) com restrições na entrada de dados, mas é algo que já fiz duas vezes e tenho a sensação de que estou sempre repetindo a mesma coisa.

Por isso, estou explorando se esse processo pode ser simplificado com algo mais genérico que você possa montar rápido sem ter que desenvolver tudo do zero toda vez.

Uma das ideias que estou testando é me apoiar no WordPress, que no final já te dá todo o frontend e o gerenciamento de usuários bastante resolvido, e pode encaixar bem, principalmente para perfis menos técnicos.

Não sei, o que vocês acham?

Shurwebs disse:

No meu caso, vem mais por experiência própria do que por um problema pontual.

Lancei alguns apps com Firebase e, principalmente em um deles, o gerenciamento de dados foi ficando bastante complicado. Montamos diretamente no console do Firebase e, à medida que crescia, fazer alterações, gerenciar conteúdo ou mexer em usuários tornou-se bastante desconfortável, principalmente porque meu amigo (que não é dev), e por falta de tempo meu, teve que assumir os dados e acabou fazendo besteira.

Como solução, no final acabei criando pequenos sites internos para gerenciar o banco de dados (listagens, CRUD, usuários, etc.) com restrições na entrada de dados, mas é algo que já fiz duas vezes e tenho a sensação de que estou sempre repetindo a mesma coisa.

Por isso, estou explorando se esse processo pode ser simplificado com algo mais genérico que você possa montar rápido sem ter que desenvolver tudo do zero toda vez.

Uma das ideias que estou testando é me apoiar no WordPress, que no final já te dá todo o frontend e o gerenciamento de usuários bastante resolvido, e pode encaixar bem, principalmente para perfis menos técnicos.

Não sei, o que vocês acham?

Clique para expandir...

Se o problema real é que seu amigo precisa gerenciar as informações sem fazer besteira, FireCMS é uma solução, e é o que eu testaria primeiro.

Se você quer resolver o problema mais geral de nunca mais construir um admin do zero, Refine é a ferramenta ideal e aproveitando que você já domina React.

O WordPress eu deixaria apenas para projetos onde o produto em si seja conteúdo editorial (blog, landings, e-commerce com WooCommerce). Para backoffice de um app mobile/web, é introduzir um stack inteiro que não te agrega nada.

jzambrano12 disse:

Se o problema real é que seu amigo precisa gerenciar as informações sem fazer besteira, FireCMS é uma solução, e é o que eu testaria primeiro.

Se você quer resolver o problema mais geral de nunca mais construir um admin do zero, Refine é a ferramenta ideal e aproveitando que você já domina React.

O WordPress eu deixaria apenas para projetos onde o produto em si seja conteúdo editorial (blog, landings, e-commerce com WooCommerce). Para backoffice de um app mobile/web, é introduzir um stack inteiro que não te agrega nada.

Clique para expandir...

Faz sentido, obrigado pelas recomendações — vou dar uma olhada nelas.

E sim, é exatamente esse o caso que estou vendo: pessoas não técnicas que precisam gerenciar dados sem fazer besteira.

No meu caso, acabei montando pequenos painéis várias vezes só para isso, e estou tentando ver se há uma forma mais simples de resolver sem ter que refazer a mesma coisa toda vez.

Você não é o único, isso acontece o tempo todo com o Firebase. O console serve para coisas pontuais, mas assim que o projeto cresce ou o cliente quer mexer nos dados sem quebrar nada, ele fica muito limitado.

O mais comum que você vai ver é que, no início, todos usam o console, mas em projetos reais quase sempre terminam montando algum tipo de backoffice. Às vezes é algo simples e rápido, outras vezes um painel mais completo, dependendo do cliente. O problema é exatamente o que você disse, você acaba refazendo a mesma coisa mil vezes.

Existem várias abordagens que costumam ser usadas. Alguns montam um template interno de admin e o reutilizam em todos os projetos, mudando apenas as coleções e regras. Outros usam ferramentas tipo Retool, Appsmith ou similares para não programar tudo do zero. E depois tem a opção que você fez, que é abstrair isso em uma ferramenta própria ou plugin, o que, aliás, é bastante lógico se você já se cansou de repetir.

Sua ideia faz sentido, principalmente se você foca em pessoas que trabalham com WordPress ou clientes que já estão confortáveis com ele. O ponto chave é ver se você resolve algo além de “evitar fazer o painel”, por exemplo, controle de permissões, validações, edição segura de dados, logs, etc. É aí que realmente agrega valor.

Em resumo, você não está se complicando, é um problema bastante comum. O que muda é como cada um resolve isso de acordo com o tipo de cliente e o stack que utiliza, mas quase ninguém fica só com o console quando escala um pouco.

Justamente por isso continuei puxando esse fio nessas semanas 😅

No final, acabei transformando em um plugin e publiquei no repositório do WordPress para testar se o problema ressoava também fora dos meus projetos:


Ainda está muito early e continuo iterando bastante (sobre tudo onboarding/permissões/UX), mas está me servindo justamente para validar se esse pain é realmente tão comum como parecia ou se era apenas coisa minha.

E sinceramente, vendo várias respostas como a sua, parece que não sou o único que acabou refazendo o mesmo backoffice várias vezes.

No final, você sempre acaba no mesmo dilema com o Firebase porque, embora o console oficial seja potente para nós, desenvolvedores, não dá para soltar um cliente lá dentro de jeito nenhum; é um perigo e eles não entendem nada. Na minha experiência, montar um painel de administração sob medida do zero para cada projeto é uma autêntica dor de cabeça e consome um tempo tremendo que quase nunca é bem orçado. Por isso, acho um acerto brutal a ideia de conectar o Firestore ao WordPress através de um plugin.

Sim, acontece bastante. O console do Firebase serve para desenvolvimento ou revisões pontuais, mas para o cliente final ele fica limitado rapidamente.

Em projetos reais, costumo separar 3 casos:

1. Dados operacionais simples
   Se o cliente só precisa editar textos, estados, categorias, usuários ou registros básicos, prefiro montar um painel pequeno ou reutilizar um backoffice existente.
2. Dados sensíveis ou com lógica de negócio
   Aqui eu não deixaria o cliente tocar no Firestore diretamente pelo console. É fácil quebrar a estrutura, apagar campos ou pular validações. Melhor um painel com formulários controlados, funções e validação.
3. Projetos que vão crescer
   Nesse caso, tentaria não repetir painéis ad hoc. Faz sentido ter uma base reutilizável: CRUD genérico, funções, logs, filtros, exportação e permissões por coleção.

Gerenciar isso pelo WordPress pode fazer sentido se o cliente já usa WP e está confortável lá. O Firestore é muito flexível e isso mesmo pode ser perigoso quando alguém não técnico mexe.

cristhian1a disse:

No final, você sempre acaba no mesmo dilema com o Firebase porque, embora o console oficial seja potente para nós, desenvolvedores, não dá para soltar um cliente lá dentro de jeito nenhum; é um perigo e eles não entendem nada. Na minha experiência, montar um painel de administração sob medida do zero para cada projeto é uma autêntica dor de cabeça e consome um tempo tremendo que quase nunca é bem orçado. Por isso, acho um acerto brutal a ideia de conectar o Firestore ao WordPress através de um plugin.

Clique para expandir...

alej_vid disse:

Sim, acontece bastante. O console do Firebase serve para desenvolvimento ou revisões pontuais, mas para o cliente final ele fica limitado rapidamente.

Em projetos reais, costumo separar 3 casos:

1. Dados operacionais simples
   Se o cliente só precisa editar textos, estados, categorias, usuários ou registros básicos, prefiro montar um painel pequeno ou reutilizar um backoffice existente.
2. Dados sensíveis ou com lógica de negócio
   Aqui eu não deixaria o cliente tocar no Firestore diretamente pelo console. É fácil quebrar a estrutura, apagar campos ou pular validações. Melhor um painel com formulários controlados, funções e validação.
3. Projetos que vão crescer
   Nesse caso, tentaria não repetir painéis ad hoc. Faz sentido ter uma base reutilizável: CRUD genérico, funções, logs, filtros, exportação e permissões por coleção.

Gerenciar isso pelo WordPress pode fazer sentido se o cliente já usa WP e está confortável lá. O Firestore é muito flexível e isso mesmo pode ser perigoso quando alguém não técnico mexe.

Clique para expandir...

Justamente essa era a ideia por trás do plugin: que usuários não técnicos possam gerenciar os dados sem tocar no Firestore em bruto.

O console do Firebase é muito bom para nós como desenvolvedores, mas não me imagino deixando um cliente lá. É fácil demais apagar algo que não deve, modificar uma estrutura ou simplesmente se perder entre coleções.

Neste momento, o plugin permite navegar e modificar documentos a partir do WordPress de forma bem mais controlada, mas estou pensando em dar um passo além.

Uma ideia que tenho é permitir criar CPTs a partir de coleções do Firestore, de forma que para o usuário final seja praticamente transparente. Ou seja, que ele edite documentos como se fossem posts normais do WordPress, com seus campos, permissões e fluxo habitual.

Não tenho certeza ainda se é uma boa ideia ou se acabaria complicando demais o produto.

Vocês acham útil? Existe alguma outra funcionalidade que sentiriam falta?

Me ocorrem coisas como gestão de Storage, FCM, importação/exportação, permissões por coleção, etc., mas prefiro ouvir primeiro o que vocês realmente precisariam em projetos reais.

Por enquanto estou me baseando em necessidades próprias, mas a verdade é que outras opiniões seriam fenomenais.

Atualizo o tópico porque, no final, continuei desenvolvendo a ideia que comentei quando o abri.

Já tenho publicada a versão 0.5.0 do plugin no WordPress.org. Neste momento, ele permite gerenciar Firestore e Firebase Authentication diretamente pelo WordPress, além de ter um modo demo para testar sem precisar conectar um projeto Firebase.

A ideia continua sendo a mesma: que um cliente ou usuário não técnico possa gerenciar a informação que precisa sem dar acesso ao Firebase Console nem deixá-lo tocar no banco de dados em bruto.

Agora estou pensando nos próximos passos. Por um lado, adicionar Realtime Database e Storage, pelo menos com uma gestão básica.

E por outro, algo que acredito que pode ser bastante útil: relacionar os usuários do Firebase Authentication com seus dados no Firestore ou Realtime Database. O Auth por si só guarda informações bastante limitadas, então a ideia seria poder entrar na ficha de um usuário e ver também seus dados adicionais (perfil, plano, preferências ou o que cada projeto tiver), mesmo que estejam armazenados no banco de dados.

Isso também permitiria detectar casos como usuários de Auth sem documento associado ou documentos cujo usuário já não existe, e poder solucionar isso pelo mesmo painel.

Deixo aqui algumas capturas de como está agora, porque mudou bastante desde que abri o tópico.







O que vocês achariam mais útil como próximo passo: Realtime/Storage ou aprofundar primeiro nesta integração entre Auth e os dados de cada usuário?

Qualquer ideia é bem-vinda, pois prefiro ir adicionando coisas que realmente possam servir antes de colocar funções só por colocar.

Eu priorizaria a integração entre Firebase Auth e Firestore antes de adicionar mais serviços. Poder entrar em um usuário e ver diretamente seu perfil, plano, preferências e demais dados associados me parece bem mais útil no dia a dia do que simplesmente adicionar suporte para Realtime Database. Sobretudo se além disso você puder detectar automaticamente usuários de Auth sem documento no Firestore ou documentos órfãos. Inclusive eu adicionaria alguma opção para definir qual coleção e qual campo relacionam cada usuário com seu UID. Isso permitiria adaptá-lo melhor a projetos que não tenham exatamente a mesma estrutura. Storage sim, vejo como interessante depois, especialmente para poder gerenciar desde o mesmo perfil arquivos, avatares ou documentos associados ao usuário.