Deja de construir bases de datos

La complejidad de la gestión de datos

• Los ingenieros de frontend terminan dándose cuenta de que necesitan cachear los datos de la API.
• Al principio empiezan con un almacenamiento de datos simple, pero a medida que aumentan las solicitudes de funciones, terminan implementando caché de datos, índices manuales, mutaciones optimistas (optimistic mutations) e invalidación recursiva de caché.
• Estas funciones se parecen al funcionamiento interno de una base de datos y, en aplicaciones frontend complejas, al final se termina construyendo una base de datos especializada para el dominio.

Lo básico del caché

• Todo empieza guardando los resultados de las solicitudes a la API en variables locales.
• En aplicaciones web que usan frameworks declarativos, los datos se guardan en variables para evitar solicitudes innecesarias a la API.
• El siguiente paso es mover el caché a una capa más alta o fuera del árbol de la UI.

Mejorar la velocidad con índices

• Organizar los datos de cierta manera puede reducir el trabajo de la aplicación y mejorar la experiencia del usuario.
• Se descubre que la optimización de datos en frontend se parece al funcionamiento interno del almacenamiento de una base de datos.
• Se mejora la estructura de datos guardándolos por ID y creando índices para consultar rápidamente elementos por fecha.

Mutaciones optimistas

• Consisten en simular localmente el efecto de una acción específica sin esperar la respuesta del servidor.
• Hacen que la interfaz parezca reaccionar de inmediato, pero si el servidor devuelve un resultado distinto, la UI debe revertir los cambios.
• Hay desafíos como duplicar la lógica entre cliente y servidor, manejar errores asíncronos y reconciliar cambios después de reiniciar la aplicación.

Invalidación recursiva de caché

• Los datos aparecen en varias partes del caché, y después de una actualización es necesario invalidarlo correctamente para que coincida con el servidor.
• La UI necesita saber qué partes del caché están relacionadas con cada mutación, y esto puede volverse frágil a medida que crece la escala.
• Cuando se combina con mutaciones optimistas, se vuelve todavía más difícil duplicar la lógica del servidor para predecir los cambios del lado del cliente.

¿Construyendo una base de datos?

• En aplicaciones frontend con suficiente complejidad, al final se terminan construyendo muchas funciones de gestión de datos, lo que quita tiempo de hacer felices a los usuarios y resolver problemas de negocio.
• Se presenta una alternativa: un stack de base de datos optimizado para frontend.

Presentando SQLSync

• Se desarrolló SQLSync, un stack de base de datos optimizado para frontend basado en SQLite.
• SQLSync está diseñado para resolver los problemas de gestión de datos y permitir que los desarrolladores se concentren en las capacidades únicas de su aplicación.
• SQLSync ofrece caché duradero, toda la funcionalidad de SQLite, mutaciones optimistas, invalidación inteligente de caché y consultas reactivas.

La opinión de GN⁺

Lo más importante de este texto es el fenómeno de que, a medida que aumenta la complejidad de las aplicaciones frontend, los desarrolladores terminan implementando por su cuenta funciones similares a las de una base de datos. Este trabajo consume tiempo y los aleja del desarrollo de funciones que realmente aportan valor a los usuarios. Un stack de base de datos optimizado para frontend como SQLSync propone un enfoque innovador para resolver este problema. Lo interesante de este artículo es que señala un problema de fondo en las formas tradicionales de gestionar datos y busca una nueva solución para que los desarrolladores trabajen de manera más eficiente.

[GN⁺]

Opiniones de Hacker News

• Entender al amigo creador del proyecto

  • SQLsync es una herramienta que permite a los desarrolladores frontend consultar y actualizar bases de datos remotas dentro del navegador.
  • Funciona enviando una base de datos SQLite al navegador aprovechando el poder de WASM.
  • Usa un algoritmo reactivo para la sincronización entre múltiples clientes.
  • Es un enfoque innovador para resolver el trabajo de sincronización de datos de los desarrolladores.

• Experiencia con software de gestión de proyectos en una empresa anterior

  • Se sincronizaban los datos usando un mecanismo de check-in/check-out, pero con la aparición de apps con actualizaciones en tiempo real empezó a verse como algo anticuado.
  • Desde la experiencia de haber construido apps web SPA durante 10 años, este tipo de mecanismos de sincronización parece haber estado adelantado a su tiempo.

• Problemas que desaparecen al dejar de usar SPA

  • Con soluciones como Hotwire o htmx, las consultas al servidor se simplifican y el problema de hacerlas rápidas se entiende mejor.

• Opinión del creador de SQLSync

  • Está respondiendo muchas preguntas y planea revisar periódicamente las que se le hayan pasado.
  • Le alegra la discusión sobre la primera publicación, enfocada en la motivación para crear SQLSync.
  • En la siguiente publicación explicará cómo funciona SQLSync.

• No darles a los usuarios un modelo mental distinto de la realidad

  • La sincronización de bases de datos puede ser más compleja que el modelo cliente-servidor.
  • Cuando se necesita una UI rápida, parece más seguro usar primitivas de CRDT.

• El principio de que lo medible es lo que se gestiona y la falacia del costo hundido

  • La complejidad de la base de datos es el problema.
  • El problema es la sintaxis de SQL, y si usar una base de datos relacional básica fuera una experiencia agradable, habría más tentación de usar una DB en vez de construir una base de datos propia.
  • Las buenas bases de datos usan SQL, y para ser eficiente hay que usar el lenguaje de la base de datos.

• El problema de sincronizar estado entre cliente y servidor

  • Volver al modelo de PHP/SSR permite esquivar el problema a costa de sacrificar UX.
  • Las SPA son buenas, pero publicar formularios multipart todavía sigue funcionando.
  • Mantener todo el estado en el servidor y tratar al cliente como una terminal simple mejora la experiencia de desarrollo.

• Comparación con librerías ORM

  • Pregunta sobre cómo se compara SQLsync con usar directamente TypeORM y SQL.js con soporte en el navegador.

• Diferencia entre bases de datos frontend y backend

  • La base de datos del frontend puede ser distinta de la del backend, y en el cliente puede haber necesidad de manejar mejor el estado en tiempo real.
  • Se está considerando usar react query y WebSockets para la invalidación de caché.
  • La idea de SQLsync también vale la pena considerarla.

• Intento similar con SignalDB

  • SignalDB usa reactividad basada en señales y una sintaxis de consultas similar a mongodb, independiente del framework.