Deixe-me contar uma história técnica.
Muitos anos atrás, eu estava desenvolvendo um aplicativo com recursos de colaboração integrados. Era uma pilha experimental fácil de usar que aproveitava todo o potencial dos primeiros React e CouchDB. Sincronizou dados em tempo real via JSON . Foi utilizado internamente na empresa, mas ficou claro sua ampla aplicabilidade e potencial em outras áreas.
Ao tentar vender esta tecnologia a potenciais clientes, 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 não imitou nada. Criamos e codificamos um cenário realista para usar o programa.
Na verdade, esse se tornou o problema. Nossa demonstração funcionou exatamente como todos os outros simularam seus aplicativos. 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 trabalhar juntos claramente 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 corte de vídeo de produto no After Effects.
Embora todos soubessem para que servia o botão Atualizar, ninguém realmente entendia que os aplicativos da web que nos pediam para construir geralmente estavam sujeitos às suas próprias limitações. E que se não forem mais necessários, a experiência do usuário será completamente diferente. Eles notaram principalmente que podiam “bater um papo” deixando notas para as pessoas com quem estavam conversando, então se perguntaram como isso era diferente, por exemplo, do Slack. Ufa!
Design de sincronizações diárias
Se você tem experiência em desenvolvimento de software, deve ser estressante lembrar que a maioria das pessoas não consegue simplesmente olhar a imagem de uma interface e entender o que ela fará ao interagir com ela. Sem falar no que acontece dentro do próprio programa. Conhecimento que lata acontecer é em grande parte o resultado de saber o que não pode acontecer e o que não deveria acontecer. Isto exige não apenas o que o software faz, mas também como suas partes individuais são coordenadas e se comunicam entre si.
Um exemplo clássico disso é um usuário olhando para um spinner.gif, imaginando quando o trabalho finalmente será concluído. O desenvolvedor teria percebido que o processo provavelmente travou e que o gif nunca desapareceria da tela. Esta animação simula a execução de um job, mas não está relacionada ao seu estado. Nesses casos, alguns técnicos gostam de revirar os olhos, surpresos com a extensão da confusão do usuário. Porém, observe quantos deles apontam para o relógio giratório e dizem que ele está realmente parado?
Esta é a essência do valor em tempo real. Hoje em dia, os bancos de dados em tempo real ainda são muito pouco utilizados e muitas pessoas os veem com desconfiança. A maioria desses bancos de dados se inclina fortemente para o estilo NoSQL, e é por isso que geralmente usam soluções baseadas em Mongo, que é melhor esquecer. No entanto, para mim, isso significa ficar confortável trabalhando com o CouchDB, bem como aprender a projetar estruturas que mais do que apenas um burocrata possa preencher com dados. Acho que estou usando melhor meu tempo.
Mas o verdadeiro tema deste post é o que estou usando hoje. Não por opção, mas por causa de políticas corporativas aplicadas de forma indiferente e cega. Portanto, fornecerei uma comparação totalmente justa 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 que me lembro com carinho. A segunda coisa para mim é um tipo diferente de fogo. Não tenho pressa em dizer seus nomes, porque quando o fizer, nos depararemos com o primeiro grande problema: nomes.
O primeiro é chamado Banco de dados em tempo real do Firebase, e em segundo lugar - Firebase Cloud Firestore. Ambos são produtos de Pacote Firebase Google. Suas APIs são chamadas respectivamente firebase.database(…) и firebase.firestore(…).
Isso aconteceu porque Banco de dados em tempo real - é apenas o original Firebase antes de sua compra pelo Google em 2014. Então o Google decidiu criar um produto paralelo uma cópia Firebase baseado em empresa de big data e chamado de Firestore com nuvem. Espero que você não esteja confuso ainda. Se você ainda está confuso, não se preocupe, eu mesmo reescrevi esta parte do artigo dez vezes.
Porque você precisa indicar Firebase na pergunta do Firebase e Armazém de Fogo em uma pergunta sobre Firebase, pelo menos para você entender há alguns anos no Stack Overflow.
Se houvesse um prêmio para a pior experiência de nomenclatura de software, este seria definitivamente 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 suas cabeças pensam em outro. São planos bem-intencionados que falham miseravelmente; eles cumpriram a profecia de que o banco de dados estaria pegando fogo. E eu não estou brincando. A pessoa que criou esse esquema de nomenclatura causou sangue, suor e lágrimas.
Vitória pírrica
Alguém poderia pensar que o Firestore é substituição Firebase, seu descendente da próxima geração, mas isso seria enganoso. Não há garantia de que o Firestore seja um substituto adequado para o Firebase. Parece que alguém cortou tudo o que era interessante e confundiu a maior parte do resto de várias maneiras.
No entanto, uma rápida olhada nos dois produtos pode confundi-lo: eles parecem fazer a mesma coisa, basicamente através das mesmas APIs e até mesmo na mesma sessão de banco de dados. As diferenças são sutis e só são reveladas por um cuidadoso estudo comparativo de extensa documentação. Ou quando você está tentando portar um código que funciona perfeitamente no Firebase para que funcione com o Firestore. Mesmo assim você descobre que a interface do banco de dados acende assim que você tenta arrastar e soltar com o mouse em tempo real. Repito, não estou brincando.
O cliente Firebase é educado no sentido de que armazena em buffer as alterações e tenta automaticamente as atualizações que dão prioridade à última operação de gravação. No entanto, o Firestore tem um limite de 1 operação de gravação por documento, por usuário, por segundo, e esse limite é aplicado pelo servidor. Ao trabalhar com ele, cabe a você encontrar uma maneira de contornar isso e implementar um limitador de taxa de atualização, mesmo quando estiver 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 como um banco de dados que usa uma API.
Aqui começamos a ver os primeiros sinais da razão de ser da Firestore. Posso estar errado, mas suspeito que alguém do alto escalão da administração do Google olhou para o Firebase após a compra e simplesmente disse: “Não, meu Deus, não. Isso é inaceitável. Só que não sob minha liderança."
Ele apareceu de seus aposentos e declarou:
“Um grande documento JSON? Não. Você dividirá os dados em documentos separados, cada um dos quais não terá mais que 1 megabyte de tamanho.”
Parece que tal limitação não sobreviverá ao primeiro encontro com qualquer base de utilizadores suficientemente motivada. Você sabe que é. No trabalho, por exemplo, temos mais de mil e quinhentas apresentações, e isso é Completamente Normal.
Com esta limitação, você será forçado a aceitar o fato de que um "documento" no banco de dados não se parecerá com nenhum objeto que um usuário possa chamar de documento.
"Matrizes de matrizes que podem conter recursivamente outros elementos? Não. Matrizes conterão apenas objetos ou números de comprimento fixo, como Deus planejou."
Portanto, se você esperava colocar GeoJSON em seu Firestore, descobrirá que isso não é possível. Nada não unidimensional é aceitável. Espero que você goste de Base64 e/ou JSON dentro de JSON.
“Importação e exportação JSON via 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. É assim que se chama agora, eu acho. E quando digo “você”, estou me dirigindo apenas àqueles que possuem credenciais 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 que associa chaves JSON a caminhos de URL. Se você escreve com HTTP PUT в / FireBase é o seguinte:
{
"hello": "world"
}
То GET /hello retornará "world". Basicamente, funciona exatamente como você esperaria. 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 bem se cada inserção tiver um ID livre de 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 basicamente você o usa por meio de uma API em tempo real que abstrai websockets, autorizações e assinaturas. O painel de administração possui ambos os recursos, permitindo edição em tempo real e importação/exportação de JSON. Se você fizer o mesmo em seu código, ficará surpreso com a quantidade de código especializado que será desperdiçado ao perceber que patch e diff JSON resolvem 90% das tarefas rotineiras de manipulação de estado persistente.
O modelo de dados do Firestore é semelhante ao JSON, mas difere em alguns aspectos críticos. Já mencionei a falta de arrays dentro de arrays. O modelo para subcoleções é que sejam conceitos de primeira classe, separados do documento JSON que os contém. Como não existe uma serialização pronta para isso, é necessário um caminho de código especializado para recuperar 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 fazer pequenas alterações em um campo por 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 junção automática e uma coluna não JSON separada. Algo como GraftQL.
Java quente
Se o Firestore deveria ser mais confiável e escalável, a ironia é que o desenvolvedor médio acabará com uma solução menos confiável do que escolher o FireBase pronto para uso. O tipo de software que o administrador de banco de dados mal-humorado precisa requer um nível de esforço e calibre de talento que é simplesmente irreal para o nicho em que o produto deveria ser 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 um desejo de pureza de dados e validação estéril que simplesmente não se alinha com a forma como o usuário empresarial médio adora trabalhar: para ele tudo é opcional, porque até o final tudo é rascunho.
A principal desvantagem do FireBase é que o cliente foi criado vários anos antes de seu tempo, antes que a maioria dos desenvolvedores web soubesse da imutabilidade. Por causa disso, o FireBase assume que você alterará os dados e, portanto, não aproveita a imutabilidade fornecida pelo usuário. Além disso, ele não reutiliza os dados nos instantâneos que passa ao usuário, o que torna a comparação muito mais difícil. Para documentos grandes, seu mecanismo de transação mutável baseado em diferenças é simplesmente inadequado. Pessoal, já temos WeakMap em JavaScript. É confortável.
Se você der aos dados o formato desejado e não deixar as árvores muito volumosas, esse problema poderá ser contornado. Mas estou curioso para saber se o FireBase seria muito mais interessante se os desenvolvedores lançassem uma API de cliente realmente boa que usasse imutabilidade combinada com alguns conselhos práticos sérios sobre design de banco de dados. Em vez disso, pareciam tentar consertar o que não estava quebrado, e isso piorou as coisas.
Não conheço toda a lógica por trás da criação do Firestore. Especular sobre os motivos que surgem dentro da caixa preta também faz parte da diversão. Esta justaposição de duas bases de dados extremamente semelhantes, mas incomparáveis, é bastante rara. É como se alguém pensasse: “Firebase é apenas uma função que podemos emular no Google Cloud”, mas ainda não descobriu o conceito de identificar requisitos do mundo real ou de criar soluções úteis que atendam a todos esses requisitos. “Deixe os desenvolvedores pensarem sobre isso. Basta deixar a UI bonita... Você pode adicionar mais fogo?”
Eu entendo algumas coisas sobre estruturas de dados. Definitivamente, vejo o conceito de "tudo em uma grande árvore JSON" como uma tentativa de abstrair qualquer senso de estrutura em grande escala do banco de dados. Esperar que o software simplesmente lide com qualquer fractal duvidoso de estrutura de dados é simplesmente uma loucura. Eu nem preciso imaginar o quão ruim as coisas poderiam ser, fiz auditorias de código rigorosas e Eu vi coisas que vocês nunca sonharam. Mas também sei como são as boas estruturas, и . Posso imaginar um mundo onde o Firestore pareceria lógico e as pessoas que o criaram pensariam que fizeram um bom trabalho. Mas não vivemos neste mundo.
O suporte a consultas do FireBase é ruim em qualquer padrão e é praticamente inexistente. Definitivamente precisa de melhorias ou pelo menos revisão. Mas o Firestore não é muito melhor porque está limitado aos mesmos índices unidimensionais encontrados no SQL simples. Se você precisa de consultas que as pessoas executam em dados caóticos, você precisa de pesquisa de texto completo, filtros de vários intervalos e ordenação personalizada definida pelo usuário. Após uma inspeção mais detalhada, as funções do SQL simples são muito limitadas por si só. Além disso, as únicas consultas SQL que as pessoas podem executar na produção são consultas rápidas. Você precisará de uma solução de indexação personalizada com estruturas de dados inteligentes. Para todo o resto, deve haver pelo menos redução incremental de mapa ou algo semelhante.
Se você pesquisar informações sobre isso no Google Docs, provavelmente será direcionado para algo como BigTable e BigQuery. No entanto, todas essas soluções são acompanhadas por um jargão de vendas corporativo tão denso que você rapidamente voltará atrás e começará a procurar outra coisa.
A última coisa que você deseja com um banco de dados em tempo real é algo feito por e para pessoas em escalas salariais de gerenciamento.
(*) Isso é uma piada, não existe isso .
Como a publicidade
Procurando por para depuração de projetos, um servidor para desenvolvimento e hospedagem? Você é definitivamente nosso cliente 🙂 Preços diários para servidores de diversas configurações, anti-DDoS e licenças Windows já estão incluídos no preço.
Fonte: habr.com