Deixe-me contar uma história técnica.
Muitos anos atrás, eu estava desenvolvendo um aplicativo com recursos de colaboração integrados. Foi uma pilha experimental útil que aproveitou todo o potencial do React e do CouchDB anteriores. Ele sincronizou dados sobre JSON OT em tempo real . Foi utilizado internamente na empresa, mas ficou evidente sua ampla aplicabilidade e potencial em outras áreas.
Ao tentar vender essa tecnologia para clientes em potencial, encontramos um obstáculo inesperado. No vídeo de demonstração, nossa tecnologia parecia e funcionava muito bem, sem problemas. O vídeo mostrou exatamente como funciona, e nada foi imitado nele. Criamos e codificamos um cenário realista para usar o programa.
Na verdade, esse se tornou o problema. Nossa demonstração funcionou exatamente da maneira que todos os outros simularam o trabalho de seus aplicativos. Mais especificamente, as informações foram transferidas instantaneamente de A para B, mesmo que fossem grandes arquivos de mídia. Após o login, cada usuário viu novas entradas. Usando o aplicativo, diferentes usuários poderiam colaborar exatamente nos mesmos projetos, mesmo que a conexão com a Internet fosse interrompida em algum lugar da aldeia. Isso está implicitamente implícito em qualquer vídeo de produto cortado no After Effects.
Mesmo que todos soubessem para que servia o botão Atualizar, ninguém entendeu que os aplicativos da web que eles nos pedem para construir geralmente estão sujeitos às suas próprias limitações. E se eles não forem mais necessários, a experiência do usuário será completamente diferente. Basicamente, eles perceberam que você pode "bater um papo" deixando notas para os interlocutores, então eles se perguntaram como isso difere, por exemplo, do Slack. Uf-f-f!
Design de sincronização diária
Se você já tem experiência em desenvolvimento de software, deve ficar nervoso ao lembrar que a maioria das pessoas não pode simplesmente olhar para a imagem de uma interface e descobrir o que ela fará ao interagir com ela. Sem mencionar o que está acontecendo dentro do próprio programa. Saber o que pode acontecer é em grande parte o resultado de saber o que não pode e o que não deve acontecer. Isso requer um modelo mental não apenas do que o software faz, mas também de como suas partes individuais são coordenadas e se comunicam umas com as outras.
Um exemplo clássico disso é um usuário olhando para spinner.gif por vinte minutosimaginando quando o trabalho finalmente terminará. O desenvolvedor entenderia que o processo provavelmente está congelado e que o gif nunca desaparecerá da tela. Esta animação simula a execução da obra, mas não está associada ao seu estado. Em casos como esse, alguns técnicos gostam de revirar os olhos, maravilhados com o grau de confusão do usuário. No entanto, observe qual deles aponta para o relógio girando e diz que eles estão realmente parados?
Esta é a essência do valor em tempo real. Os bancos de dados em tempo real ainda são muito pouco usados hoje em dia e muitos suspeitam deles. A maioria desses bancos de dados está ativamente inclinada para o estilo NoSQL, e é por isso que eles geralmente usam soluções baseadas em Mongo que são melhores. No entanto, para mim significa o conforto de trabalhar com o CouchDB, bem como o estudo de desenhar estruturas que não apenas alguns burocratas poderão preencher com dados. Acho que estou gastando meu tempo melhor.
Mas o verdadeiro tópico deste post é o que estou usando hoje. Não por opção, mas por causa da política corporativa aplicada de forma indiferente e cega. Portanto, vou apresentar uma comparação perfeitamente honesta e imparcial de dois produtos de banco de dados em tempo real do Google intimamente relacionados.
Ambos têm a palavra Fogo em seus nomes. Uma coisa eu me lembro com carinho. O segundo para mim é um tipo diferente de fogo. Não tenho pressa em dizer seus nomes, porque assim que faço isso, nos deparamos com o primeiro grande problema - nomes.
O primeiro é denominado Firebase Real-Time Database e o segundo é Firebase Cloud Firestore . Ambos são produtos do pacote Firebase do Google. Suas APIs são nomeadas, respectivamente,
firebase.database(…)e firebase.firestore(…).
Isso ocorre porque o Real-Time Database é apenas o Firebase original antes que o Google o comprasse em 2014. Então o Google decidiu criar uma cópia deFirebase com base no big data da empresa e nomeou-o Firestore com uma nuvem. Eu espero que você não esteja confuso ainda. Se você ficar confuso, não se preocupe, eu mesmo reescrevi esta parte do artigo dez vezes.
Porque o Firebase precisa ser citado na pergunta do Firebase e o Firestore na pergunta do Firebase, pelo menos para ser compreendido há alguns anos no Stack Overflow.
Se houvesse um prêmio para a pior nomenclatura de produtos de software, esse caso definitivamente se tornaria um dos candidatos. A distância de Hamming entre esses nomes é tão pequena que confunde até engenheiros experientes, cujos dedos estão digitando um nome, embora a cabeça pense em outro. São planos que falharam miseravelmente, inventados com as melhores intenções; eles cumpriram a profecia de que o banco de dados estaria em chamas. E eu não estou brincando. O homem que elaborou esse esquema de nomenclatura causou sangue, suor e lágrimas.
Vitória de Pirro
Alguém poderia pensar que o Firestore é um substituto do Firebase, seu descendente da próxima geração, mas isso seria um equívoco. O Firestore tem a garantia de não ser um substituto do Firebase. Parece que alguém cortou tudo o que era interessante e confundiu a maior parte do resto de maneiras diferentes.
No entanto, uma rápida olhada nos dois produtos pode ser confusa: eles parecem estar fazendo a mesma coisa, principalmente por meio das mesmas APIs e até mesmo na mesma sessão de banco de dados. As diferenças são sutis e só aparecem com um estudo comparativo completo da extensa documentação. Ou ao tentar portar um código que funciona perfeitamente para o Firebase funcionar com o Firestore. Mesmo assim, você descobre que a interface do banco de dados acende assim que você tenta arrastar e soltar em tempo real. Novamente, não estou brincando.
O cliente Firebase é educado no sentido de que armazena as alterações em buffer e repete as atualizações automaticamente, dando prioridade à última gravação. No entanto, o Firestore tem um limite de 1 operações de gravação por documento por usuário por segundo, e esse limite é imposto pelo servidor. Ao trabalhar com ele, você mesmo deve encontrar uma maneira de contornar isso e implementar um limitador de taxa de atualização, mesmo quando você está apenas tentando construir seu aplicativo. Ou seja, o Firestore é um banco de dados em tempo real sem um cliente em tempo real que se disfarça usando uma API.
Com isso, começamos a ver os primeiros sinais do significado da existência do Firestore. Posso estar errado, mas suspeito que alguém no alto escalão do google cuidou de comprar no Firebase e apenas disse: “Não, meu Deus, não. Isso é inaceitável. Só não sob minha liderança. "
Ele saiu de seus aposentos e proclamou:
“Um grande documento JSON? Não. Você vai dividir os dados em documentos separados, cada um dos quais não terá mais de 1 megabyte de tamanho. "
Parece que tal limitação não sobreviverá ao primeiro encontro com qualquer base de usuários razoavelmente motivada. Você sabe que é. No trabalho, por exemplo, temos mais de mil e quinhentas apresentações, e isso é perfeitamente normal.
Com essa limitação, você terá que aceitar o fato de que um único “documento” em um banco de dados não será como qualquer objeto que um usuário possa chamar de documento.
“Arrays de arrays que podem conter recursivamente outros elementos? Não. Matrizes irão conter apenas objetos de comprimento fixo ou números como o Senhor pretendia. "
Portanto, se você esperava colocar o GeoJSON em seu Firestore, descobrirá que isso não é possível. Nada não uniforme é permitido. Espero que você ame Base64 e / ou JSON dentro de JSON.
Importar e exportar JSON por HTTP, ferramentas de linha de comando ou painel de administração? Não. Você só poderá exportar e importar dados para o Google Cloud Storage. Portanto, parece ser chamado agora. E quando digo "você", estou me referindo apenas àqueles que têm poderes de proprietário do projeto. Todos os outros podem criar ingressos. "
Como você pode ver, o modelo de dados FireBase é fácil de descrever. Ele contém um enorme documento JSON vinculando chaves JSON a caminhos de URL. Se você escrever o seguinte
HTTP PUTno /FireBase:
{
"hello": "world"
}Ele
GET /hellovai voltar "world". Basicamente, funciona exatamente como você espera. Uma coleção de objetos FireBase é /my-collection/:idequivalente a um dicionário JSON {"my-collection": {...}}na raiz, cujo conteúdo está disponível em /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Isso funciona bem se cada inserção tiver um ID de não colisão, para o qual o sistema possui uma solução padrão.
Em outras palavras, o banco de dados é 100% compatível com JSON (*) e funciona muito bem com HTTP como o CouchDB. Mas principalmente você o usa por meio de uma API em tempo real que abstrai websockets, autorização e assinaturas. O painel de administração tem ambos os recursos, permitindo edição em tempo real e importação / exportação JSON. Se você ficar com o mesmo código em seu código, ficará surpreso com quanto código customizado é desperdiçado ao perceber que patch e JSON de diff resolvem 90% das tarefas de estado persistente de rotina.
O modelo de dados Firestore é semelhante ao JSON, mas difere dele em vários aspectos críticos. Já mencionei a falta de arrays dentro de arrays. O modelo de sub-coleções deve ser conceitos de primeira classe separados do documento JSON que o contém. Como não há serialização pronta para uso para isso, um caminho de código especializado é necessário para obter e gravar dados. Para processar suas próprias coleções, você precisa escrever seus próprios scripts e ferramentas. O painel de administração só permite que você faça pequenas alterações em um campo por vez e não tem recursos de importação / exportação.
Eles pegaram um banco de dados NoSQL em tempo real e o transformaram em um não SQL lento com junção automática e uma coluna não JSON separada. Algo no espírito do GraftQL .
Java quente
Se o Firestore se tornasse mais confiável e escalável, a ironia é que o desenvolvedor médio obterá uma solução menos confiável do que escolher o FireBase pronto para uso. O software de que o administrador de banco de dados mal-humorado precisa exige um tal nível de esforço e calibre de especialistas que é simplesmente irreal para um nicho no qual o produto é considerado bom. Isso é semelhante a como o HTML5 Canvas não substitui o Flash se não houver ferramentas de desenvolvimento e um player. Além disso, o Firestore está atolado em uma busca por limpeza de dados e validação estéril, o que simplesmente não está de acordo com a forma como o usuário empresarial médio gosta de trabalhar : para ele, tudo é opcional, porque tudo é um rascunho até o fim.
A principal desvantagem do FireBase é que o cliente foi criado com vários anos de antecedência, antes mesmo que a maioria dos desenvolvedores da web soubesse da imutabilidade. Por causa disso, o FireBase presume que você estará modificando os dados e, portanto, não tira vantagem da imutabilidade fornecida pelo usuário. Além disso, ele não reutiliza dados em snapshots enviados ao usuário, o que torna a comparação muito mais difícil. Para documentos grandes, seu mecanismo de transação baseado em diff mutável é simplesmente inadequado. Pessoal, já temos
WeakMapJavaScript. É confortável.
Ao modelar os dados conforme necessário e não tornar as árvores muito volumosas, esse problema pode ser contornado. Mas estou curioso para saber se o FireBase seria muito mais interessante se os desenvolvedores apresentassem uma API de cliente realmente boa que usa imutabilidade combinada com alguns conselhos práticos e sólidos sobre design de banco de dados. Em vez disso, eles parecem ter tentado consertar o que não está quebrado, e isso piorou as coisas.
Não conheço toda a lógica por trás da criação do Firestore. Raciocinar sobre os motivos que surgem dentro da caixa preta também faz parte da diversão. Essa justaposição de dois bancos de dados extremamente semelhantes, mas incomparáveis, é bastante rara. Como se alguém estivesse pensando, "Firebase é apenas um recurso que podemos emular no Google Cloud."mas ainda não descobriram o conceito de definir requisitos do mundo real ou criar soluções úteis que satisfaçam todos esses requisitos. “Deixe os desenvolvedores pensarem sobre isso. Basta deixar a IU bonita ... Você pode adicionar mais fogo? "
Eu entendo algumas coisas sobre estruturas de dados. Posso ver claramente que o conceito de "tudo em uma grande árvore JSON" é uma tentativa de abstrair do banco de dados qualquer noção de estrutura em grande escala. Esperar que o software simplesmente lide com qualquer fractal de estrutura de dados questionável é uma loucura. Nem preciso imaginar como tudo pode ser ruim, fiz rigorosas auditorias de código e vi algo que vocês nunca sonharam . Mas também sei como são as boas estruturas, como usá-las epor que isso deve ser feito . Posso imaginar um mundo no qual o Firestore parecia lógico e as pessoas que o criaram achavam que fizeram um bom trabalho. Mas não vivemos neste mundo.
O suporte para a construção de consultas no FireBase é pobre por qualquer padrão, ele praticamente não existe. Definitivamente, precisa de melhorias ou pelo menos revisão. Mas o Firestore não é muito melhor, pois é limitado aos mesmos índices 1D encontrados no SQL simples. Se você deseja consultas que as pessoas realizam com dados caóticos, precisa de pesquisa de texto completo, filtros em vários intervalos e ordenação arbitrária definida pelo usuário. Olhando mais de perto, as funções do SQL simples são muito limitadas por si mesmas. Além disso, as únicas consultas SQL que os humanos podem executar na produção são as consultas rápidas. Você precisará de uma solução de indexação especializada com estruturas de dados sofisticadas. Para todo o resto, pelo menos deve haver uma redução de mapa incremental ou algo semelhante.
Se você olhar nos documentos do Google sobre isso, provavelmente será apontado na direção de algo como BigTable e BigQuery. No entanto, todas essas decisões são acompanhadas por um volume tão grande de jargão de vendas corporativas que você rapidamente voltará e começará a procurar por outra coisa.
A última coisa que você precisa no caso de um banco de dados em tempo real é algo feito por humanos e para pessoas que trabalham em uma escala de salários para liderança.
(*) Isso é uma piada, não existe 100% de compatibilidade JSON .
Publicidade
Você está procurando um VDS para projetos de depuração, um servidor para desenvolvimento e implantação? Definitivamente, você é nosso cliente :) Faturamento diário de servidores de várias configurações, licenças anti-DDoS e Windows já estão inclusos no preço.
