No Firestore, a forma como a aplicação consulta documentos deve orientar o modelo de leitura. Uma tela de posts recentes pode filtrar por estado publicado e ordenar pela data. Um painel administrativo pode precisar listar rascunhos e publicados por última atualização. Essas são consultas diferentes, com critérios e custo diferentes, ainda que usem a mesma coleção.

Escreva a consulta antes de criar o índice

Liste os filtros, a ordenação e o limite de cada tela. Depois teste a consulta em uma base de desenvolvimento com os mesmos campos e valores do caso real. Consultas compostas podem precisar de um índice específico. O erro de índice ausente costuma fornecer um link para criá-lo, mas esse link não substitui a revisão: confira se o índice representa uma consulta permanente e se foi aplicado no projeto correto.

Um índice é parte do contrato operacional do banco. Mantenha as definições necessárias em arquivo de configuração versionado quando a ferramenta e o projeto suportarem isso. Assim, uma implantação nova não depende de alguém lembrar de clicar manualmente no console. Remova índices não usados com cuidado e observe métricas antes de presumir que uma consulta deixou de ser importante.

Ordenação também muda o conjunto de resultados

Uma consulta ordenada por publishedAt não é apenas uma lista reordenada no cliente. Documentos sem esse campo podem não aparecer no resultado ordenado. Ao publicar dados legados, verifique se todos os documentos têm os campos exigidos. Um valor ausente, nulo ou de tipo diferente também pode gerar ordenações inesperadas e tornar a paginação inconsistente.

O campo de ordenação deve ter semântica única. Se alguns posts guardam string ISO e outros guardam timestamps, a comparação pode produzir agrupamentos incompatíveis. Migre para um formato canônico e normalize novas gravações. Use datas UTC ou um formato com fuso explícito para não depender da configuração local do servidor.

Segurança de consulta não é filtro pós-leitura

As regras do Firestore avaliam se a consulta inteira pode retornar apenas documentos autorizados. Elas não baixam resultados e removem os que violam a regra depois. Uma consulta precisa incluir condições compatíveis com as regras. Isso exige alinhar o modelo de autorização às consultas que a interface executa.

Há uma distinção no servidor: bibliotecas administrativas do Firebase usam credenciais IAM e não passam pelas regras de segurança do cliente. Uma rota de servidor que lê dados privados precisa aplicar autorização própria antes de consultar o Firestore. Habilitar regras restritivas não protege, por si só, um endpoint que usa Admin SDK.

Observe leituras e comportamento real

Um limit controla o tamanho da página, mas não garante custo previsível se o cliente repetir a chamada sem necessidade. Evite baixar uma coleção inteira para filtrar e ordenar no navegador quando o conjunto pode crescer. Confira documentos lidos, tamanho da resposta e consultas por sessão.

Teste também dados sem campos, filtros que combinam valores e tentativas de acesso por usuário sem vínculo. Se a consulta falhar por índice, registre qual combinação de filtros exigiu a definição e acrescente o índice ao fluxo de implantação. O modelo, as consultas, regras e índices precisam evoluir juntos para que outra instalação consiga reproduzir a leitura.

Firestore: consultas e regras de segurança · Firestore: índices