El Auge de la Pila Transaccional Moderna

Hola a todos. Mi nombre es Yoko. Soy una dibujante técnica, desarrolladora, gerente de productos y, por último, socia en H16z invirtiendo en el ecosistema de JavaScript y herramientas para desarrolladores. Hoy me gustaría compartir algunos cambios arquitectónicos interesantes que he visto después de hablar con cientos de desarrolladores y empresas tecnológicas. Estoy poniendo las arquitecturas en el contexto de las transacciones, ya que son tan fundamentales para nuestra vida diaria. Son la base de cosas como la emisión de boletos de avión, la entrega de alimentos a nuestras puertas y la reserva de cuidadores de gatos y perros. Y estamos viendo un cambio importante en cómo los desarrolladores utilizan y razonan sobre las tecnologías aquí.

Bueno, spoiler alert, JavaScript siempre gana. Así que hablemos de por qué y cómo. Ahora, aquí está la arquitectura que verás en el mundo antiguo. Como puedes ver, hay un montón de microservicios divididos entre el cliente y el servidor porque utilizan diferentes lenguajes, y también porque los desarrolladores frontend y backend no pueden ponerse de acuerdo entre sí. Cuando ves la ruta de una solicitud, por ejemplo, al realizar un pedido, esta se autentica y luego se envía a una API. El punto final de la API deberá orquestar cientos de microservicios para entregar una transacción comercial al usuario. Luego pasará por servicios de gestión de inventario, procesamiento de pedidos, procesamiento de pagos, entre otros. En este punto, los desarrolladores utilizan colas y cachés, como se puede ver en la mitad inferior de la imagen, para almacenar lo que llamamos estados de la aplicación, como `pedido recibido` o `pedido pagado`. Los desarrolladores también codificarán manualmente la lógica de reintento para obtener los datos en las bases de datos y cruzarán los dedos y esperarán lo mejor. Hemos descubierto que a medida que el sistema escala, también lo hace la complejidad de gestionar colas, cachés y casos especiales. Ahora vemos que muchas empresas comienzan a construir sus nuevos proyectos de manera muy diferente.

Ahora ingresa a la pila transaccional moderna, donde ya no necesitas aprovisionar y gestionar cientos y miles de microservicios. En su lugar, hemos llegado a un punto en el que el servidor sin servidor y JavaScript por sí solos son suficientes para alimentar toda la aplicación. Es posible que te preguntes qué es la pila transaccional moderna. En primer lugar, es completamente JavaScript y el backend es atendido por un proveedor. A veces, el proveedor es sin servidor. Ya no hay lo que llamamos frontend y backend. Todos son ingenieros full stack y ya no hay APIs, ya que está escrito en el mismo lenguaje de programación. Ahora tienes cosas como componentes de servidor y TRPC simplemente llamando a una función. Vemos que cada vez más empresas adoptan este patrón a medida que avanzan. Lo que tradicionalmente llamamos backend, ahora tenemos plataformas como Superbase, Convex, Upsash y otros que pueden eliminar por completo la necesidad de que los desarrolladores de aplicaciones gestionen directamente la infraestructura del backend.

En segundo lugar, otra característica de la pila transaccional moderna es que está impulsada por herramientas impulsadas por componentes. Para la autenticación, ya no necesitas lidiar con herramientas de nivel inferior que tradicionalmente usan los ingenieros de backend. Ahora puedes simplemente elegir herramientas como Clerc y usar un componente de firma de React. Otro buen ejemplo aquí es un proyecto de código abierto llamado React Email. Ya no tienes que codificar HTML básico para correos electrónicos transaccionales y ahora puedes usar React y Tailwind directamente en tu correo electrónico. Para el almacenamiento de objetos, esto es algo de lo que muchos ingenieros me hablan, incluso yo mismo, cómo aprender AWS. Pero ahora puedes usar algo llamado UploadThing nativamente en React en lugar de usar AWS S3 directamente.

Por último, un aspecto destacado de esta pila es que a medida que las empresas utilizan más APIs, más funciones y aceptan más webhooks, básicamente tienen que lidiar con funciones asíncronas a gran escala. Entonces, cuando esto sucede, debe haber un lugar central para orquestar estas cosas, ya que los reintentos hechos a mano son difíciles. Ahora comenzamos a ver motores de flujo desempeñando un papel central en el mundo nativo sin servidor. Y la forma de entenderlos es que son los orquestadores de funciones asíncronas. Aquí está la intuición. Si tu aplicación maneja cientos de registros de usuarios y luego envía un montón de correos electrónicos de bienvenida a los usuarios, puedes usar herramientas como ingest para escribir unas pocas líneas de código TypeScript para definir qué funciones se deben activar cuando ocurre un evento de registro. También volverá a intentar esta parte de la lógica automáticamente con un retraso exponencial si ese proceso falla. Y en el lado del cliente, si quieres, puedes usar la capa de autoría de la máquina de estados llamada xState. Lo conecto con el motor de flujo. Es un proyecto súper genial, hace que las cosas sean mucho más fáciles de entender en comparación con Redux, que solía usar todo el tiempo.

Probablemente haya horas y días de cosas de las que hablar en una pila que vemos una y otra vez aquí en la era sin servidor. Si quieres hablar más, no dudes en enviarme un mensaje directo en Twitter a staff Yoko Draws. Y eso es todo lo que tengo hoy. Gracias. Espero poder hablar más en persona.