1. Introducción a Electric SQL
Hola, soy James Arthur, cofundador y CEO de Electric SQL. Somos un Sinclair para construir aplicaciones modernas. Nuestro Sinclair local-first te permite construir aplicaciones directamente sobre Postgres usando React. Tenemos un equipo de geeks de sistemas distribuidos que han estado investigando y fortaleciendo la programación en el lado AP del teorema de cap. Esto ha llevado a un cambio en la arquitectura de las aplicaciones, con los sistemas local-first ganando más popularidad. Estos sistemas permiten la comunicación directa con una base de datos local y proporcionan resultados instantáneos, funcionalidad fuera de línea y colaboración multiusuario incorporada. Ahora pasemos a una demostración para ver esto en acción.
Entonces, hola, soy James Arthur. Soy uno de los cofundadores y soy el CEO de Electric SQL. Entonces esto es básicamente Electric. Somos un Sinclair para construir aplicaciones modernas. Entonces, específicamente, es un Sinclair local-first, del cual hablaré, y te permite construir aplicaciones como Figma, Linear, directamente sobre Postgres, usando React.
Solo para darte un poco de contexto sobre quiénes somos, básicamente somos un grupo de geeks de sistemas distribuidos. Y entonces, la compañía surge de una serie de investigaciones en el lado AP del teorema de cap, y tenemos a varias de las personas que han sido pioneras en muchas cosas en esa área en el equipo, incluyendo a dos de los inventores de CRDTs, etc. Y básicamente, estos académicos, durante las últimas probablemente un par de décadas o más, han estado trabajando para fortalecer básicamente lo que puedes hacer con la programación en el lado AP del teorema de cap. Y no entraré en detalles aquí, pero puedes investigar un poco sobre este tipo de investigación. Y ahora se está utilizando para cambiar la forma en que construyes aplicaciones hoy en día, y particularmente, se trata de apuntar a la transferencia de estado de la arquitectura de la aplicación. Entonces, los sistemas tradicionales cloud-first, se ejecutan en el servidor, hablan con servicios web a través de la red. Mientras que ahora tienes sistemas local-first, donde hablas directamente con una base de datos local que está incrustada dentro de la aplicación, y luego los datos se sincronizan en segundo plano. Y este tipo de arquitectura ahora está siendo utilizada por una amplia gama de aplicaciones exitosas. Así que mencioné cosas como Figma, Linear, tienes el nuevo Facebook Messenger, las nuevas aplicaciones de Google Workspace, tienes SuperHuman, por ejemplo. Y solo para darte una idea muy rápida de lo que está sucediendo allí, con un sistema tradicional cloud-first, tienes la red en el camino de interacción. Entonces el usuario hace clic en un botón, envía una solicitud al servidor, el servidor envía algo de vuelta al usuario, y luego ves los resultados. Y entonces tienes latencia por ir a través de la red, el servidor necesita estar en línea, tienes errores de red que tienes que codificar cada vez que vas a través de la red, y el usuario está allí viendo un spinner de carga o esperando que la página cargue. Mientras que, con local-first, básicamente mueves la base de datos, o un subconjunto de la base de datos, al cliente, el usuario hace clic en el botón, todo es instantáneo, por lo que no hay latencia porque no tienes la red en el camino de interacción, el usuario ve el resultado inmediatamente, las aplicaciones por defecto funcionan sin conexión, si el servidor se desconecta, la aplicación sigue funcionando. Luego introduces este tipo de capa de sincronización en vivo entre la base de datos y el cliente y en el servidor. Y juntos, lo que esto te da es este modelo donde obtienes una especie de trinidad sagrada de una gran experiencia de usuario moderna para el consumidor o prosumidor, que combina la reactividad instantánea para que las aplicaciones simplemente se sientan instantáneas de usar con colaboración multiusuario incorporada y también aplicaciones que pueden trabajar sin conexión y manejar conflictos por ti. Así que voy a saltar en este punto y vamos a pasar a una especie de demostración solo para ver eso en acción. Voy a cambiar de ventanas. Así que esto es pasar a electric. Como primero, solo voy a saltar para darte una idea de algo de el código si eso es útil como orientación. Entonces, por ejemplo, ¿cómo configuras esto? Correcto. Entonces tenemos una arquitectura donde tienes una base de datos Postgres en el fondo. Ejecutas un servicio de sincronización eléctrica. Entonces esto es un servicio de sincronización elixir. Es sin estado. Se ejecuta frente a PostgreSQL y maneja esa replicación por ti.
2. Acceso a Datos y Sincronización
Generamos una biblioteca de acceso a datos segura desde el esquema de datos de Postgres. Define tu esquema como de costumbre y utiliza reglas para controlar la exposición de datos y los permisos. Autentica la aplicación local utilizando un JWT y envuelve el controlador SQL light con electrify para obtener una versión en vivo reactiva de la conexión a la base de datos. La API utiliza formas para controlar la sincronización de datos en el dispositivo local. Define formas para la replicación parcial dinámica y vincula consultas en vivo para actualizaciones en tiempo real. Escribe datos directamente en la base de datos local y mantén todo en vivo y reactivo.
Lo que hacemos entonces es generar una biblioteca de acceso a data segura desde el esquema de data de Postgres desde el esquema DDL. Así que la forma en que funciona es que simplemente defines tu esquema como de costumbre utilizando cualquier tooling que usarías para trabajar con Postgres. Así que algo como por ejemplo, luego, nosotros, proporcionamos un conjunto de reglas para poder controlar qué data se expone al sistema. Y también quién puede, quién tiene qué permisos sobre qué data. Es un poco como la security a nivel de fila, pero es un poco diferente porque está diseñado para ser portátil para que puedas ejecutar las reglas en el servicio de sincronización y en el cliente que te permite lograr algo llamado finalidad de los derechos locales. Así que no tienes que codificar para retrocesos y errores cada vez que lo haces. Correcto. Luego autenticas la aplicación local utilizando un JWT, y luego dentro del cliente, básicamente tomas el controlador SQL light estándar para tu entorno. Así que si estás en un navegador web utilizando una compilación Wasm de SQL lights, o si estás haciendo una aplicación móvil, es como un controlador React nativo o un expo o un controlador capacitor. Y luego envuelves eso con esta llamada para electrificarlo. Y eso te da una especie de versión en vivo reactiva de la conexión a la database que también es consciente de tu esquema, y sabe dónde conectar para la replicación. Luego proporcionamos una API utilizando un primitivo llamado formas, que te permite controlar qué data se sincroniza dentro y fuera del dispositivo local. Así que si te imaginas que empiezas con, digamos, una gran base de datos de postgres, y quieres sincronizar solo un subconjunto de la data en el dispositivo local. Defines una forma que podría ser como el proyecto 1234. Así que por ejemplo, aquí, como, podemos decir un proyecto e incluir todos los problemas y comentarios y los autores de los comentarios debajo de eso. Así que es un poco como hacer una consulta ORM con un gráfico de asociación. Y luego puedes definir múltiples formas a medida que avanzas. Y puedes actualizarlos en runtime. Y se agregarán en una especie de suscripción de forma combinada para una aplicación cliente en particular. Así que esa es una API que controla básicamente la replicación parcial dinámica, qué data se sincroniza en el dispositivo local. Y luego, una vez que tienes la data en la database para el dispositivo local, vinculas consultas en vivo. Así que en este caso, este es un ejemplo de resultados como una variable de estado de React, y usas un gancho de consulta en vivo. Y luego tienes un constructor de consultas inspirado en prisma para definir consultas de cómo quieres acceder a la data en la database. O puedes bajar a SQL puro. Y luego, en cualquier momento, puedes escribir data directamente en la database local. Y básicamente todo se mantiene en vivo y reactivo. Así que porque tienes este modelo de replicación activa bidireccional debajo de los componentes que controlan qué data se sincroniza dentro y fuera del dispositivo, en lugar de hacer solo consultas estáticas o recuperaciones estáticas contra el servicio de backend, lo que haces es mantener todo en vivo para que si otro usuario también cambia la data en otro lugar, tus componentes también se actualizan naturalmente. Así que aquí hay un ejemplo de un simple componente de React. Obtienes un control sobre la database electrificada. Configuras una consulta en vivo
3. Funcionalidad y Sincronización
Puedes crear nuevos elementos y pasarlos a través de un componente estándar, manteniendo todo reactivo y funcionando sin conexión. Se admite la sincronización en tiempo real de varios usuarios, lo que permite el uso multiplataforma y una funcionalidad resistente sin conexión. El sistema garantiza la consistencia transaccional causal plus, evitando conflictos y preservando las garantías de integridad. La replicación activa-activa permite actualizaciones en múltiples instancias de la aplicación.
para todos los elementos. Y luego tienes una función aquí para decir, crear un nuevo elemento. Y simplemente pasas esos elementos a través de un componente estándar. Y todo se mantiene reactivo, todo funciona, la aplicación funciona sin conexión. Cuando se conecta,
data se sincroniza. Y si el componente se vuelve a renderizar, ya sea que cambies la
data, ya sea que alguien más cambie la
data. Así que solo para mostrarte un poco de esto en acción. Así que por ejemplo, hablamos de que las cosas son instantáneas y super rápidas. Así que esto te da un ejemplo del tipo de latencia que obtienes para hacer un ciclo completo de re-renderizado a través de la
database local. Está en una especie de milisegundos de un solo dígito o bajo dos dígitos. Mientras que cuando vas por encima de la
cloud, esto está hablando con un servicio
backend para la misma aplicación. A, la latencia es mucho mayor, pero también tu disponibilidad y la calidad de tu
user experience están a merced de la conectividad del usuario. En términos de sincronización en tiempo real de varios usuarios, puedes ver la misma aplicación de demostración. Y ahora tenemos dos instancias de la misma aplicación de demostración donde estamos sincronizando a través del servidor. Así que si añado un elemento en el lado izquierdo, se sincroniza con el lado derecho. Si muevo el deslizador, se sincroniza con el lado derecho. Así que te da este tipo de sincronización multiusuario incorporada. También es multiplataforma. Funciona en la web y en el móvil, y esta sincronización en tiempo real funciona de manera resistente sin conexión, ¿verdad? Así que aquí está la misma aplicación, pero ahora tenemos un gancho de conectividad. Así que por ejemplo, digamos que desconecto al usuario uno sin conexión, creo dos elementos aquí y borro los elementos aquí. Cuando el usuario uno se conecta, todo finalmente se sincroniza al mismo estado. Así que es en realidad una consistencia transaccional causal plus, que es el modo de consistencia más fuerte posible para este tipo de aplicación. Y significa que básicamente puedes hacer escrituras sin conexión y no obtienes conflictos. Y también preservamos un montón de garantías de integridad en torno a la
data relacional, como la integridad referencial, de la que probablemente no tenga tiempo para hablar ahora.
Pero solo para mostrarte una cosa más muy interesante. He mencionado que es este modelo de replicación activa-activa. Así que aquí, por ejemplo, está la misma aplicación de demostración. Ahora, si solo abro un terminal para seguir las instrucciones. Así que lo que tenemos aquí entonces es que puedo obtener una cadena de conexión para básicamente conectarme al Postgres que está respaldando este ejemplo. Y luego esto es me va a dar un comando aquí, por ejemplo, para actualizar el valor del deslizador. Y luego si vienes y ves la aplicación, mientras hago esto, puedes ver que simplemente estoy moviendo el deslizador.
4. Sincronización y Beneficios
A medida que escribes contenido en la base de datos Postgres, se hunde en la aplicación. Puedes monitorear el valor del mismo deslizador con una consulta de observación. Local First Software proporciona una experiencia de usuario de alta calidad, elimina el código de relleno y permite ahorros de costos y simplicidad operativa. Para obtener más información, visita la Comunidad Web Local First y nuestro sitio web. ElectricSQL es una capa de sincronización Local First con integración de React, proporcionando un cliente seguro de tipo, APIs para replicación dinámica, primitivas de consulta en vivo e integraciones de marco. Encuéntranos en electric-sql.com, Discord y GitHub.
Básicamente, a medida que escribes contenido en la base de datos Postgres, se hunde en la aplicación, y a medida que editas data en la aplicación, se hunde de nuevo en el Postgres. Así que solo una última, por ejemplo, puedes monitorear el valor del mismo deslizador si hacemos eso con una consulta de observación. Y luego, a medida que mueves el deslizador en el navegador, ves el valor cambiando en la parte inferior izquierda. Y puedes obtener algunos patrones muy interesantes al unificar la gestión del estado entre el Estado de la UE y tus datos de aplicación en la misma base de datos local.
Genial. Bueno, espero que eso te haya dado una idea muy rápida del sistema. Quiero decir, solo para recapitular, el software Local First te da una experiencia de usuario realmente de alta calidad y resistente. Como desarrollador, simplemente elimina el tipo de capa de crud y todo el código de relleno alrededor de interactuar con los servicios web y manejar las áreas de red. Y en realidad, te permite reemplazar una diversidad de servicios de back-end con solo un protocolo de replicación estandarizado. Así que en realidad, con muchas de las aplicaciones que están funcionando en esto, informan que proporciona un montón de ahorros de costos y simplicidad operativa. Para obtener más información sobre Local First, hay una gran community, que es la Comunidad Web Local First, si buscas eso en Google. Hay un manifiesto donde un grupo de investigación llamado IncanSwitch's va a definir el término Software Local First. Y en nuestro sitio web, hay un montón de cosas donde puedes ir a través de algunas de esas guías de demostración y sumergirte en el modelo. Entonces, y de nuevo, solo ElectricSQL. Entonces, ¿qué somos? Así que somos una capa de sincronización Local First con integración de React. Básicamente hacemos la sincronización Local First correctamente entre Postgres y React en tu aplicación. Te damos un cliente seguro de tipo. Te damos estas APIs para la replicación parcial dinámica basada en formas. Te damos primitivas de consulta en vivo, el modelo de reactivity y un montón de integraciones de marco. Todo es de código abierto y está diseñado para un auto alojamiento simple. Para obtener más información sobre ElectricSQL estamos en electric-sql.com. Tenemos una comunidad de Discord si tienes alguna pregunta o quieres seguir el proyecto y puedes vernos en GitHub en github.com slash electric-sql. Muchas gracias.
React Summit 2020
