Local First App Development

Hola a todos, mi nombre es Anselm y hoy me gustaría hablarles sobre LocalThirst, una nueva forma loca de construir aplicaciones. Si queremos construir una aplicación, es como, tengo una nueva idea, quiero construir esta aplicación, ¿verdad? Usualmente lo que pensamos que necesitamos hacer es algo como esto, ¿verdad? Tendremos un front end, un backend, alguna base de datos, y tal vez tendremos que interactuar con algunas APIs de Excel.

Pero desafortunadamente, la realidad hoy en día se ve más como esto. Se ha vuelto realmente, realmente complicado y estamos muy lejos del simple modelo tradicional de cliente-servidor. Y empeora estos días debido a aplicaciones de alta fidelidad como Figma y Notion, o incluso Google Docs, los usuarios hoy en día esperan todo tipo de características avanzadas como multijugador en tiempo real, sincronización entre dispositivos. Cada vez más personas están comenzando a esperar que las aplicaciones funcionen sin conexión. Quieres poder compartir contenido en una aplicación y definir permisos complejos. Y si empiezas a pensar en cómo agregar estas cosas aún más complicadas a esta pila ya complicada, se vuelve realmente difícil. Como si quisiéramos multijugador en tiempo real, ¿dónde necesitamos agregar eso? Afectará el front end, afectará el backend, afectará la base de datos. Ninguna de las tecnologías tradicionales aquí está realmente hecha para eso. De manera similar, si queremos agregar soporte sin conexión, ¿es eso solo una cosa de front end? ¿Afectará el estado de la UI? También tenemos que pensar en eso en el backend. Es realmente poco claro. La sincronización entre dispositivos también se vuelve realmente complicada. Y si queremos hacer algún tipo de compartición entre usuarios, eso realmente afecta a todas las partes de nuestra aplicación. Y simplemente se vuelve más y más complicado. Y mi favorita, algo tan simple como las cargas de archivos de usuario, que es como radical, ¿verdad? Incluso solo implementar eso, si has tenido que implementarlo en aplicaciones, toca todo y es mucho más complicado de lo que debería ser. Así que todas estas cosas que los usuarios ahora dan por sentado son como incómodas hasta realmente difíciles de construir.

Entonces, si miras este diagrama también, el código específico de tu aplicación está realmente por todas partes. Y se convierte en algo realmente complicado. Tienes que tomar todas estas decisiones tecnológicas, como cómo vas a representar el estado de la UI. ¿Qué pasa con, cómo hablas con tu backend? ¿Tienes alguna biblioteca de consultas, RPCs? ¿Qué usas para auth? ¿Hablas directamente con la base de datos o quieres usar algún ORM? Tal vez por rendimiento necesitas un caché. Probablemente necesites algo como una cola de mensajes para ciertos tipos de tareas, particularmente para hablar con APIs externas. Y necesitas desplegar todo eso. Y por supuesto, hay soluciones simplificadas que te dan cualquier combinación de estos como un paquete, pero internamente todavía se ven igual de complicadas.

Y si ampliamos un poco aquí y dejamos de pensar en términos de los patrones que estamos acostumbrados a dar por sentado que así es como se construyen las aplicaciones y necesitas todas estas cosas, ¿qué hace realmente una pila? Y diría que cada pila realmente solo implementa un estado compartido entre usuarios y dispositivos. Y por alguna razón tienes que construir eso a mano cada vez, una y otra vez. Y nota aquí que no me refiero a, sí, nuevas aplicaciones con estas características geniales como multijugador en tiempo real, incluso pilas aburridas para aburridas como web 2.0, aplicaciones tipo SaaS. Todo lo que realmente hacen es implementar un estado compartido entre usuarios y dispositivos. Así que tal vez una solución para ayudarnos a salir de este lío es ¿qué pasaría si pudiéramos construir herramientas generales con estado compartido entre usuarios en mente desde el principio?

He construido muchas aplicaciones web. En mi experiencia, he sido como un consultor full-stack durante algo así como 13, 14 años, dependiendo de cómo lo cuentes para cada aplicación que he construido, he tenido que construir esta pila solo para obtener un estado compartido. Y solo entonces podría comenzar a construir las partes específicas de la aplicación. Y nunca supe realmente cómo resolver esto hasta que descubrí esta nueva forma de construir aplicaciones que respondió a mi pregunta de qué pasaría si pudiéramos hacerlo de una manera diferente. Y esta forma de construir aplicaciones se llama local first. Así es como se ve una infraestructura local first, mucho más simple. Básicamente tienes tu front end, que solo habla con el estado local y obtienes esta experiencia de construir como una buena aplicación offline de la vieja escuela. Pero luego tu estado local se sincroniza con otros dispositivos, con otros usuarios, e incluso con trabajadores de back end de una manera generalizada a través de lo que yo llamaría una infraestructura de sincronización y almacenamiento.

Descargo de responsabilidad aquí, muchas de las formas en que voy a explicar estas cosas están ligeramente sesgadas porque estamos construyendo un framework para construir aplicaciones local first. Así que esto será opinado y podrías preguntar, ¿quiénes somos nosotros? Bueno, soy yo y mi equipo en Garden Computing, y estamos construyendo Jazz, que es un framework para construir aplicaciones local first. Y también estamos ejecutando JazzCloud, que es infraestructura de sincronización y almacenamiento como servicio para aplicaciones construidas con Jazz. Así que esto básicamente significa que la parte de infraestructura de sincronización y almacenamiento allá arriba es ya sea JazzCloud o autoalojada. Y realmente quiero subrayar eso porque no quiero que pienses que esta charla está súper sesgada porque soy un proveedor de este tipo de cosas. Es todo de código abierto. Puedes ejecutarlo tú mismo. Creo que es simplemente conveniente usar algo como JazzCloud. Pero la imagen general es esta. Y la parte más importante y poderosa para mí en comparación con la pila tradicional es esta parte que, al decir que trabajas con estado local, que se sincroniza de una manera generalizada, significa que tu código específico de la aplicación realmente solo vive en esta parte de aquí abajo. Solo tienes que construir tu front end y tal vez algunos trabajadores de back end para hablar con APIs externas.

De hecho, hay muchos tipos de aplicaciones que puedes construir solo con código de front end. Ahora solo tienes que tomar tres decisiones tecnológicas o incluso menos. Y tienes muy poco que desplegar porque, de nuevo, solo podrías necesitar desplegar un front end estático y tal vez algunos trabajadores de back end ligeros, no toda una pila.

¿Cómo puede ser esto posible? El primer ingrediente que tuve que descubrir que realmente me dio la idea de construir un framework como este y que me hizo pensar de esta manera diferente es algo llamado CRDTs. Puede que hayas oído hablar de ellos o no. La abreviatura significa tipos de datos replicados sin conflictos. Y una forma muy rápida y simple de pensar en ellos es que son Git para datos.

Para ser más preciso, es un Git súper rápido para muchos datos pequeños. Y puedes ejecutarlo en el cliente. Y eso es realmente lo que hace que cosas difíciles como de las que hablé antes, sean realmente fáciles de repente. Por ejemplo, multijugador en tiempo real. Bueno, y si tienes un Git súper rápido para muchos datos pequeños, creo que puedes imaginar cómo podrías construir experiencias multijugador en tiempo real sobre eso. Simplemente compartes las ediciones y todos terminarán con los mismos datos y puedes hacer eso en tiempo real. Podrías estar preguntando, bueno, parte del multijugador en tiempo real es tener presencia de usuario, así que puedes ver los cursores de otros usuarios y demás. ¿Cómo añadirías eso? Bueno, los cursores son realmente solo más datos pequeños, así que simplemente también los pones en el CRDT y es súper rápido, así que puedes ver los cursores de otras personas u otros tipos de presencia de usuario en tiempo real. Así que, multijugador en tiempo real y presencia resueltos.

¿Qué hay de la sincronización entre dispositivos? Bueno, si piensas en cómo usas Git, podrías trabajar en el mismo repositorio en diferentes dispositivos y luego simplemente usar empujes y tirones explícitos para llegar al mismo estado en todas partes. Y lo mismo es cierto para los CRDTs, excepto que sucede automáticamente en tiempo real. Soporte offline, misma historia. Por supuesto, puedes usar Git offline. Puedes trabajar sin internet, hacer algunos commits, subirlos y todo funciona y los CRDTs son exactamente lo mismo. De nuevo, porque es un Git súper rápido para muchos datos pequeños.

Si lo piensas, si trabajas offline en múltiples dispositivos simultáneamente o si diferentes personas trabajan offline en los mismos datos, inevitablemente te encontrarás con conflictos. Y aquí es donde entra la última propiedad realmente importante de los CRDTs, que es que básicamente tienen una fusión automática razonable incorporada. Así que, incluso si te desconectas, vuelves a conectarte, tus cambios se sincronizan, la mayoría de los conflictos se resolverán de una manera que esperarías como usuario. E incluso esta idea radical de cargas de archivos de usuario también se vuelve súper simple porque no puedes solo almacenar muchos datos pequeños en los CRDTs, en realidad también puedes almacenar datos grandes en ellos. Y luego esos datos grandes se sincronizan y comparten entre los usuarios al igual que todo lo demás. Así que, las cargas de archivos de usuario también son muy fáciles. Y podrías empezar a ver que aunque la arquitectura es muy diferente y podría parecer como esta loca nueva forma de construir aplicaciones, realmente quiero convencerte hoy de que es en realidad la única manera sensata de construir aplicaciones hoy en día.

Podrías estar preguntándote a continuación, bueno, ¿cómo funciona el compartir y cómo funcionan los permisos en este tipo de contexto? Y tradicionalmente haces esto aplicándolos de manera centralizada en el backend en el límite de la API.

Aquí realmente no tenemos un límite de API, entonces, ¿cómo funciona eso? Lo que me lleva al segundo ingrediente, la criptografía de clave pública. Una forma simple de describir la criptografía de clave pública es que significa que puedes cifrar datos específicamente para alguien y solo ellos pueden descifrarlos. Y puedes firmar datos como alguien específico, por lo que obtienes una especie de autoría verificable. Y también puedes hacer esto en el cliente.

Así que esto nos permite combinar nuestros dos ingredientes, CRDTs y criptografía de clave pública, lo que significa que en lugar de solo cifrar datos estáticos y firmar datos estáticos, podemos cifrar diferencias y firmar diferencias. Cifrar las diferencias significa que solo las personas que queremos que vean nuestros cambios o nuestros objetos pueden verlos, por lo que efectivamente implementamos acceso de lectura. Y al firmarlos, otras personas pueden verificar que las ediciones que se están sincronizando son de personas que realmente tienen permiso para escribir en este objeto. Así es como se ve el compartir y los permisos complejos en este mundo.

Y muchas de estas cosas, como viste, que solían ser incómodas o realmente difíciles ahora son realmente fáciles. E incluso hay una cosa que no había mencionado antes, el cifrado de extremo a extremo, que era simplemente imposible en una arquitectura tradicional. Muchas de estas, y eso es posible ahora porque, nuevamente, estamos usando criptografía de clave pública y tenemos esta forma verificable de control de acceso que nos permite hacer cifrado de extremo a extremo y ediciones verificables. Esto significa que si miramos nuestro gráfico de infraestructura para una pila local first nuevamente, en realidad solo los trabajadores de front-end y back-end ven los datos de nuestros usuarios en texto plano, y toda la infraestructura de sincronización y almacenamiento no es de confianza, lo siento, es libre de confianza, lo que significa que incluso si eliges usar Jazz Cloud en lugar de usar tu servidor de sincronización autoalojado, tú no tienes que confiar en mí con los datos de tus usuarios. Tus usuarios no tienen que confiar en mí con los datos de tus usuarios. Y si no tienes ningún trabajador de back-end, porque no necesitas hablar con APIs externas, puedes realmente construir aplicaciones completamente cifradas de extremo a extremo donde ni siquiera tú puedes ver los datos en texto plano de tus usuarios. Muchas de estas, y la razón por la que construí esto en Jazz es porque realmente creo que local first es mejor si la identidad y los permisos del usuario también son local first, porque eso es lo que realmente es la criptografía de clave pública. Es identidad y permisos del usuario local first.

Ahora, si hablas con algunas otras personas de local first, podrían decir, sí, bueno, eso es solo como tu opinión. Y esa es realmente una gran manera de dividir el espacio local first. Por un lado, tenemos frameworks como Jazz o Evolu o DXOS, donde les gusta que muchos de estos permisos y la identidad de usuario local first basada en criptografía realmente pertenezcan junto con el estado compartido de local first. Por otro lado, tienes frameworks como Electric o Zero Sync o InstantDB, que usan CRDTs, pero luego dependen de una infraestructura centralizada más tradicional para hacer cumplir los permisos en el límite de la API. Y luego muchas de las bibliotecas de código abierto con todos los servicios adjuntos a ellas, como AutoMerge, Yjs y Laurel, realmente solo implementan los CRDTs y dejan los permisos y la autenticación a ti. Usualmente incluso dejan la sincronización a ti.

Así que podrías estar curioso ahora, bueno, está bien, más o menos entiendo la arquitectura general de la pila. ¿Cómo se ve realmente construir aplicaciones de esta manera? Y de nuevo, descargo de responsabilidad, te mostraré cómo se ve construir aplicaciones con Jazz. Podría verse ligeramente diferente con otros frameworks porque otra gran manera de dividir el espacio emergente local first es por cómo se ve construir aplicaciones con él. Y aproximadamente diría que a la izquierda, tienes estos frameworks donde parece que estás simplemente editando el estado JSON y se siente mucho como un estado de uso de React que puedes escribir y luego se sincroniza mágicamente con otros dispositivos. Y en el lado derecho, tienes herramientas que son más como traer la base de datos al cliente y harías mutaciones y consultas en el cliente. Jazz está en el lado izquierdo. Así que eso es lo que los ejemplos aquí parecerán.

Descargo de responsabilidad final, te mostraré como la versión de React de Jazz. Ya soportamos usarlo con Vanilla JS y lo siento, debería decir que Vue y Suave están llegando pronto. Pero es muy simple. El primer paso es configurar un contexto y sincronización, que es solo un proveedor simple aquí donde puedes elegir entre diferentes métodos de autenticación que están integrados en Jazz. Aquí estamos usando autenticación de demostración porque eso te permite iniciar sesión rápidamente como diferentes usuarios y puedes probar rápidamente las características de multijugador y compartir. Puedes ver que básicamente lo único realmente importante aquí es que especificamos una conexión WebSocket al par de sincronización que queremos y hacemos un poco de manejo de estado para la autenticación, ¿verdad? Envolvemos toda nuestra aplicación en este proveedor y luego definimos un esquema, que es realmente la parte más importante de construir cualquier aplicación Jazz donde defines el modelo de datos que realmente hace tu aplicación, tu aplicación. Así que digamos que queremos construir una pequeña aplicación de chat. Así que realmente solo necesitamos dos clases aquí, una para el mensaje que solo tiene un campo de texto que es una cadena. Y luego decimos que el chat es solo una lista colaborativa o co-lista de mensajes, ¿verdad? Tanto el mensaje como la lista de CRDTs, el mensaje es uno que parece un mapa con campos que las personas pueden editar colaborativamente. El chat es una lista donde las personas pueden insertar mensajes colaborativamente.

Una vez que tenemos eso, podemos simplemente crear un objeto de chat y parece un objeto local simple. Pero tan pronto como haces este chat.create, en realidad persiste este objeto de chat localmente en tu navegador y se sincroniza con la infraestructura de sincronización y almacenamiento donde se almacena como almacenamiento en la nube y luego otras personas pueden referenciarlo y suscribirse a él. Así que una vez que tienes un chat, podemos usar este gancho use costate para suscribirse a los cambios en él. En JavaScript puro, habría un ejemplo como chat.subscribe y obtienes un callback que se llama. En este caso, este componente se volverá a renderizar cada vez que el chat cambie. Y lo genial aquí es que se volverá a renderizar o tu suscripción será llamada no solo cuando el chat cambie debido a cambios locales, sino también cuando recibas cambios de otros dispositivos u otras personas que se están sincronizando. Así que se vuelve muy, muy fácil construir aplicaciones. Básicamente solo construyes la interfaz de usuario alrededor de estos valores colaborativos y te suscribes a los cambios en ellos.

El chat en realidad se ve como un JSON simple, por lo que podemos mapear los mensajes en él y luego simplemente renderizar el mensaje en un componente. Y para que te hagas una idea, ahora podrías preguntarte, ¿cómo se ve editar algo como una lista colaborativa? Bueno, puedes ver en esta entrada de chat, cuando el usuario presiona enter en su nuevo mensaje, literalmente solo creamos un nuevo mensaje y luego lo empujamos al chat. Finalmente, para mostrarte cómo se ve esta criptografía de clave pública que suena complicada al usarla en Jazz, es realmente simple. Hay una abstracción llamada grupos donde puedes agregar cuentas o, en este caso, a todos con un rol específico. Y luego, cuando creas un valor colaborativo como el chat aquí, especificas un grupo como propietario. Y de esa manera determinas los derechos de acceso sobre ese objeto basado en los roles, diferentes cuentas o todos tienen en el grupo. Eso es todo lo que necesitas hacer. Es básicamente permisos al estilo Dropbox para cualquier objeto que crees. Puedes definir todo eso localmente. Puedes ver esta función de crear chat aquí. Literalmente estoy llamando a eso en un botón al hacer clic. Así que puedes configurar todo eso, los grupos al igual que los objetos en ellos se sincronizarán y se persistirán en la nube. Y puedes manejarlos como objetos locales.

El último tema un poco más complicado es, bueno, probablemente tu aplicación cambiará con el tiempo. Así que podrías necesitar cambiar el esquema. Y aquí adoptamos una idea de las bases de datos llamada migraciones, excepto que son un poco más complicadas. Porque si lo piensas, los clientes podrían estar desconectados. Su lealtad podría ejecutarse simultáneamente en diferentes dispositivos ahora en lugar de en una base de datos centralizada. Así que esta es probablemente la parte más difícil, nueva y complicada de Local First. Pero en nuestra experiencia hasta ahora, está bien. Solo necesitas ser cuidadoso. Y estamos descubriendo los patrones que puedes seguir para asegurarte de que funcione bien. Y luego en el futuro, podríamos introducir medidas de protección para realmente asegurarnos de que no puedas hacer nada mal con ellas. Así que probablemente para mí, el lema de Local First no es solo que las cosas difíciles son fáciles ahora. Algunas cosas son un poco complicadas ahora, pero básicamente vale totalmente la pena.

Podrías estar preguntándote, bueno, has explicado un poco la parte del front end, cómo se ve eso. Lo bueno es que los trabajadores de backend funcionan de la misma manera. Porque en el modelo Local First, si tienes un trabajador de backend que quieres que haga cosas como hablar con una API externa, simplemente se convierten en otro cliente para la infraestructura de sincronización y almacenamiento. Así que pueden ejecutarse donde quieras. Simplemente se suscriben al mismo estado que tienes en tu front end. Ni siquiera tienes que hacer llamadas explícitas a la API. Solo tienes esta tela compartida de datos que puedes editar y a la que puedes suscribirte.

Y en el caso de Jazz en particular, los trabajadores del servidor en realidad tienen pequeñas cuentas al igual que los usuarios. Así que puedes darles acceso preciso a ciertos tipos de datos. Y nuevamente, está criptográficamente asegurado que solo pueden ver y solo editar los datos a los que les das acceso. Así que eso se vuelve mucho más preciso y verificable.

Permíteme mostrarte rápidamente algunas aplicaciones que la gente ya está construyendo con Jazz, solo para que te hagas una idea de lo versátil que es. Esta es una aplicación llamada Invoice Rater. Están construyendo una herramienta que inicia sesión en diferentes proveedores de nube como AWS, CloudFlare con tus credenciales, descarga todas tus facturas y las recopila para que puedas fácilmente enviarlas a las autoridades fiscales, por ejemplo. Este es un gran ejemplo de una aplicación que simplemente no podrías construir con infraestructura tradicional porque tienes que confiarle tus credenciales de usuario para todas estas plataformas. Pero como está construida con Jazz de una manera local first usando permisos local first, está en realidad todo cifrado de extremo a extremo y obtienes todos los beneficios agradables de una aplicación offline donde posees los datos y sabes exactamente lo que sucede. Pero también obtienes almacenamiento en la nube y sincronización entre dispositivos.

Una aplicación completamente diferente llamada Learn Anything. Ya está lanzada. Puedes ir a verla. Es esta plataforma de aprendizaje realmente genial donde si estás interesado en algún tema, como si quieres aprender desarrollo de front end o cómo tocar la guitarra, simplemente vas a Learn Anything, ingresas tu tema y luego obtienes una lista de enlaces y material enviados por usuarios y cuidadosamente curados para aprender ese tema. Luego puedes rastrear tu progreso a medida que avanzas por diferentes pasos y progresas en ese tema. Pero también puedes enviar tu propio material. De esta manera, es básicamente como una red social con muchos usuarios interactuando. Reciben una gran cantidad de visitantes por primera vez cada semana, creo que varios millones. Así que porque eligieron usar Jazz para toda su pila, significa que Jazz, en su caso, funciona mucho más como una base de datos tradicional y tiene que servir a todos estos usuarios por primera vez con muchos objetos para sincronizar en cada carga. Y pudimos hacer que se estirara para eso, lo que realmente validó mi esperanza de que local first no es solo una forma de nicho para construir ciertos tipos de aplicaciones donde es particularmente adecuado, sino que en realidad hace que sea realmente fácil construir cualquier tipo de aplicación, incluso algo que necesita ser tan escalable como una red social.

Otra aplicación que extiende lo que las aplicaciones local first pueden hacer es esta aplicación que está en desarrollo llamada Succulent, que es una herramienta de programación de redes sociales. Así que puedes planificar tus publicaciones de Instagram allí. Lo bueno aquí es que este es un buen ejemplo de la carga de archivos.

También maneja todos los datos de imagen. Y puedes, incluso mientras estás offline, poner imágenes allí, planificar tus publicaciones, y tiene un pequeño trabajador de servidor que realmente hablará con la API de métodos para publicar tus publicaciones. Pero la experiencia del usuario es completamente offline first y local first. Y puedes usarlo en varios dispositivos desde tu laptop, desde tu teléfono. Y fue simplemente súper, súper simple de construir debido a esta arquitectura.

Hay un par de ellos que me encantaría mostrarte, pero todavía están actualmente en sigilo. Alguien está construyendo un panel de CI en tiempo real donde tienen una API existente para sus ejecuciones de despliegue de CI, pero es un poco torpe y difícil construir un buen panel alrededor. Así que están usando Jazz como esta especie de capa de traducción que hace que sea realmente fácil construir una interfaz de usuario en tiempo real. Alguien está construyendo una aplicación de lienzo infinito, y ahora están tratando de construirla con Jazz porque resuelve básicamente todas las partes difíciles de la infraestructura. Y realmente pueden centrarse solo en la interfaz de usuario y la experiencia del usuario. Y finalmente, otro ejemplo donde se vuelve realmente importante tener estos permisos criptográficos y la identidad del usuario es una aplicación para compartir información de know-your-customer, que suele ser muy sensible y personal, con personas y organizaciones específicas. Sí, todos sus desafíos difíciles son nuevamente resueltos por Jazz al tener la identidad del usuario y permisos integrados de esta manera segura y de esta manera generalizada. Así que pueden centrarse, nuevamente, solo en la interfaz de usuario y la experiencia del usuario.

Si esto suena genial y tienes curiosidad y quieres intentar construir aplicaciones de una manera local-first la mejor fuente de recursos que va a haber no está del todo allí todavía, pero esperamos que llegue pronto, donde Jazz y un par de otros proveedores de motores de sincronización y frameworks local-first de código abierto, queremos crear esta página de comparación donde realmente puedas mirar muchas dimensiones diferentes y ver qué tecnología y qué servicio es el mejor ajuste para tu aplicación. Eso aún no está disponible, así que mantente atento. Pero si quieres comenzar a construir aplicaciones de una manera local-first de inmediato, realmente te animo a que revises jazz.tools, que por supuesto es la página de inicio de Jazz y Jazz Cloud. Y solo echa un vistazo a la documentación y las guías y pruébalo. Únete a nuestro Discord si tienes alguna pregunta. Espero haber podido darte una pequeña muestra de cómo es local-first. Muchas gracias por tu atención. Y aquí es donde puedes encontrar Jazz en Twitter y a mí en Twitter. Sí, espero que te unas a mí y construyas aplicaciones muy geniales mucho más rápido de una manera local-first. Gracias.