Deixe-me contar uma história técnica.
Há muitos anos, desenvolvi um aplicativo com funções de colaboração integradas. Era uma pilha experimental conveniente que utilizava todo o potencial do início do React e do CouchDB. Ele sincronizava dados em tempo real via JSON. . Era utilizado no trabalho interno da empresa, mas sua ampla aplicabilidade e potencial em outros setores eram evidentes.
Ao tentar vender essa tecnologia para clientes potenciais, nos deparamos com um obstáculo inesperado. No vídeo de demonstração, nossa tecnologia parecia e funcionava perfeitamente, sem problemas. O vídeo mostrava exatamente como funcionava, sem simulações. Criamos e codificamos um cenário de uso realista do programa.
Na verdade, isso acabou sendo um problema. Nossa demonstração funcionava exatamente como as aplicações de outras pessoas faziam. Para ser específico, a informação era transmitida instantaneamente de A para B, mesmo que fossem grandes arquivos de mídia. Após o login, cada usuário via novas postagens. Com o aplicativo, diferentes usuários podiam colaborar claramente nos mesmos projetos, mesmo em caso de conexão de Internet instável em algum lugar na roça. Isso é, de forma implícita, sugerido em qualquer vídeo sobre o produto editado no After Effects.
Apesar de todos saberem para que serve o botão Atualizar, ninguém entendia que os aplicativos web que eles nos pedem para criar, geralmente, estão sujeitos às suas limitações. E que, se não forem mais necessários, a experiência do usuário será completamente diferente. Principalmente, eles percebiam que podiam "conversar", deixando anotações para seus interlocutores, e se perguntavam como isso era diferente, por exemplo, do Slack. Ufa!
Design de sincronizações cotidianas
Se você já tem experiência em desenvolvimento de software, deve se irritar com a necessidade de lembrar que a maioria das pessoas não consegue simplesmente olhar para uma imagem da interface e entender o que ela fará ao interagir com ela. Sem mencionar o que acontece dentro do próprio programa. Saber o que pode vai acontecer é, em grande parte, o resultado de saber o que não pode acontecer e o que não deve acontecer. Para isso, é necessário não apenas o que o software faz, mas também como suas partes individuais estão alinhadas e se comunicam entre si.
Um clássico exemplo disso é um usuário que, por vinte minutos, olha para spinner.gif, se perguntando quando finalmente o trabalho vai acabar. O desenvolvedor entenderia que o processo provavelmente travou e que o gif nunca desaparecerá da tela. Essa animação imita o progresso do trabalho, mas não tem relação com seu estado. Em casos como este, alguns técnicos costumam revirar os olhos, impressionando-se com o grau de mal-entendido dos usuários. Mas note quem de fato aponta para os relógios giratórios e diz que, na verdade, eles estão completamente parados?
Esta é a essência do valor em tempo real. Hoje em dia, bancos de dados em tempo real ainda são extremamente pouco utilizados, e muitos os encaram com desconfiança. A maioria desses bancos de dados tende a inclinar-se ao estilo NoSQL, o que geralmente leva ao uso de soluções baseadas em Mongo, das quais é melhor esquecer. No entanto, para mim, isso significa trabalhar confortavelmente com CouchDB, além de explorar o design de estruturas que poderão ser preenchidas com dados por qualquer burocrata. Acredito que estou utilizando meu tempo de forma mais eficiente.
Mas o verdadeiro tema deste post é o que estou usando atualmente. Não por minha escolha, mas devido a uma política corporativa aplicada de forma indiferente e cega. Portanto, farei uma comparação Absolutamente Justa e Imparcial de dois produtos intimamente relacionados ao trabalho com bancos de dados em tempo real do Google.
Ambos os nomes contêm a palavra Fire. Um eu lembro com carinho. O outro, para mim, é um tipo diferente de chama. Não estou apressado para dizer seus nomes, porque assim que o fizer, enfrentaremos o primeiro grande problema — os nomes.
O primeiro se chama Firebase Real-Time Database, e o segundo — Firebase Cloud Firestore. Ambos são produtos da Firebase suite do Google. Suas APIs são chamadas, respectivamente, firebase.database(…) e firebase.firestore(…).
Isso ocorreu porque Real-Time Database — é apenas a versão original do Firebase antes de sua aquisição pelo Google em 2014. Depois, o Google decidiu criar um produto paralelo, construído a partir dos dados em grande escala da empresa, e o chamou de Firestore com uma nuvem. Espero que você ainda não esteja confuso. Se você se confundiu, não se preocupe, eu mesmo reescrevi esta parte do artigo dez vezes. Porque é necessário indicar Firebase, a plataforma de big data da empresa, e foi chamada de Firestore com nuvem. Espero que você ainda não esteja confuso. Se ainda estiver confuso, não se preocupe, eu mesmo reescrevi esta parte do artigo dez vezes.
Porque é necessário especificar Firebase na questão do Firebase, e Firestore na questão do Firebase, pelo menos para que você fosse entendido alguns anos atrás no Stack Overflow.
Se houvesse um prêmio para o pior nome de produtos de software, este caso definitivamente se tornaria um dos candidatos. A distância de Hamming entre esses nomes é tão pequena que confunde até mesmo engenheiros experientes, cujos dedos digitam um nome enquanto a cabeça pensa em outro. Esses planos falharam estrondosamente, criados com as melhores intenções; eles cumpriram a profecia de que o banco de dados estaria em chamas. E não estou brincando. A pessoa que inventou esse esquema de nomenclatura causou sangue, suor e lágrimas.
Vitória de Pirro
Poderia-se pensar que Firestore é uma substituição do Firebase, seu descendente de próxima geração, mas isso seria um equívoco. O Firestore definitivamente não serve como substituto do Firebase. Parece que alguém removeu tudo o que é interessante dele, e confundiu a maior parte do que sobrou de várias maneiras.
No entanto, uma rápida olhada nos dois produtos pode confundi-lo: eles parecem fazer praticamente a mesma coisa, através de APIs que são majoritariamente idênticas e até mesmo na mesma sessão de banco de dados. As diferenças são sutis e só são descobertas através de um exame comparativo cuidadoso da extensa documentação. Ou quando você tenta portar um código que funciona perfeitamente no Firebase para que ele funcione com o Firestore. É nesse momento que você percebe que a interface do banco de dados pega fogo assim que você tenta realizar um arrasto em tempo real. Reitero, não estou brincando.
O cliente Firebase é educado na medida em que ele armazena em cache as mudanças e realiza tentativas automáticas de atualização, priorizando a última operação de gravação. No entanto, o Firestore possui uma limitação de 1 operação de gravação por documento por usuário por segundo, e essa limitação é imposta pelo servidor. Ao trabalhar com ele, você deve encontrar uma forma de contornar isso e implementar um limitador de taxa de atualização, mesmo quando está apenas tentando criar seu aplicativo. Ou seja, o Firestore é um banco de dados em tempo real sem um cliente em tempo real, que se disfarça como tal através da API.
É aqui que começamos a ver os primeiros sinais do sentido da existência do Firestore. Pode ser que eu esteja enganado, mas suspeito que alguém no alto comando do Google olhou para o Firebase após a compra e simplesmente disse: “Não, de jeito nenhum. Isso é inaceitável. 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 com um tamanho máximo de 1 megabyte.”
Parece que essa limitação não vai suportar o primeiro choque com qualquer base de usuários suficientemente motivada. Você sabe que é verdade. No nosso trabalho, por exemplo, temos mais de mil apresentações, e isso é absolutamente normal.
Com essa limitação, você terá que aceitar o fato de que um ‘documento’ no banco de dados não se parecerá com nenhum objeto que o usuário possa chamar de documento.
“Arrays de arrays, que podem conter recursivamente outros elementos? Não. Arrays vão conter apenas objetos ou números de comprimento fixo, como foi destinado pelo Senhor.”
Portanto, se você esperava colocar seu GeoJSON no Firestore, descobrirá que isso é impossível. Nada multidimensional é permitido. Espero que você goste de Base64 e/ou JSON dentro do JSON.
“Importação e exportação de JSON via HTTP, ferramentas de linha de comando ou painel de administrador? Não. Você só poderá exportar e importar dados no Google Cloud Storage. Parece que agora é assim que se chama. E quando digo ‘você’, estou me dirigindo apenas àqueles que têm autoridade de Proprietário do Projeto. Todos os outros podem ir e criar tickets.”
Como você pode ver, o modelo de dados do FireBase é fácil de descrever. Ele contém um enorme documento JSON que vincula chaves JSON a caminhos de URL. Se você escrever usando HTTP PUT em / FireBase o seguinte:
{
"hello": "world"
} Então GET /hello retornará "world". Basicamente, funciona exatamente como você espera. A coleção de objetos FireBase /my-collection/:id é equivalente 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 perfeitamente se cada inserção tiver IDs sem colisões, 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 perfeitamente com HTTP, como o CouchDB. Mas, em sua maioria, você a utiliza através de uma API em tempo real, que abstrai websockets, autenticação e assinaturas. O painel de administração possui ambas as funcionalidades, permitindo tanto a edição em tempo real quanto a importação/exportação de JSON. Se você seguir isso em seu código, ficará surpreso com a quantidade de código especializado que desaparecerá quando entender que patch e diff JSON resolvem 90% das tarefas rotineiras de manipulação de estado persistente.
O modelo de dados Firestore é semelhante ao JSON, mas difere dele em alguns aspectos críticos. Já mencionei a ausência de arrays dentro de arrays. O modelo de sub-coleções é que elas são conceitos de primeira classe, separados do documento JSON que as contém. Como não existe uma serialização pronta para isso, é necessário um caminho especializado para execução de código ao obter e gravar dados. Para manipular suas próprias coleções, é preciso escrever seus próprios scripts e ferramentas. O painel de administração permite que você faça apenas pequenas alterações de um campo de cada vez e não possui 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 auto-combinação e uma coluna separada para não-JSON. Algo no espírito do GraftQL.
Java quente
Se o Firestore deveria se tornar mais confiável e escalável, a ironia é que o desenvolvedor médio terá uma solução menos confiável do que se tivesse escolhido o FireBase 'pronto para uso'. O software necessário para o Administrador de Banco de Dados Crítico requer tal nível de esforço e o calibre de especialistas que simplesmente não é realista para o nicho onde supostamente deveria haver um bom produto. É como se o HTML5 Canvas não fosse uma substituta do Flash se não houver ferramentas de desenvolvimento e reprodutores. Além disso, o Firestore se atolou na busca pela pureza dos dados e validação estéril, o que simplesmente não corresponde ao modo de trabalho do usuário médio de negócios. gosta de trabalhar: para ele, não é necessário, porque até o final tudo é um rascunho.
A principal desvantagem do FireBase é que o cliente foi criado alguns anos antes do seu prazo, muito antes de a maioria dos desenvolvedores web conhecer sobre imutabilidade. Por causa disso, o FireBase pressupõe que você irá modificar os dados e, portanto, não utiliza as vantagens da imutabilidade fornecida pelo usuário. Além disso, ele não reutiliza dados nos snapshots transmitidos ao usuário, o que torna a execução de diffs muito mais difícil. Para documentos grandes, o seu mecanismo de transações baseado em diffs mutáveis simplesmente não é adequado. Gente, nós já temos WeakMap em JavaScript. Isso é conveniente.
Se os dados forem formatados corretamente e as árvores não forem muito volumosas, é possível contornar esse problema. Mas eu estou curioso se o FireBase seria muito mais interessante se os desenvolvedores lançassem uma API de cliente realmente boa, que usasse imutabilidade em conjunto com conselhos práticos sérios sobre a estrutura das bases de dados. Em vez disso, eles parecem ter tentado consertar o que não estava quebrado, e isso tornou as coisas piores.
Eu não sei toda a lógica por trás da criação do Firestore. Refletir sobre as motivações que surgem dentro de uma caixa-preta é também parte da diversão. Essa oposição entre duas bases de dados extremamente semelhantes, mas incomparáveis, é bastante rara. É como se alguém tivesse pensado: “Firebase é apenas uma função que podemos emular no Google Cloud”, mas ainda não descobriu o conceito de definir requisitos do mundo real ou criar soluções úteis que atendam a todos esses requisitos. “Deixe isso para os desenvolvedores pensarem. Apenas faça a interface bonita... E podemos adicionar mais animação?”
Eu entendo algumas coisas sobre estruturas de dados. Eu realmente vejo que a ideia de “tudo em uma grande árvore JSON” é uma tentativa de abstrair da base de dados qualquer sensação de estrutura em larga escala. Esperar que o software simplesmente consiga lidar com qualquer fractal duvidoso de estrutura de dados é simplesmente loucura. Eu não preciso nem imaginar quão ruim tudo pode ser, eu fiz auditorias rigorosas de código e vi coisas que vocês, pessoas, nem sonham.. Mas eu também sei como são boas estruturas, e Posso imaginar um mundo onde o Firestore pareceria bastante lógico, e as pessoas que o criaram achariam que fizeram um bom trabalho. Mas não vivemos nesse mundo.
O suporte para construção de consultas no FireBase é ruim por quaisquer padrões; praticamente não existe. Definitivamente, ele precisa de melhorias ou, pelo menos, uma revisão. Mas o Firestore não é muito melhor, pois está limitado aos mesmos índices unidimensionais que existem em um SQL simples. Se você precisa de consultas que as pessoas fazem com dados caóticos, é necessário ter busca de texto completo, filtros em vários intervalos e uma ordem arbitrária definida pelo usuário. Ao examinar cuidadosamente, as funções do SQL simples são demasiado limitadas por si só. Além disso, os únicos SQLs que as pessoas podem executar no ambiente de produção são consultas rápidas. Você precisará de uma solução especializada para indexação com estruturas de dados bem pensadas. Para tudo o que resta, pelo menos deveria haver uma forma incremental de map-reduce ou algo semelhante.
Se você procurar informações sobre isso na documentação do Google, espero que o direcionem para algo como BigTable e BigQuery. No entanto, todas essas soluções vêm acompanhadas de uma quantidade tão grande de jargão corporativo que você rapidamente voltará e começará a buscar algo diferente.
A última coisa que você precisa em um banco de dados em tempo real é algo criado por pessoas para pessoas, trabalhando de acordo com a escala salarial de gerência.
(*) Isso é uma piada, não existe um conceito como .
Em nome da publicidade
Procurando um servidor para desenvolver e hospedar projetos? Você definitivamente é o nosso cliente 🙂 Cobrança diária para servidores de várias configurações, antiDDoS e licenças do Windows já estão incluídas no custo.
Fonte: habr.com
