Patrones de Arquitectura Remix

Rate this content
Bookmark

Remix ofrece una increíble flexibilidad y puede ser desplegado en cualquier lugar donde se ejecute JavaScript. Pero, ¿cómo encaja Remix en el panorama de aplicaciones más amplio de una organización? Remix proporciona una gran utilidad, pero ¿cómo aprovecharla al máximo? ¿Qué cosas deberían manejarse dentro de Remix y qué cosas serían mejor hacer en otro lugar? ¿Deberíamos usar el adaptador express para agregar un servidor WebSocket o debería ser un microservicio independiente? ¿Cómo integrarán las organizaciones empresariales Remix en sus pilas actuales? ¡Hablemos de patrones de arquitectura! En esta charla, quiero compartir mis pensamientos sobre cómo integrar mejor Remix en una pila (empresarial) más grande.

Andre Landgraf
Andre Landgraf
23 min
18 Nov, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla introduce los patrones de arquitectura Remix para aplicaciones web, con más del 50% de los participantes utilizando Remix profesionalmente. La migración de aplicaciones de una sola página a Remix implica una refactorización paso a paso y ofrece flexibilidad en las opciones de despliegue. La escalabilidad se puede lograr distribuyendo la capa de base de datos e implementando el almacenamiento en caché de la aplicación. El patrón de backend para frontend simplifica la obtención de datos, y Remix proporciona capacidades en tiempo real para características colaborativas a través de servidores WebSocket y Server-SendEvents.

Available in English

1. Introducción a la Arquitectura de Software y Remix

Short description:

Una arquitectura de software es el plano de tu aplicación. React es ahora también una arquitectura que puede ser implementada por diferentes meta frameworks. Hoy, quiero hablar sobre los patrones de arquitectura de Remix. Más del 50% de los participantes afirmaron que utilizan Remix profesionalmente. El 50% de aquellos que usan Remix profesionalmente migraron de React Router a Remix. Hablemos sobre los patrones de arquitectura.

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.

2. Introducción a la Arquitectura de Remix

Short description:

Remix es un manejador de HUP que se ejecuta en un entorno de servidor. Crea una Aplicación de Página Única Mejorada Progresivamente (PASPA) que funciona sin JavaScript y abraza la plataforma. Sin embargo, Remix es agnóstico a la capa de base de datos, lo que nos permite elegir la nuestra o usar una de las pilas de Remix. Este es el primer patrón de arquitectura para crear aplicaciones web con Remix.

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.

3. Pasando de SPA a la Arquitectura Remix

Short description:

Para pasar de una aplicación de página única a una aplicación Remix, se crea una arquitectura temporal. El código de React se traslada de la SPA a Remix, mientras que se mantiene el servidor API independiente. Las solicitudes de la SPA se pasan a la API heredada a través del manejador HTTP de Remix. Esto permite la refactorización paso a paso del código de la SPA para aprovechar las características de Remix. El código del servidor API heredado se traslada gradualmente al manejador HTTP de Remix. La variante más común es la independiente de Node.js, que proporciona familiaridad, flexibilidad y compatibilidad. Otra variante de vanguardia es la independiente de edge, que se despliega en entornos edge, ofreciendo proximidad geográfica a los usuarios.

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.

4. Escalabilidad, Caché y Empresa

Short description:

Un patrón interesante es crear una aplicación escalable utilizando entornos edge. Sin embargo, es importante considerar la capa de base de datos y distribuirla regionalmente para un rendimiento óptimo. Otro patrón es utilizar un caché de aplicación, como Redis, para mitigar los cuellos de botella causados por la frecuente extracción de datos de la base de datos. Este patrón no es específico de Remix y es útil para aplicaciones complejas. En escenarios empresariales, la arquitectura SPA se integra en un entorno más complejo, que implica la colaboración entre diferentes equipos.

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.

5. Patrón Backend para Frontend y GraphQL

Short description:

La obtención de datos de múltiples APIs en un frontend puede ser complicada. El patrón backend para frontend ayuda a simplificar esto al crear un servicio de middleware que maneja la lógica de obtención. GraphQL es una gran adición a este patrón, permitiendo una fácil orquestación y agregación de datos de diferentes servidores.

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.

6. Patrón Backend para Frontend y Tiempo Real

Short description:

Remix implementa naturalmente el patrón backend para frontend, proporcionando un control total del servidor web y eliminando la necesidad de orquestaciones independientes o capas de middleware. Este patrón de arquitectura puede ser utilizado en un contexto empresarial y puede ser mejorado con GraphQL para la agregación de datos. Remix ofrece flexibilidad en la implementación, soportando servidores de larga duración, entornos sin servidor y despliegues en el borde. Los patrones en tiempo real, como los utilizados en Figma y Google Docs, requieren marcos con fuertes capacidades en tiempo real.

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.

7. Capacidades en Tiempo Real y Características Colaborativas

Short description:

Ninguno de los marcos de React proporciona primitivas o convenciones para capacidades en tiempo real. Figma y Google Docs requieren construir sobre el marco. Las funciones sin servidor no admiten transmisión o servidores WebSocket, lo que dificulta la creación de una API común. Sin embargo, hay formas de crear capacidades en tiempo real en las aplicaciones de React. Se mostrarán tres patrones para implementar características colaborativas en Remix.

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.

8. Servidor WebSocket y Despliegue de Remix

Short description:

Puedes crear un servidor independiente de WebSockets y desplegarlo donde sea que se admitan los WebSockets. Puede estar separado de tu aplicación Remix, lo que te brinda flexibilidad en el despliegue. Otra opción es agregar el servidor WebSocket al mismo entorno de servidor que tu aplicación Remix. Esto permite compartir código y tipos entre el servidor WebSocket y la aplicación Remix, pero las opciones de despliegue son más limitadas.

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.

9. Server-SendEvents y Capacidades en Tiempo Real

Short description:

Server-SendEvents puede usarse como una alternativa a WebSockets para crear una conexión entre el frontend y el servidor. Remix proporciona las herramientas necesarias para mutar el estado del servidor en función del estado del cliente y sincronizarlos. Server-SendEvents se puede implementar dentro de una aplicación Remix, lo que permite una reactividad de pila completa y capacidades en tiempo real. Remix no tiene primitivas incorporadas para esto, pero se puede lograr aprovechando la plataforma Remix. Hay tres patrones en tiempo real para implementar capacidades en tiempo real en Remix, siendo Server-SendEvents particularmente emocionante. Además, hay un creciente interés y discusión en torno a Server-SendEvents y Remix. Vale la pena señalar que un número significativo de participantes comenzó a programar con Remix, destacando la necesidad de contenido amigable para principiantes y una comunidad más accesible.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
Don't Solve Problems, Eliminate Them
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
Understanding React’s Fiber Architecture
React Advanced Conference 2022React Advanced Conference 2022
29 min
Understanding React’s Fiber Architecture
Top Content
We've heard a lot about React's Fiber Architecture, but it feels like few of us understand it in depth (or have the time to). In this talk, Tejas will go over his best attempt at understanding Fiber (reviewed by other experts), and present it in an 'explain-like-I'm-five years old' way.
Making JavaScript on WebAssembly Fast
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.

Workshops on related topic

Remix Fundamentals
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Kent C. Dodds
Kent C. Dodds
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
AI on Demand: Serverless AI
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Top Content
Featured WorkshopFree
Alba Silvente Fuentes
Roberto Butti
2 authors
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
Back to the Roots With Remix
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
Alex Korzhikov
Pavlik Kiselev
2 authors
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
How to Solve Real-World Problems with Remix
Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
Michael Carter
Michael Carter
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
Build and Launch a personal blog using Remix and Vercel
Remix Conf Europe 2022Remix Conf Europe 2022
156 min
Build and Launch a personal blog using Remix and Vercel
Featured Workshop
Robert Pop
Robert Pop
In this workshop we will learn how to build a personal blog from scratch using Remix, TailwindCSS. The blog will be hosted on Vercel and all the content will be dynamically served from a separate GitHub repository. We will be using HTTP Caching for the blog posts.
What we want to achieve at the end of the workshop is to have a list of our blog posts displayed on the deployed version of the website, the ability to filter them and to read them individually.
Table of contents: - Setup a Remix Project with a predefined stack- Install additional dependencies- Read content from GiHub- Display Content from GitHub- Parse the content and load it within our app using mdx-bundler- Create separate blog post page to have them displayed standalone- Add filters on the initial list of blog posts