Déixame contar unha historia técnica.
Hai moitos anos, estaba a desenvolver unha aplicación con funcións de colaboración incorporadas. Era unha pila experimental amigable que aproveitou todo o potencial dos primeiros React e CouchDB. Sincronizaba os datos en tempo real mediante JSON . Utilizouse internamente dentro da empresa, pero a súa ampla aplicabilidade e potencial noutros ámbitos era evidente.
Mentres tentabamos vender esta tecnoloxía a clientes potenciais, atopamos un obstáculo inesperado. No vídeo de demostración, a nosa tecnoloxía parecía e funcionaba moi ben, sen problemas alí. O vídeo mostraba exactamente como funciona e non imitaba nada. Creamos e codificamos un escenario realista para usar o programa.
De feito, este converteuse no problema. A nosa demostración funcionou exactamente do mesmo xeito que todos simularon as súas aplicacións. En concreto, a información foi transferida instantáneamente de A a B, aínda que se tratara de ficheiros multimedia grandes. Despois de iniciar sesión, cada usuario viu novas entradas. Usando a aplicación, diferentes usuarios podían traballar xuntos claramente nos mesmos proxectos, aínda que a conexión a Internet se interrompese nalgún lugar da vila. Isto está implícito implícito en calquera vídeo de produto cortado en After Effects.
Aínda que todo o mundo sabía para que servía o botón Actualizar, ninguén entendía realmente que as aplicacións web que nos pedían que construíamos adoitaban estar suxeitas ás súas propias limitacións. E que se xa non son necesarios, a experiencia do usuario será completamente diferente. Principalmente notaron que podían "chatear" deixando notas para as persoas coas que estaban falando, polo que se preguntaron en que era diferente de, por exemplo, Slack. Uf!
Deseño de sincronizacións cotiás
Se tes experiencia no desenvolvemento de software, debe ser angustiante lembrar que a maioría da xente non pode simplemente mirar unha imaxe dunha interface e comprender o que fará cando interactúa con ela. Sen esquecer o que ocorre dentro do propio programa. Coñece iso lata suceder é en gran parte o resultado de saber o que non pode pasar e o que non debe ocorrer. Isto require non só o que fai o software, senón tamén como as súas partes individuais se coordinan e se comunican entre si.
Un exemplo clásico disto é un usuario mirando a un fiador.gif, preguntándose cando estará finalmente rematada a obra. O programador entenderase que o proceso probablemente estaba atascado e que o gif nunca desaparecería da pantalla. Esta animación simula a execución dun traballo, pero non está relacionada co seu estado. Nestes casos, a algúns técnicos gústalles botar os ollos en branco, sorprendidos pola extensión da confusión do usuario. Non obstante, fíxate en cantos deles apuntan ao reloxo que xira e din que en realidade está parado?
Esta é a esencia do valor en tempo real. Hoxe en día, as bases de datos en tempo real aínda son moi pouco utilizadas e moitas persoas as ven con desconfianza. A maioría destas bases de datos inclínanse moito polo estilo NoSQL, polo que adoitan empregar solucións baseadas en Mongo, que é mellor esquecer. Non obstante, para min isto significa sentirme cómodo traballando con CouchDB, así como aprender a deseñar estruturas que máis que un burócrata pode encher con datos. Creo que uso mellor o meu tempo.
Pero o verdadeiro tema desta publicación é o que estou usando hoxe. Non por elección, senón polas políticas corporativas aplicadas de forma indiferente e cega. Entón, ofrecerei unha comparación totalmente xusta e imparcial de dous produtos de base de datos de Google en tempo real moi relacionados.
Ambos teñen a palabra Lume nos seus nomes. Unha cousa que recordo con cariño. A segunda cousa para min é un tipo diferente de lume. Non teño présa por dicir os seus nomes, porque unha vez que o faga, atoparémonos co primeiro gran problema: os nomes.
O primeiro chámase Base de datos en tempo real Firebase, e segundo - Firebase Cloud Firestore. Ambos son produtos de Suite Firebase Google. As súas API chámanse respectivamente firebase.database(…) и firebase.firestore(…).
Isto ocorreu porque Base de datos en tempo real - é só o orixinal Base de lume antes da súa compra por Google en 2014. Entón Google decidiu crear un produto paralelo unha copia Firebase baseado nunha empresa de big data e chamouna Firestore cunha nube. Espero que aínda non esteas confundido. Se aínda estás confundido, non te preocupes, eu mesmo reescribín esta parte do artigo dez veces.
Porque hai que indicar Base de lume na pregunta de Firebase e Firestore nunha pregunta sobre Firebase, polo menos para facerche entender hai uns anos en Stack Overflow.
Se houbese un premio á peor experiencia de nomeamento de software, este sería definitivamente un dos candidatos. A distancia de Hamming entre estes nomes é tan pequena que confunde ata os enxeñeiros experimentados cuxos dedos escriben un nome mentres as súas cabezas pensan noutro. Son plans ben intencionados que fracasan estrepitosamente; cumpriron a profecía de que a base de datos estaría en chamas. E non estou de broma. A persoa á que se lle ocorreu este esquema de nomeamento causou sangue, suor e bágoas.
Vitoria pírrica
Un podería pensar que Firestore é substitución Firebase, o seu descendente da próxima xeración, pero iso sería enganoso. Non se garante que Firestore sexa un substituto axeitado para Firebase. Parece que alguén recortou todo o interesante e confundiu a maior parte do resto de varias maneiras.
Non obstante, unha rápida ollada aos dous produtos pode confundilo: parece que fan o mesmo, basicamente a través das mesmas API e mesmo na mesma sesión de base de datos. As diferenzas son sutís e só se revelan mediante un coidadoso estudo comparativo dunha ampla documentación. Ou cando estás tentando portar código que funciona perfectamente en Firebase para que funcione con Firestore. Mesmo entón descobres que a interface da base de datos se ilumina en canto intentas arrastrar e soltar co rato en tempo real. Repito, non estou de broma.
O cliente de Firebase é educado no sentido de que almacena os cambios e tenta automaticamente as actualizacións que dan prioridade á última operación de escritura. Non obstante, Firestore ten un límite de 1 operación de escritura por documento por usuario e segundo, e o servidor aplica este límite. Cando traballes con el, depende de ti atopar un xeito de evitar el e implementar un limitador de taxa de actualización, aínda que só esteas tentando crear a túa aplicación. É dicir, Firestore é unha base de datos en tempo real sen un cliente en tempo real, que se fai pasar por un que usa unha API.
Aquí comezamos a ver os primeiros sinais da razón de ser de Firestore. Pode que me equivoque, pero sospeito que alguén de alto nivel na xestión de Google mirou Firebase despois da compra e simplemente dixo: "Non, Deus, non. Isto é inaceptable. Só non baixo o meu liderado".
Saíu das súas cámaras e declarou:
"Un gran documento JSON? Non. Dividirá os datos en documentos separados, cada un dos cales non terá un tamaño superior a 1 megabyte".
Parece que tal limitación non sobrevivirá ao primeiro encontro con ningunha base de usuarios suficientemente motivada. Xa sabes que é. No traballo, por exemplo, temos máis de mil e medio de presentacións, e isto é Completamente Normal.
Con esta limitación, estarás obrigado a aceptar o feito de que un "documento" da base de datos non se parecerá a ningún obxecto que un usuario poida chamar un documento.
"Matrices de matrices que poden conter recursivamente outros elementos? Non. As matrices só conterán obxectos ou números de lonxitude fixa, como Deus pretendía".
Polo tanto, se esperabas poñer GeoJSON no teu Firestore, descubrirás que isto non é posible. Nada non unidimensional é aceptable. Espero que che guste Base64 e/ou JSON dentro de JSON.
"¿Importar e exportar JSON a través de HTTP, ferramentas de liña de comandos ou panel de administración? Non. Só poderás exportar e importar datos a Google Cloud Storage. Así se chama agora, creo. E cando digo "ti", só me dirixo a aqueles que teñen credenciais de propietario do proxecto. Todos os demais poden ir crear entradas".
Como podes ver, o modelo de datos FireBase é fácil de describir. Contén un enorme documento JSON que asocia claves JSON con rutas URL. Se escribes con HTTP PUT в / FireBase é o seguinte:
{
"hello": "world"
}
O GET /hello volverá "world". Basicamente, funciona exactamente como esperarías. Colección de obxectos FireBase /my-collection/:id equivalente a un dicionario JSON {"my-collection": {...}} na raíz, cuxos contidos están dispoñibles en /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Isto funciona ben se cada inserción ten un ID sen colisións, para o que o sistema ten unha solución estándar.
Noutras palabras, a base de datos é 100% compatible con JSON (*) e funciona moi ben con HTTP, como CouchDB. Pero basicamente úsao a través dunha API en tempo real que abstrae websockets, autorizacións e subscricións. O panel de administración ten ambas as capacidades, permitindo tanto a edición en tempo real como a importación/exportación de JSON. Se fas o mesmo no teu código, sorprenderás a cantidade de código especializado que se desperdiciará cando te decates de que o parche e o diferencial JSON resolve o 90% das tarefas rutineiras de manexar o estado persistente.
O modelo de datos de Firestore é semellante ao JSON, pero difire nalgúns aspectos importantes. Xa mencionei a falta de matrices dentro das matrices. O modelo para as subcoleccións é que sexan conceptos de primeira clase, separados do documento JSON que os contén. Dado que non hai unha serialización preparada para isto, é necesaria unha ruta de código especializada para recuperar e escribir datos. Para procesar as súas propias coleccións, cómpre escribir os seus propios scripts e ferramentas. O panel de administración só permite facer pequenos cambios un campo á vez e non ten capacidades de importación/exportación.
Tomaron unha base de datos NoSQL en tempo real e convertérono nun lento non SQL con unión automática e unha columna separada non JSON. Algo así como GraftQL.
Java quente
Se se suponía que Firestore era máis fiable e escalable, entón a ironía é que o programador medio acabará cunha solución menos fiable que escoller FireBase fóra da caixa. O tipo de software que necesita o administrador de bases de datos Grumpy require un nivel de esforzo e un calibre de talento que non son realistas para o nicho no que se supón que é bo o produto. Isto é semellante a como HTML5 Canvas non é un substituto de Flash se non hai ferramentas de desenvolvemento e reprodutor. Ademais, Firestore está sumido nun desexo de pureza de datos e validación estéril que simplemente non se axusta á forma en que o usuario medio da empresa encántalle traballar: para el todo é opcional, porque ata o final todo é un borrador.
A principal desvantaxe de FireBase é que o cliente foi creado varios anos antes do seu tempo, antes de que a maioría dos desenvolvedores web soubese sobre a inmutabilidade. Debido a isto, FireBase asume que cambiará os datos e, polo tanto, non aproveitará a inmutabilidade proporcionada polo usuario. Ademais, non reutiliza os datos nas instantáneas que pasa ao usuario, o que dificulta moito a diferenza. Para documentos grandes, o seu mecanismo de transacción baseado en diferenzas mutables é simplemente inadecuado. Rapaces, xa o temos WeakMap en JavaScript. É cómodo.
Se dás aos datos a forma desexada e non fai que as árbores sexan demasiado voluminosas, pódese evitar este problema. Pero teño curiosidade por se FireBase sería moito máis interesante se os desenvolvedores lanzaran unha API de cliente moi boa que utilizase a inmutabilidade combinada con algúns consellos prácticos serios sobre o deseño de bases de datos. Pola contra, parecían tentar arranxar o que non estaba roto, e iso empeorou.
Non sei toda a lóxica detrás da creación de Firestore. Especular sobre os motivos que xorden dentro da caixa negra tamén forma parte da diversión. Esta xustaposición de dúas bases de datos moi similares pero incomparables é bastante rara. Como se alguén pensase: "Firebase é só unha función que podemos emular en Google Cloud", pero aínda non descubriu o concepto de identificar requisitos do mundo real ou crear solucións útiles que cumpran todos eses requisitos. "Deixa que os desenvolvedores pensen niso. Fai que a IU sexa fermosa... Podes engadir máis lume?"
Entendo un par de cousas sobre as estruturas de datos. Definitivamente vexo o concepto de "todo nunha gran árbore JSON" como un intento de abstraer calquera sentido de estrutura a gran escala da base de datos. Esperar que o software faga fronte a calquera estrutura de datos dubidosa fractal é simplemente unha locura. Nin sequera teño que imaxinar o mal que poden ser as cousas, fixen auditorías de código rigorosas e Vin cousas que nunca soñaches. Pero tamén sei como son as boas estruturas, и . Podo imaxinar un mundo no que Firestore parecería lóxico e as persoas que o crearon pensasen que fixeron un bo traballo. Pero non vivimos neste mundo.
O soporte de consulta de FireBase é pobre para calquera estándar e é practicamente inexistente. Definitivamente necesita unha mellora ou polo menos unha revisión. Pero Firestore non é moito mellor porque está limitado aos mesmos índices unidimensionales que se atopan en SQL simple. Se precisas consultas que a xente realice sobre datos caóticos, necesitas busca de texto completo, filtros de rango múltiple e ordes personalizadas definidas polo usuario. Tras unha inspección máis atenta, as funcións do SQL simple son demasiado limitadas por si só. Ademais, as únicas consultas SQL que as persoas poden executar en produción son consultas rápidas. Necesitará unha solución de indexación personalizada con estruturas de datos intelixentes. Para todo o demais, debería haber polo menos unha redución de mapas incremental ou algo similar.
Se buscas información sobre isto en Google Docs, esperamos que che indiquen algo como BigTable e BigQuery. Non obstante, todas estas solucións van acompañadas de tanta xerga corporativa de vendas que rapidamente volverás atrás e comezarás a buscar outra cousa.
O último que queres cunha base de datos en tempo real é algo feito por e para persoas en escalas salariais de xestión.
(*) Isto é unha broma, non existe .
Sobre os dereitos da publicidade
Buscar para proxectos de depuración, un servidor para desenvolvemento e hospedaxe? Sen dúbida es o noso cliente 🙂 Os prezos diarios para servidores de varias configuracións, licenzas anti-DDoS e Windows xa están incluídos no prezo.
Fonte: www.habr.com