Patrones de Arquitectura Remix

Hola a todos. ¿Qué es una arquitectura de software de nuevo? Una arquitectura de software es el plano de tu aplicación. Diseñas una arquitectura para cumplir con tus requisitos y adaptarte a tu caso de uso y resolver el problema que estás teniendo. Y luego eliges un stack de texto para implementar la arquitectura que acabas de diseñar.

Resulta que React es ahora también una arquitectura. Esta es una perspectiva realmente interesante de Dan Abramov, quien recientemente estuvo en Twitter reflexionando sobre el estado de React. Afirma que React ya no es solo la biblioteca, sino también una arquitectura que puede ser implementada por diferentes meta frameworks. Perspectiva realmente interesante, y estoy emocionado de ver a dónde nos lleva.

Y hoy, quiero hablar sobre los patrones de arquitectura de Remix que se utilizan comúnmente y se implementan arquitecturas con Remix. Mi nombre es Andrej. Soy un desarrollador de Alemania. Trabajo en LinkedIn y actualmente vivo en Cupertino, California. En mi tiempo libre, todos los lunes, doy tutorías a desarrolladores aspirantes en Meetup, y en general, me encanta construir para la web. Antes de mudarme a Estados Unidos, escribí mi tesis de maestría sobre patrones de gestión de API. Realicé entrevistas y hablé con ingenieros de software y arquitectos de diferentes empresas, y luego identifiqué patrones en cómo estas empresas gestionan sus API. Luego documenté los resultados de una manera coherente y organizada. Para eso, creé un lenguaje de patrones, y crear ese lenguaje de patrones fue muy divertido para mí, y aprendí mucho. Así que, quería hacerlo de nuevo, esta vez para Remix. Quiero responder a la pregunta, ¿cómo se usa Remix? Así que, para esto, creé una encuesta que llamé El Estado de Remix, y obtuve 74 respuestas. Tengamos en cuenta que 74 respuestas no son suficientes para ser estadísticamente relevantes, pero sí son suficientes para analizar o identificar patrones de uso comunes. Dicho esto, aún quiero mostrar algunos de los números que obtuve de la encuesta, solo porque me sorprendieron tanto.

El primero aquí es que más del 50% de los participantes afirmaron que utilizan Remix profesionalmente. Esto me sorprendió, considerando que la versión 1 de Remix solo se lanzó hace un año, pero es realmente genial ver que una gran parte de la comunidad ya gana dinero con Remix. De aquellos que usan Remix profesionalmente en este momento, el 50% afirmó que migraron de React Router a Remix. Pensé que este número sería mucho mayor, considerando el claro camino de migración entre React Router y Remix, y también obviamente la conexión entre las dos tecnologías. Pero resulta que la gente realmente se mueve de todo tipo de tecnologías a Remix. Las aplicaciones de página única de React todavía eran la fuente o región más grande de donde la gente se movía pero Next.js también se mencionó mucho, Express.js, LGS, Rails, Vue, pero en general hay tantas tecnologías diferentes para construir para la web y la gente realmente afirmó que se mueven de todo tipo de antecedentes y tecnologías a Remix. Creo que esto es realmente genial de ver, pero hablemos de patrones de arquitectura. Antes de Remix, o en general, podemos estar de acuerdo en que esto es una gran parte del estándar de la industria en este momento. Tienes la arquitectura de la aplicación de página única, tenemos una SPA que se ejecuta en el navegador en el front end y tienes un servidor de API independiente que luego se comunica con la SPA.

Entonces, este es el estándar de la industria en este momento. ¿Cómo se compara Remix con eso? Cuando usas MPX grade Remix para iniciar tu aplicación Remix y simplemente eliges lo básico, terminas con esto. Y esto es un entorno de servidor, ¿verdad? Remix es un manejador de HUP que se ejecuta en un entorno de servidor. Y si inicias una aplicación Remix, viene con un entorno de servidor, que ya está algo esbozado para ti. Y en ese entorno de servidor, tienes un servidor web en el que se ejecuta el manejador de HUP. Eso fue un trabalenguas. Y eso crea esta aplicación PASPA. Y PASPA es este término que significa Aplicación de Página Única Mejorada Progresivamente, acuñado por Kenzie Dodds para promover que la aplicación que crea Remix hace mucho más que una SPA. Incluso funciona sin JavaScript. Utiliza la plataforma, abraza la plataforma, emula los comportamientos predeterminados del navegador JavaScript si JavaScript está habilitado, y hace muchas más cosas por ti. Por eso es que todos amamos Remix. Pero si lo comparamos con la arquitectura SPA, vemos que todavía falta la capa de base de datos. Y aquí, Remix es agnóstico, así que tenemos que elegir una base de datos nosotros mismos o elegir una de las pilas de Remix y vendrá gratis para nosotros. Obviamente, esto también es opcional. No siempre necesitas una capa de base de datos. También puedes tener un CMS en su lugar. Pero entonces, de cualquier manera, lo que tenemos aquí es nuestro primer patrón de arquitectura. Aquí es donde todos comenzamos con Remix y es un sistema de arquitectura que podemos usar para crear para la web.

Entonces surge la pregunta de cómo pasamos de esta aplicación de página única, estándar de la industria, a nuestra aplicación Remix? La respuesta es que lo que muchos dicen que hacen es que crean esta arquitectura temporal para luego pasar a Remix. Mueven el código de React de la SPA dentro de Remix, pero mantienen el servidor API independiente. Luego, pasan las solicitudes de la SPA a esa API heredada, reenviando las solicitudes a través del manejador HTTP de Remix.

Lo que es realmente genial de esta arquitectura y este enfoque es que ahora puedes refactorizar tu código SPA paso a paso para aprovechar más las características que Remix proporciona. Así que refactorizas tu consulta de uso o tus efectos de uso con las llamadas de fetch a forms y use fetcher en Remix y realmente haces que tu aplicación mejore progresivamente basándose en las capacidades que Remix proporciona. Al mismo tiempo, mueves más y más código del servidor API heredado al manejador HTTP de Remix, por lo que realmente puedes hacer esto en rebanadas de características verticales y paso a paso tomar más y más ventaja de las capacidades de Remix. Y esto es obviamente también un patrón de arquitectura, incluso si es esperanzadamente temporal, porque al final del día, quieres realmente poner fin a ese servidor API independiente y mover todo a Remix, tener el control total del servidor web y terminar con esa aplicación Remix independiente de la que hablamos antes.

Pero es súper genérico, ¿verdad? Solo decimos base de datos y un entorno de servidor, así que tenemos que ser más específicos aquí realmente para hacer esto más productivo. Y si hablas de diferentes variaciones en un lenguaje de patrones, hablas de variantes y las variantes son en realidad todas la misma cosa, solo que tienen diferentes características. Se te permite tener una variante favorita también, pero aquí solo quiero hablar de las más comunes basadas en los datos de la encuesta. Y la primera variante que se mencionó más es la independiente de Node.js. Así que usas el adaptador ExpressJS, el servidor de la aplicación remix o cualquier otro objetivo de despliegue que sea basado en Node.js y ahora tienes este servidor de aplicación independiente Node.js, tu aplicación remix ahora funcionando en Node.js.

Lo que es realmente genial de esta variante es que se siente muy familiar. Si has usado ExpressJS antes o cualquier otro servidor web basado en Node.js o como servidor API independiente, puedes decir que es lo mismo. Ahora solo tienes remix funcionando encima de eso también. También es súper flexible porque no estás atado a un proveedor de hosting o servicio específico. Puedes desplegar esto en cualquier lugar donde se pueda desplegar Node.js. Y es muy compatible con todos los paquetes npm y el código que has escrito en el pasado. Así que es una variante realmente genial. Una variante alternativa es la independiente de edge. Y esta es obviamente muy vanguardista, porque ahora desplegamos en un entorno edge. Y realmente creo que es una tendencia, el despliegue edge, que remix realmente ayudó a acelerar. Siento que todo empezó con remix. Remix estaba impulsando tener adaptadores para cloud para trabajadores y páginas, que también fueron los adaptadores más mencionados en la encuesta. Y siento que todo empezó desde ahí. Y ahora tenemos tantos diferentes entornos edge para elegir, ¿verdad? Tenemos dino deploy, tenemos fly.io, que crea estos servidores de larga duración distribuidos regionalmente, que es una experiencia similar a edge. Vercell y Netlify ambos añadieron sus propios entornos edge. Así que es realmente genial ver que tenemos todos esos diferentes adaptadores ahora para remix, para desplegar en el edge. Pero lo que obtenemos de todos ellos es esta proximidad geográfica a nuestros usuarios. Al desplegar en el edge, distribuimos nuestra aplicación a través del globo a diferentes entornos edge, diferentes servidores edge.

Y lo que es realmente genial de esto también es que muchos de esos entornos edge en realidad son serverless. Así que obtenemos el mismo tipo de escalabilidad que nos proporciona serverless. E incluso si los entornos no son serverless, en su mayoría hacen el mismo tipo de truco. Así que creamos esta aplicación muy escalable.

Un patrón realmente genial. Pero lo que tenemos que tener en cuenta aquí con esta variante es que... Y por eso también resalté la capa de base de datos, que si desplegamos en diferentes regiones, también tenemos que hacerlo con nuestra base de datos. De lo contrario, no obtendremos tanto de la proximidad geográfica. Queremos reducir los tiempos de respuesta, pero si nuestra base de datos está muy lejos de nuestra aplicación web, no obtenemos tanto de ella. Así que también tenemos que distribuir regionalmente nuestra base de datos. Solo algo a tener en cuenta, pero aún así una increíble variante de patrón.

Y la variante número tres es probablemente mi favorita, y se llama caché de aplicación. Así que este es agnóstico al entorno del servidor. No importa qué entorno de servidor elijas, este patrón siempre funcionará. Solo añades un Redis o cualquier otro caché de aplicación en memoria para deshacerte de algunos cuellos de botella. Así que el objetivo aquí es si tu aplicación crece en complejidad y tienes que extraer mucho en cada solicitud, para mitigar algunas de las penalizaciones en cuanto al tiempo de respuesta, de extraer tanto de la base de datos, añadiendo un caché. Y esto no es realmente un problema específico de Remix. Cuando tu aplicación se vuelve complicada, tienes que contrarrestar eso. Pero es realmente fácil hacer esto con Remix. Por ejemplo, personalmente siempre extraigo de mi raíz muchos datos, como la configuración del usuario y el objeto del usuario, y el próximo video preferido para ver, y luego las compras promocionadas y demás. Y luego tener todo eso en un caché, para que no tengas que extraerlo en cada mutación, es una gran manera de mitigar los cuellos de botella que pueden venir de extraer de la base de datos demasiado a menudo. Así que, definitivamente un patrón genial. Pero hablemos de Empresa. Cuando digo Empresa, eso solo significa que se vuelve aún más complicado, ¿verdad? Ya dijimos, nuestra aplicación puede volverse más compleja. Tienes que añadir algo como Redis, ¿verdad? Para contrarrestar eso. Pero ¿qué pasa si se vuelve más y más complicado, verdad? Esto es básicamente Empresa. Es como el jefe final en complejidad. Y cuando miramos hacia atrás al estándar de la industria en este momento, tenemos esta arquitectura SPA. Así que Empresa, solo significa que tienes que integrar tu SPA en un entorno aún más complicado o complejo. Pero muchos equipos diferentes trabajan juntos para crear una arquitectura de sistema.

Entonces, es posible que tengas que obtener datos de muchas APIs diferentes que proporcionan diferentes entidades para tu aplicación, diferente lógica de negocio para tu aplicación. Y luego tienes que manejar todos esos estados de carga y estados de error y autorización y reintentos y revalidación, UIs optimistas, todo eso para esas diferentes APIs que probablemente estén trabajando un poco diferente dentro del frontend, dentro de tu SPA. Y eso puede volverse súper complicado y un lío.

Es por eso que muchas personas recurren a implementar el patrón backend para frontend. Así que eso es parte del estándar de la industria también. Es como este patrón muy conocido donde creas este servicio de middleware que está vinculado a tu frontend y de alguna manera obstruye parte de la complejidad del sistema. Y puedes mover mucha de esa lógica de obtención dentro de esta capa de orquestación. Así que ahora tu SPA está protegida de obtener datos de diferentes APIs y haces eso en tu backend que es para tu frontend.

Y este es también un caso de uso realmente genial para GraphQL. Porque si añades GraphQL en el servidor, es donde realmente brilla, ¿verdad? Orquestando solicitudes, diferentes servidores, agregando data, y luego haciéndola accesible. Obviamente también puedes añadir GraphQL aquí a la SPA y luego tienes que obtener datos solo de un punto final. Pero este es un gran caso de uso para GraphQL de todos modos.

Entonces, la pregunta ahora es que sabemos que esto es el estándar de la industria o parte del estándar de la industria en este momento. ¿Cómo traducimos esto a Remix? Y resulta, y nunca lo pensé de esta manera, y creo que es tan genial, es que Remix implementa naturalmente el patrón backend para frontend. Muchas personas en la encuesta afirmaron que utilizan específicamente Remix para implementar un backend para el patrón de arquitectura frontend. Y resulta que la documentación de Remix tiene contenido sobre esto explicando cómo exactamente Remix funciona como un backend para tu frontend. Pero nunca vi esto y nunca lo pensé de esta manera. Y creo que es simplemente genial que si usas Remix, obtienes un control total de tu servidor web y tu servidor web reemplaza la necesidad de cualquier orquestación independiente, capa de middleware que hubieras necesitado de otra manera. Así que cuando usas Remix para implementar tu SPA, obtienes el patrón backend para frontend de manera natural proporcionado por Remix. Creo que es realmente genial pensar en ello de esta manera. Y obviamente, este es un patrón de arquitectura que podemos usar en un contexto empresarial. E incluso podemos añadir GraphQL encima si lo necesitamos, ¿verdad? Aquí es donde GraphQL brilla para agregar y orquestar datos de diferentes puntos finales. Y eso se traduciría en una variante de ese fondo para el patrón frontend en Remix. Genial. Entonces, tenemos tres diferentes candidatos de patrones que hemos identificado que esperamos que temporalmente pasen a través de la API Legacy, que actúa como un paso de migración. Y luego tenemos la aplicación independiente Remix. Aquí es donde todos empezamos. Y luego, si se vuelve más complicado, obtenemos de manera natural este patrón de arquitectura backend para frontend implementado de manera natural por Remix. Y esto crea esos tres diferentes patrones que hemos identificado. Y vimos que hay muchas variantes diferentes, y hay muchas más variantes que ni siquiera menciono. Realmente no hablé sobre Fly.io, Netlify, Resell, esos proveedores de alojamiento geniales que ofrecen tantas otras cosas interesantes para nosotros. Pero realmente muestra cuán flexible es Remix en general, ¿verdad? Puedes desplegar en servidores de larga duración, en entornos serverless, y en el borde. Y podemos añadir fácilmente algo como Redis a nuestra aplicación para mitigar los cuellos de botella y realmente variar nuestra arquitectura basada en nuestro caso de uso y realmente alinear Remix con lo que queremos construir, lo cual es realmente genial ver que Remix es tan flexible.

Al final, solo quiero hablar sobre los patrones en tiempo real. Hasta ahora hemos hablado sobre los patrones de arquitectura en general, y ahora quiero hacer doble clic en tiempo real. Esta es una discusión en curso entre experiencias estáticas y experiencias muy dinámicas y qué framework es mejor para desarrollar qué tipo de aplicación. Lo llamamos web de documentos versus web de aplicaciones, y luego nos preguntamos qué framework es realmente adecuado para crear esas experiencias altamente dinámicas que queremos crear en 2022. A veces Figma o Google Docs se utilizan como ejemplos de estas experiencias altamente dinámicas que queremos crear. ¿Qué framework elegirías para crear algo como Figma? En mi opinión, creo que la escala no es suficiente. El espectro entre estático y dinámico, necesitamos añadir más a la derecha de dinámico, porque lo que hace que Figma y Google Docs sean altamente dinámicos son realmente sus capacidades en tiempo real. Estas son aplicaciones reactivas de pila completa y un saludo a convex.dev que hacen mucho trabajo genial en esa área. En realidad, hay muchas startups que intentan hacer algo en esta área.

Pero desde una perspectiva de framework, creo que ninguno de los frameworks, esos frameworks que tenemos ahora en el ecosistema de React, proporciona primitivas o convenciones para implementar capacidades en tiempo real. Entonces, cuando hablamos de algo como Figma o Google Docs, esto no es algo con lo que tu framework te ayuda. Simplemente tienes que construir esas cosas sobre lo que el framework proporciona. Dicho esto, tampoco es realmente un fallo de esos frameworks, porque hay tantas preguntas abiertas a nivel de infraestructura. Solo para darte un ejemplo, las funciones serverless intuitivamente no admiten realmente algo como transmisión, como respuestas de larga duración, o servidores WebSocket porque quieren cerrarse después de manejar la solicitud. Y AWS proporciona su propia solución para hacer que los WebSockets funcionen con serverless, como el agrupamiento de conexiones y cosas así. Es muy específico para cada proveedor de infraestructura. Sería realmente difícil abstraer eso y crear una API común en una capa de framework. Mucha construcción aún en marcha y preguntas abiertas, pero todavía hay formas ahora obviamente para crear capacidades en tiempo real en tus aplicaciones de React. Solo quiero mostrar tres diferentes patterns sobre cómo implementar características colaborativas en Remix.

En el primero, lo llamo servidor independiente de WebSockets. Es probablemente el más sencillo. Simplemente creas un servidor independiente con un servidor WebSocket encima y puedes desplegarlo donde sea que se admitan los WebSockets, como un servidor Node.js de larga duración, por ejemplo. Y lo tienes separado de tu aplicación Remix. Lo genial de esto es que te mantienes flexible en cuanto a dónde desplegar tu aplicación Remix, incluso si la despliegas en entornos como Netlify Versa, que realmente no admiten WebSockets en este momento.

Como tu servidor de WebSockets es independiente, aún puedes desplegar tu aplicación Remix allí. Y luego tienes que tener esto, como tu aplicación del lado del cliente de tu aplicación Remix tiene que comunicarse con el servidor WebSocket. Y tienes que eliminar algo de la lógica que anteriormente estabas manejando en Remix con WebSockets ahora. Pero funciona y es una excelente manera de agregar capacidades en tiempo real. Incluso más genial, creo, dependiendo de los casos de uso, agregar el servidor WebSocket al mismo entorno de servidor que usas para tu aplicación Remix.

Correcto, Remix realmente expone el servidor web subyacente que se utiliza cuando usas Remix. Si eliges el adaptador Express JS, tienes acceso a donde se crea la aplicación Express. Y allí también puedes agregar un servidor WebSocket. Es solo un entorno Node.js. Y ahora si eliges el objetivo de despliegue correcto puedes tener tu servidor WebSocket funcionando al lado de tu manejador HTTP de Remix. Lo realmente genial de esto es que con Remix estábamos tan contentos de que podemos compartir código y tipos entre nuestro frontend y backend. Y ahora con esto también podemos compartir código entre nuestro servidor WebSocket y nuestra aplicación Remix. Pero estamos un poco más limitados porque no podemos desplegar en todos los entornos que Remix admite, porque tenemos que asegurarnos de que este entorno también admita WebSockets.

Eso me lleva a mi último patrón aquí, que es el que más me emociona. Y eso es usar Server-SendEvents como una tecnología alternativa a WebSockets. Así que usamos Server-SendEvents ahora para crear una conexión entre el frontend y nuestro servidor que crea esta reactividad completa. Y la forma en que funcionan los Server-SendEvents es que crean un flujo unidireccional entre el servidor y el cliente para que el servidor pueda enviar paquetes de información o eventos al cliente. Así que no es bidireccional como WebSockets, pero si realmente lo piensas, el otro camino ya está cubierto con Remix.

Remix proporciona todo lo que necesitamos para mutar nuestro estado del servidor en función de nuestro estado del cliente. Así que estos formularios y envíos de formularios y uso de fetch. Ya podemos mutar los datos. Y luego, ya que Remix revalida nuestro estado del cliente y sincroniza nuestro estado del cliente con nuestro estado del servidor. Lo único que realmente queda es informar a un cliente si otro cliente cambia el estado del servidor. Correcto. Esto es lo que significa la reactividad de pila completa en ese sentido. Que en la pila completa en el servidor. Si cambias el estado, tu cliente reacciona a estos cambios y los eventos del servidor envían puedes enviar un ping a tu cliente e informarle de un cambio. Y luego puedes desencadenar la revalidación en la carga útil incluso puede incluir la entidad que ha sido actualizada y luego lo manejas en el estado de React.

Pero lo realmente genial de los eventos del lado del servidor es que puedes implementar ellos dentro de tu aplicación Remix. Así que dentro de una ruta de recurso en el cargador de tu aplicación Remix puedes agregar el código para crear un punto final de eventos del lado del servidor y luego puedes usar la plataforma en el lado del frontend de tu aplicación Remix y un usuario reacciona para crear la conexión a ese punto final. Y ahora tienes reactividad de pila completa y capacidades en tiempo real para experiencias colaborativas multijugador en tu aplicación Remix hoy. Remix realmente no proporciona ninguna primitiva y convenciones para manejar eso, pero desde Remix expone la plataforma para nosotros, esto es como esto es compatible básicamente fuera de la caja con Remix hoy. Y creo que es simplemente genial.

Así que tenemos tres patrones en tiempo real aquí sobre cómo implementar capacidades en tiempo real con Remix. Puedes usar WebSockets de una forma u otra con Remix. Pero aún más, estoy aún más emocionado por los eventos de servicio. Y también hay mucha tracción en este momento en torno a este tema en GitHub, en la discusión sobre eventos de servicio y Remix. Y estoy realmente emocionado de ver a dónde lleva esto. Pero al final, quiero dejarte con un hecho de la encuesta. Y es que seis de los 74 participantes, alrededor del 8%, afirmaron que comenzaron a programar con Remix. Y creo que esta es una gran oportunidad para todos nosotros de crear contenido amigable para principiantes para Remix. Personalmente, me hubiera encantado aprender a programar o desarrollo web con Remix. Probablemente me hubiera ayudado a entender la plataforma mejor antes de saltar a React. Ahora, siento que estoy pensando muchas veces en una forma React, aunque quiero pensar de una manera web. Y creo que Remix habría proporcionado una excelente manera de comenzar con esto. Y eso significa que todos tenemos un trabajo que hacer ahora, y eso es hacer que la comunidad sea más accesible para los principiantes. Dicho esto, muchas gracias por escuchar y feliz codificación.