Firestore — O novo produto do Firebase

Em outubro de 2017, foi lançado o Firestore, com o objetivo de resolver alguns problemas que o Realtime Database apresentava na hora de desenvolver uma aplicação. A grande diferença é que, agora, o modelo de dados é orientado a documentos, diferentemente do Realtime Database que armazenava dados em forma de uma grande árvore JSON. Um documento pode ser visto como um objeto JavaScript e uma coleção nada mais é do que um conjunto de documentos.

A vantagem do Firestore é que ficou mais fácil organizar dados complexos através da utilização de subcoleções em documentos. Isso faz com que haja uma menor desnormalização do banco de dados o que resulta em uma menor duplicação de dados.

Como assim?

No Realtime Database, nós temos uma capacidade limitada de queries, caso quisermos fazer consultas mais complexas, como uma query composta, temos que desnormalizar o banco de dados com campos que nos permitam obter o dado que desejamos.

Por exemplo, digamos que a nossa intenção é filtrar os restaurantes localizados na cidade de Porto Alegre, onde sua reputação seja maior ou igual a 8. No Realtime Database, nós teríamos que criar um campo a mais no objeto restaurante, pois não seria possível fazer uma query composta que retornasse o dado que desejamos. Nossa árvore JSON ficaria mais ou menos assim:

Já no Firestore, nós não precisamos desnormalizar o banco de dados a esse nível, pois podemos fazer o uso de queries compostas mais avançadas. Poderíamos simplesmente executar o seguinte comando:

No entanto, a primeira vez que você executar uma query composta sem índice, você perceberá, ao abrir o console de seu navegador, que ela não pode ser executada. Isso ocorre porque o Firestore exige que seja criado um índice para tal query. Por padrão, é criado um índice para todos os campos dos documentos, porém esses índices são feitos para consultas que usam apenas um sinal de igualdade. Queries compostas que fazem uso de uma range clause exigem que sejam criados índices específicos. Para criar tal índice, basta abrir o console de seu navegador e clicar no link da mensagem de erro. Você será direcionado para o console do Firestore, onde poderá criar um índice para sua consulta.

Estrutura

Abaixo segue um exemplo de como seria o armazenamento da coleção de restaurantes no Firestore.

Perceba que a maneira que são armazenados os documentos em coleções é muito similar a estrutura da árvore JSON do Realtime Database. No entanto, a grande diferença é que caso esse banco de dados cresça, a sua escalabilidade torna-se mais maleável na medida em que a hierarquia de coleções, documentos e subcoleções é mais fácil de organizar do que um grande objeto JSON.

Ainda falando sobre escalabilidade, no Realtime Database era necessário criar vários projetos no console do Firebase e conectar seu app a cada um deles, processo conhecido como “sharding”. Isso acontecia porque o Realtime Database tem um limite de 100.000 conexões simultâneas e 1.000 operações de gravação/segundo para uma instância de banco de dados. Assim, para superar esses limites o desenvolvedor teria que criar outros projetos e conectá-los ao seu App.

O Firestore promete acabar com esse problema. Segundo sua documentação, a partir do momento em que deixar de ser BETA, a escalabilidade será automática.

Modelando seu banco de dados

Na modelagem do seu banco de dados você deve considerar duas regras:

1) Um documento não pode conter outro documento.

2) Coleções só podem conter documentos, ou seja, não é possível ter uma coleção de coleções.

No entanto, um documento pode conter subcoleções (de até 100 níveis). Isso é extremamente útil porque é possível estruturar os dados de maneira hierárquica, fazendo com que o acesso a eles seja simplificado. Também é possível embutir objetos complexos como arrays no documento, porém é preciso tomar cuidado, porque, caso não seja possível prever o tamanho que o array poderá vir a ter, o carregamento de dados pode tornar-se lento, pois a performance do Firestore é baseada no tamanho do resultado de sua pesquisa e não no tamanho do banco de dados, ou seja, a agilidade é medida pela quantidade de MB que a busca retorna. Isso só é possível graças aos índices que o Firestore faz uso. Sem falar que não é possível editar apenas um elemento do array e que cada documento tem um limite de 1MB.

Portanto, ao modelar seu banco de dados é importante pensar em grandes coleções com pequenos documentos, ou seja, por uma questão de performance e organização hierárquica deve-se preferir o uso de subcoleções do que grandes documentos que podem tornar-se pesados.

Queries

Sem dúvida, uma das grandes melhorias do Firestore em relação ao Realtime Database é que ficou muito mais flexível buscar dados no banco de dados. Para se ter uma ideia, no Realtime Database as queries são deep by default, ou seja, elas retornam toda a subtree do objeto que estamos buscando. Com o uso de subcoleções isso não ocorre no Firestore, pois as queries são o que chamamos de shallow, ou seja retornam apenas o documento que estamos buscando, desta maneira não precisamos nos preocupar com as subcoleções que o documento tem. Além do mais, agora é possível combinar sorting e filtering em uma mesma propriedade em uma única query, funcionalidade que não é permitida no Realtime Database.

Realtime Database vs Firestore

Qual eu devo usar?

Enquanto o Firestore estiver na versão Beta, eu sugeria para você utilizar uma combinação dos dois modelos de banco de dados. Sim, o Firebase oferece essa possibilidade, basta usar os serviços a partir do namespace firebase, assim para ter uma referência do Realtime Database você só precisa executar o seguinte comando firebase.database(), e para o Firestore este outro comando firebase.firestore(). Feito isso, elabore sua estratégia, você pode usar o Firestore apenas para salvar dados que não sejam core para seu negócio, ou fazer uma duplicação de dados, ou seja para cada write, você pode salvar nos dois bancos de dados. Assim, caso a primeira estratégia tenha sido a escolhida, quando você se sentir confortável com a utilização da ferramenta e estiver com a confiança necessária para fazer a completa utilização dela, você apenas terá que importar os dados do Realtime Database e gerar um script para exportar os dados para o Firestore.