Déjame contarte una historia técnica.
Hace muchos años, estaba desarrollando una aplicación con funciones de colaboración integradas. Era una pila experimental fácil de usar que aprovechaba todo el potencial de los primeros React y CouchDB. Sincronizó datos en tiempo real vía JSON . Se utilizó internamente dentro de la empresa, pero su amplia aplicabilidad y potencial en otras áreas eran claros.
Al intentar vender esta tecnología a clientes potenciales, nos encontramos con un obstáculo inesperado. En el vídeo de demostración, nuestra tecnología se veía y funcionaba muy bien, no hubo problemas. El vídeo muestra exactamente cómo funciona y no imita nada. Ideamos y codificamos un escenario realista para usar el programa.
De hecho, este se convirtió en el problema. Nuestra demostración funcionó exactamente de la misma manera que todos los demás simularon sus aplicaciones. Específicamente, la información se transfirió instantáneamente de A a B, incluso si se trataba de archivos multimedia de gran tamaño. Después de iniciar sesión, cada usuario vio nuevas entradas. Con la aplicación, diferentes usuarios podían trabajar juntos claramente en los mismos proyectos, incluso si la conexión a Internet se interrumpía en algún lugar del pueblo. Esto está implícitamente implícito en cualquier video de producto cortado en After Effects.
Aunque todos sabían para qué servía el botón Actualizar, nadie entendía realmente que las aplicaciones web que nos pedían que construyéramos generalmente estaban sujetas a sus propias limitaciones. Y que si ya no son necesarios, la experiencia de usuario será completamente diferente. Principalmente notaron que podían “chatear” dejando notas para las personas con las que estaban hablando, por lo que se preguntaron en qué se diferenciaba de, por ejemplo, Slack. ¡Uf!
Diseño de sincronizaciones cotidianas.
Si tiene experiencia en el desarrollo de software, debe ser angustioso recordar que la mayoría de las personas no pueden simplemente mirar una imagen de una interfaz y comprender lo que hará al interactuar con ella. Sin mencionar lo que sucede dentro del propio programa. conocimiento que lata suceder es en gran medida el resultado de saber lo que no puede suceder y lo que no debería suceder. Esto requiere no sólo lo que hace el software, sino también cómo sus partes individuales se coordinan y se comunican entre sí.
Un ejemplo clásico de esto es un usuario que mira fijamente un spinner.gif, preguntándose cuándo finalmente estarán terminadas las obras. El desarrollador se habría dado cuenta de que probablemente el proceso estaba bloqueado y que el gif nunca desaparecería de la pantalla. Esta animación simula la ejecución de un trabajo, pero no está relacionada con su estado. En tales casos, a algunos técnicos les gusta poner los ojos en blanco, asombrados por el grado de confusión del usuario. Sin embargo, ¿observa cuántos de ellos señalan el reloj giratorio y dicen que en realidad está estacionario?
Ésta es la esencia del valor en tiempo real. Hoy en día, las bases de datos en tiempo real todavía se utilizan muy poco y mucha gente las mira con recelo. La mayoría de estas bases de datos se inclinan mucho hacia el estilo NoSQL, por lo que suelen utilizar soluciones basadas en Mongo, que es mejor olvidar. Sin embargo, para mí esto significa sentirme cómodo trabajando con CouchDB, así como aprender a diseñar estructuras que más que un simple burócrata pueda llenar con datos. Creo que estoy usando mejor mi tiempo.
Pero el verdadero tema de esta publicación es lo que estoy usando hoy. No por elección propia, sino debido a políticas corporativas aplicadas de forma indiferente y ciega. Por lo tanto, proporcionaré una comparación completamente justa e imparcial de dos productos de bases de datos en tiempo real de Google estrechamente relacionados.
Ambos tienen la palabra Fuego en sus nombres. Una cosa que recuerdo con cariño. Lo segundo para mí es un tipo diferente de fuego. No tengo prisa por decir sus nombres, porque una vez que lo haga, nos toparemos con el primer gran problema: los nombres.
El primero se llama Base de datos en tiempo real de Firebasey el segundo Firebase Nube Firestore. Ambos son productos de Conjunto de base de fuego Google. Sus API se llaman respectivamente. firebase.database(…) и firebase.firestore(…).
Esto sucedió porque Base de datos en tiempo real - es solo el original Base de fuego antes de su compra por parte de Google en 2014. Entonces Google decidió crear un producto paralelo. copiar Firebase se basó en una empresa de big data y la llamó Firestore con nube. Espero que no estés confundido todavía. Si todavía estás confundido, no te preocupes, yo mismo reescribí esta parte del artículo diez veces.
Porque necesitas indicar Base de fuego en la pregunta de Firebase, y tienda de fuego en una pregunta sobre Firebase, al menos para que entiendas hace unos años en Stack Overflow.
Si hubiera un premio para la peor experiencia de nomenclatura de software, este definitivamente sería uno de los contendientes. La distancia de Hamming entre estos nombres es tan pequeña que confunde incluso a los ingenieros experimentados cuyos dedos escriben un nombre mientras sus cabezas piensan en otro. Se trata de planes bien intencionados que fracasan estrepitosamente; cumplieron la profecía de que la base de datos estaría en llamas. Y no estoy bromeando en absoluto. La persona que ideó este esquema de nombres provocó sangre, sudor y lágrimas.
Victoria pírrica
Uno pensaría que Firestore es reemplazo Firebase, su descendiente de próxima generación, pero eso sería engañoso. No se garantiza que Firestore sea un reemplazo adecuado de Firebase. Parece que alguien eliminó todo lo interesante y confundió la mayor parte del resto de varias maneras.
Sin embargo, un vistazo rápido a los dos productos puede confundirlo: parecen hacer lo mismo, básicamente a través de las mismas API e incluso en la misma sesión de base de datos. Las diferencias son sutiles y sólo se revelan mediante un cuidadoso estudio comparativo de una extensa documentación. O cuando intentas migrar un código que funciona perfectamente en Firebase para que funcione con Firestore. Incluso entonces descubres que la interfaz de la base de datos se ilumina tan pronto como intentas arrastrar y soltar con el mouse en tiempo real. Repito, no estoy bromeando.
El cliente de Firebase es educado en el sentido de que almacena en buffer los cambios y reintenta automáticamente las actualizaciones que dan prioridad a la última operación de escritura. Sin embargo, Firestore tiene un límite de 1 operación de escritura por documento, por usuario y por segundo, y este límite lo aplica el servidor. Al trabajar con él, depende de usted encontrar una manera de evitarlo e implementar un limitador de velocidad de actualización, incluso cuando solo está intentando crear su aplicación. Es decir, Firestore es una base de datos en tiempo real sin un cliente en tiempo real, que se hace pasar por una que utiliza una API.
Aquí empezamos a ver los primeros signos de la razón de ser de Firestore. Puede que me equivoque, pero sospecho que alguien de alto rango en la administración de Google miró Firebase después de la compra y simplemente dijo: “No, Dios mío, no. Esto es inaceptable. Simplemente no bajo mi liderazgo".
Apareció de sus aposentos y declaró:
“¿Un gran documento JSON? No. Dividirás los datos en documentos separados, cada uno de los cuales no tendrá más de 1 megabyte de tamaño”.
Parece que tal limitación no sobrevivirá al primer encuentro con una base de usuarios suficientemente motivada. Sabes que lo es. En el trabajo, por ejemplo, tenemos más de mil quinientas presentaciones, y esto es Completamente Normal.
Con esta limitación, se verá obligado a aceptar el hecho de que un "documento" en la base de datos no se parecerá a ningún objeto que un usuario pueda llamar documento.
"¿Arreglos de arreglos que pueden contener recursivamente otros elementos? No. Las matrices contendrán sólo objetos o números de longitud fija, como Dios quiso".
Entonces, si esperaba poner GeoJSON en su Firestore, encontrará que esto no es posible. Nada que no sea unidimensional es aceptable. Espero que te guste Base64 y/o JSON dentro de JSON.
“¿Importación y exportación de JSON a través de HTTP, herramientas de línea de comandos o panel de administración? No. Solo podrás exportar e importar datos a Google Cloud Storage. Creo que así se llama ahora. Y cuando digo "usted", solo me dirijo a aquellos que tienen credenciales de Propietario de Proyecto. Todos los demás pueden ir y crear tickets".
Como puede ver, el modelo de datos de FireBase es fácil de describir. Contiene un documento JSON enorme que asocia claves JSON con rutas URL. si escribes con HTTP PUT в / FireBase es el siguiente:
{
"hello": "world"
}
Que GET /hello volverá "world". Básicamente, funciona exactamente como cabría esperar. Colección de objetos de FireBase /my-collection/:id equivalente a un diccionario JSON {"my-collection": {...}} en la raíz, cuyo contenido está disponible en /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Esto funciona bien si cada inserción tiene una identificación libre de colisiones, para la cual el sistema tiene una solución estándar.
En otras palabras, la base de datos es 100% compatible con JSON (*) y funciona muy bien con HTTP, como CouchDB. Pero básicamente lo usas a través de una API en tiempo real que abstrae websockets, autorizaciones y suscripciones. El panel de administración tiene ambas capacidades, permitiendo tanto la edición en tiempo real como la importación/exportación JSON. Si hace lo mismo en su código, se sorprenderá de la cantidad de código especializado que se desperdiciará cuando se dé cuenta de que patch and diff JSON resuelve el 90 % de las tareas rutinarias de manejo del estado persistente.
El modelo de datos de Firestore es similar a JSON, pero difiere en algunos aspectos críticos. Ya mencioné la falta de matrices dentro de matrices. El modelo para las subcolecciones es que sean conceptos de primera clase, separados del documento JSON que las contiene. Dado que no existe una serialización lista para usar para esto, se requiere una ruta de código especializada para recuperar y escribir datos. Para procesar sus propias colecciones, necesita escribir sus propios scripts y herramientas. El panel de administración solo le permite realizar pequeños cambios en un campo a la vez y no tiene capacidades de importación/exportación.
Tomaron una base de datos NoSQL en tiempo real y la convirtieron en una lenta no SQL con unión automática y una columna separada no JSON. Algo así como GraftQL.
Java caliente
Si se suponía que Firestore era más confiable y escalable, entonces la ironía es que el desarrollador promedio terminará con una solución menos confiable que elegir FireBase listo para usar. El tipo de software que necesita el administrador de bases de datos Grumpy requiere un nivel de esfuerzo y calibre de talento que es simplemente poco realista para el nicho en el que se supone que es bueno el producto. Esto es similar a cómo HTML5 Canvas no reemplaza a Flash en absoluto si no hay herramientas de desarrollo ni un reproductor. Además, Firestore está sumido en un deseo de pureza de datos y validación estéril que simplemente no se alinea con la forma en que el usuario empresarial promedio le encanta trabajar: para él todo es opcional, porque hasta el final todo es un borrador.
La principal desventaja de FireBase es que el cliente se creó varios años antes de su tiempo, antes de que la mayoría de los desarrolladores web conocieran la inmutabilidad. Debido a esto, FireBase supone que usted cambiará los datos y, por lo tanto, no aprovecha la inmutabilidad proporcionada por el usuario. Además, no reutiliza los datos de las instantáneas que pasa al usuario, lo que dificulta mucho la diferenciación. Para documentos grandes, su mecanismo de transacción mutable basado en diferencias es simplemente inadecuado. Chicos ya tenemos WeakMap en JavaScript. Es cómodo.
Si le da a los datos la forma deseada y no hace que los árboles sean demasiado voluminosos, entonces este problema se puede evitar. Pero tengo curiosidad por saber si FireBase sería mucho más interesante si los desarrolladores lanzaran una API de cliente realmente buena que utilizara la inmutabilidad combinada con algunos consejos prácticos serios sobre el diseño de bases de datos. En lugar de eso, parecían tratar de arreglar lo que no estaba roto, y eso empeoró las cosas.
No conozco toda la lógica detrás de la creación de Firestore. Especular sobre los motivos que surgen dentro de la caja negra también forma parte de la diversión. Esta yuxtaposición de dos bases de datos extremadamente similares pero incomparables es bastante rara. Es como si alguien pensara: "Firebase es sólo una función que podemos emular en Google Cloud", pero aún no ha descubierto el concepto de identificar requisitos del mundo real o crear soluciones útiles que cumplan con todos esos requisitos. “Dejemos que los desarrolladores piensen en ello. Simplemente haz que la interfaz de usuario sea hermosa... ¿Puedes agregar más fuego?
Entiendo un par de cosas sobre estructuras de datos. Definitivamente veo el concepto de "todo en un gran árbol JSON" como un intento de abstraer cualquier sentido de estructura a gran escala de la base de datos. Esperar que el software pueda lidiar simplemente con cualquier fractal de estructura de datos dudosa es simplemente una locura. Ni siquiera tengo que imaginar lo mal que podrían estar las cosas, he realizado rigurosas auditorías de código y Vi cosas que ustedes nunca soñaron. Pero también sé cómo son las buenas estructuras, и . Puedo imaginar un mundo en el que Firestore parecería lógico y las personas que lo crearon pensarían que hicieron un buen trabajo. Pero no vivimos en este mundo.
El soporte de consultas de FireBase es deficiente desde cualquier punto de vista y prácticamente inexistente. Definitivamente necesita mejoras o al menos revisión. Pero Firestore no es mucho mejor porque está limitado a los mismos índices unidimensionales que se encuentran en SQL simple. Si necesita consultas que las personas ejecuten sobre datos caóticos, necesita búsqueda de texto completo, filtros de rango múltiple y ordenamiento personalizado definido por el usuario. Tras una inspección más cercana, las funciones de SQL simple son demasiado limitadas por sí solas. Además, las únicas consultas SQL que las personas pueden ejecutar en producción son las consultas rápidas. Necesitará una solución de indexación personalizada con estructuras de datos bien pensadas. Para todo lo demás, al menos debería haber una reducción de mapa incremental o algo similar.
Si busca información sobre esto en Google Docs, es de esperar que le indiquen algo como BigTable y BigQuery. Sin embargo, todas estas soluciones van acompañadas de una jerga de ventas corporativa tan densa que rápidamente retrocederá y empezará a buscar otra cosa.
Lo último que desea con una base de datos en tiempo real es algo hecho por y para personas en las escalas salariales gerenciales.
(*) Esto es una broma, no existe tal cosa .
Sobre los derechos de publicidad
Buscando para depurar proyectos, un servidor para desarrollo y hosting? Definitivamente eres nuestro cliente 🙂 Los precios diarios para servidores de varias configuraciones, anti-DDoS y licencias de Windows ya están incluidos en el precio.
Fuente: habr.com