Déjame contarte una historia técnica.
Hace muchos años estaba desarrollando una aplicación con funciones de colaboración integradas. Fue una pila experimental útil que aprovechó todo el potencial de los primeros React y CouchDB. Sincronizó datos sobre JSON OT en tiempo real . Se utilizó internamente en la empresa, pero su amplia aplicabilidad y potencial en otras áreas fue evidente.
Al intentar vender esta tecnología a clientes potenciales, encontramos un obstáculo inesperado. En el video de demostración, nuestra tecnología se veía y funcionaba muy bien, sin problemas. El video mostró exactamente cómo funciona, y no se imitó nada en él. Creamos 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 el trabajo de sus aplicaciones. Más específicamente, la información se transfirió instantáneamente de A a B, incluso si se trataba de archivos multimedia grandes. Después de iniciar sesión, cada usuario vio nuevas entradas. Usando la aplicación, diferentes usuarios podrían colaborar en exactamente los mismos proyectos, incluso si la conexión a Internet se interrumpió en algún lugar de la aldea. Esto está implícitamente implícito en cualquier video de producto cortado en After Effects.
Aunque todo el mundo sabía para qué era el botón Actualizar, nadie entendió que las aplicaciones web que nos piden que creemos suelen estar sujetas a sus propias limitaciones. Y que si ya no son necesarios, la experiencia del usuario será completamente diferente. Básicamente, notaron que se puede "chatear" dejando notas a los interlocutores, por lo que se preguntaron en qué se diferencia, por ejemplo, de Slack. ¡Uf-f-f!
Diseño de sincronización diaria
Si ya tiene experiencia en el desarrollo de software, debería ponerle de los nervios recordar que la mayoría de la gente no puede simplemente mirar una imagen de una interfaz y descubrir qué hará al interactuar con ella. Sin mencionar lo que sucede dentro del programa en sí. Saber lo que puede suceder es en gran medida el resultado de saber lo que no puede y no debe suceder. Esto requiere un modelo mental no solo de lo que hace el software, sino también de cómo sus partes individuales se coordinan y se comunican entre sí.
Un ejemplo clásico de esto es un usuario que mira spinner.gif durante veinte minutos.preguntándose cuándo finalmente terminará el trabajo. El desarrollador entendería que el proceso probablemente esté congelado y que el gif nunca desaparecerá de la pantalla. Esta animación simula la ejecución del trabajo, pero no está asociada a su estado. En casos como este, a algunos técnicos les gusta poner los ojos en blanco, maravillados por el grado de confusión del usuario. Sin embargo, observe cuál de ellos apunta al reloj giratorio y dice que en realidad están estacionarios.
Ésta es la esencia del valor en tiempo real. Las bases de datos en tiempo real todavía se utilizan muy poco en estos días y muchos sospechan de ellas. La mayoría de estas bases de datos se inclinan activamente hacia el estilo NoSQL, razón por la cual suelen utilizar soluciones basadas en Mongo, que es mejor olvidar. Sin embargo, para mí significa la comodidad de trabajar con CouchDB, así como el estudio de diseñar estructuras que no solo algún burócrata podrá llenar con datos. Creo que paso mejor mi tiempo.
Pero el tema real de esta publicación es lo que estoy usando hoy. No por elección, sino por la política corporativa aplicada indiferente y ciegamente. Así que le daré una comparación perfectamente honesta e imparcial de dos productos de base de datos en tiempo real de Google estrechamente relacionados.
Ambos tienen la palabra Fuego en sus nombres. Una cosa que recuerdo con cariño. El segundo para mí es un tipo diferente de fuego. No tengo prisa por decir sus nombres, porque tan pronto como lo hago, nos enfrentamos al primer gran problema: los nombres.
El primero se llama Firebase Real-Time Database y el segundo es Firebase Cloud Firestore . Ambos son productos de la suite Firebase de Google. Sus API se denominan, respectivamente,
firebase.database(…)y firebase.firestore(…).
Esto se debe a que Real-Time Database es solo el Firebase original antes de que Google lo comprara en 2014. Entonces Google decidió crear una copia deFirebase basado en el big data de la empresa y lo llamó Firestore con una nube. Espero que no estés confundido todavía. Si se confunde, no se preocupe, yo mismo he reescrito esta parte del artículo diez veces.
Porque Firebase debe citarse en la pregunta de Firebase y Firestore en la pregunta de Firebase, al menos para que se entienda hace unos años en Stack Overflow.
Si hubiera un premio al peor nombre de productos de software, entonces este caso definitivamente se convertiría en 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, aunque la cabeza piensa en otro. Estos son planes que fracasaron estrepitosamente, inventados con las mejores intenciones; cumplieron la profecía de que la base de datos estaría en llamas. Y no estoy bromeando. El hombre que ideó este esquema de nombres causó sangre, sudor y lágrimas.
victoria pírrica
Uno pensaría que Firestore es un reemplazo de Firebase, su descendiente de próxima generación, pero eso sería un error. Se garantiza que Firestore no sustituirá a Firebase. Parece que alguien le quitó todo lo interesante y confundió a la mayor parte del resto de diferentes maneras.
Sin embargo, un vistazo rápido a los dos productos puede resultar confuso: parecen estar haciendo lo mismo, principalmente a través de las mismas API, e incluso en la misma sesión de base de datos. Las diferencias son sutiles y solo salen a la luz con un estudio comparativo minucioso de la extensa documentación. O al intentar transferir un código que funciona perfectamente a Firebase para que funcione con Firestore. Incluso entonces, se da cuenta de que la interfaz de la base de datos se ilumina tan pronto como intenta arrastrar y soltar en tiempo real. Una vez más, no estoy bromeando.
El cliente de Firebase es educado en el sentido de que almacena los cambios y reintenta automáticamente las actualizaciones, dando prioridad a la última escritura. Sin embargo, Firestore tiene un límite de 1 operación de escritura por documento por usuario por segundo, y este límite lo impone el servidor. Cuando trabaje con él, usted mismo debe encontrar una manera de evitarlo e implementar un limitador de frecuencia de actualización, incluso cuando solo está tratando de construir 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 API.
Con esto comenzamos a ver los primeros signos del significado de la existencia de Firestore. Puede que me equivoque, pero sospecho que alguien de alto nivel en el liderazgo de Google miró después de comprar en Firebase y simplemente dijo: “No, Dios mío, no. Esto es inaceptable. Solo que no bajo mi liderazgo ".
Salió de sus aposentos y proclamó:
“¿Un gran documento JSON? No. Dividirá 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 razonablemente motivada. Sabes que lo es. En el trabajo, por ejemplo, tenemos más de mil quinientas presentaciones, y esto es Perfectamente Normal.
Con esta limitación, tendrá que aceptar el hecho de que un "documento" en la base de datos no será como ningún objeto que el usuario llamaría documento.
“¿Matrices de matrices que pueden contener recursivamente otros elementos? No. Las matrices solo contendrán objetos o números de longitud fija como el Señor pretendía ".
Entonces, si esperaba poner GeoJSON en su Firestore, encontrará que esto no es posible. No se permite nada que no sea uniforme. 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á exportar e importar datos a Google Cloud Storage. Así parece que se llama ahora. Y cuando digo "usted", me refiero solo a aquellos que tienen poderes de Propietario del Proyecto. Todos los demás pueden ir y crear entradas ".
Como puede ver, el modelo de datos de FireBase es fácil de describir. Contiene un documento JSON enorme que vincula las claves JSON a las rutas URL. Si escribe lo siguiente
HTTP PUTen /FireBase:
{
"hello": "world"
}Se
GET /hellovolverá "world". Básicamente, funciona exactamente como cabría esperar. Una colección de objetos FireBase es /my-collection/:idequivalente 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 inserto tiene un ID de no colisión, para lo 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 principalmente lo usa a través de una API en tiempo real que abstrae websockets, autorizaciones y suscripciones. El panel de administración tiene ambas capacidades, lo que permite la edición en tiempo real y la importación / exportación JSON. Si sigue con lo mismo en su código, se sorprenderá de la cantidad de código personalizado que se desperdicia cuando se dé cuenta de que Patch y diff JSON resuelven el 90% de las tareas rutinarias de estado persistente.
El modelo de datos de Firestore es similar a JSON, pero difiere de él en algunos aspectos críticos. Ya mencioné la falta de matrices dentro de las matrices. El modelo de subcolecciones debe ser conceptos de primera clase separados del documento JSON que lo contiene. Dado que no existe una serialización lista para usar para esto, se requiere una ruta de código especializada para obtener y escribir datos. Para procesar sus propias colecciones, debe 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 columna lenta sin SQL con unión automática y una columna separada sin JSON. Algo en el espíritu de GraftQL .
Java caliente
Si Firestore se volviera más confiable y escalable, la ironía es que el desarrollador promedio obtendrá una solución menos confiable que elegir FireBase lista para usar. El software que necesita el malhumorado administrador de bases de datos requiere tal nivel de esfuerzo y calibre de especialistas que es simplemente poco realista para un nicho en el que se supone que el producto es bueno. Esto es similar a cómo HTML5 Canvas no reemplaza en absoluto a Flash si no hay herramientas de desarrollo y un reproductor. Además, Firestore está atascado en una búsqueda de limpieza de datos y validación estéril, lo que simplemente no está en línea con la forma en que le gusta trabajar al usuario comercial promedio : para él todo es opcional, porque todo es un borrador hasta el final.
La principal desventaja de FireBase es que el cliente se creó varios años antes, incluso antes de que la mayoría de los desarrolladores web supieran acerca de la inmutabilidad. Debido a esto, FireBase asume que modificará los datos y, por lo tanto, no aprovecha la inmutabilidad proporcionada por el usuario. Además, no reutiliza los datos en las instantáneas enviadas al usuario, lo que dificulta mucho el diff. Para documentos grandes, su mecanismo de transacción basado en diferencias mutables es simplemente inadecuado. Chicos, ya tenemos
WeakMapJavaScript. Es cómodo.
Al dar forma a los datos según sea necesario y no hacer que los árboles sean demasiado voluminosos, este problema puede evitarse. Pero tengo curiosidad por saber si FireBase sería mucho más interesante si los desarrolladores presentaran una API de cliente realmente buena que utiliza la inmutabilidad combinada con algunos consejos sólidos y prácticos sobre el diseño de bases de datos. En cambio, parece que intentaron arreglar lo que no estaba roto y eso lo empeoró.
No conozco toda la lógica detrás de la creación de Firestore. Razonar sobre los motivos que surgen dentro de la caja negra también es parte de la diversión. Esta yuxtaposición de dos bases de datos extremadamente similares pero incomparables es bastante rara. Como si alguien estuviera pensando, "Firebase es solo una función que podemos emular en Google Cloud".pero todavía no he descubierto el concepto de definir requisitos del mundo real o crear soluciones útiles que satisfagan todos estos requisitos. “Dejemos que los desarrolladores lo piensen. Simplemente haz que la interfaz de usuario sea bonita ... ¿Puedes agregar más fuego? "
Entiendo un par de cosas sobre las estructuras de datos. Puedo ver claramente que el concepto de "todo en un gran árbol JSON" es un intento de abstraer de la base de datos cualquier sentido de estructura a gran escala. Esperar que el software simplemente maneje cualquier fractal de estructura de datos cuestionable es una locura. Ni siquiera necesito imaginar lo malo que puede ser todo, realicé auditorías de código rigurosas y vi algo con lo que ustedes nunca soñaron . Pero también sé cómo son las buenas estructuras, cómo usarlas ypor qué debería hacerse . Puedo imaginar un mundo en el que Firestore parecería bastante lógico y las personas que lo crearon pensaron que hicieron un buen trabajo. Pero no vivimos en este mundo.
El soporte para la construcción de consultas en FireBase es malo según los estándares, prácticamente no existe. Definitivamente necesita una mejora o al menos una revisión. Pero Firestore no es mucho mejor, ya que se limita a los mismos índices 1D que se encuentran en SQL simple. Si desea que las personas realicen consultas sobre datos caóticos, entonces necesita una búsqueda de texto completo, filtros en múltiples rangos y un orden arbitrario definido por el usuario. En una inspección más cercana, las funciones de SQL simple son demasiado limitadas por sí mismas. Además, las únicas consultas SQL que los humanos pueden ejecutar en producción son las consultas rápidas. Necesitará una solución de indexación especializada con estructuras de datos sofisticadas. 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 los documentos de Google, es de esperar que se le indique algo como BigTable y BigQuery. Sin embargo, todas estas decisiones van acompañadas de tal volumen de jerga de ventas corporativas tan espesa que rápidamente volverá y comenzará a buscar otra cosa.
Lo último que necesita en el caso de una base de datos en tiempo real es algo creado por humanos y para personas que trabajan en una escala salarial para el liderazgo.
(*) Esto es una broma, no existe la compatibilidad 100% JSON .
Publicidad
¿Busca un VDS para depurar proyectos, un servidor para desarrollo y despliegue? Definitivamente eres nuestro cliente :) La facturación diaria de servidores de varias configuraciones, licencias anti-DDoS y Windows ya están incluidas en el precio.
