Patrones de Arquitectura de Remix

Rate this content
Bookmark

Remix ofrece una flexibilidad increíble y se puede implementar en cualquier lugar donde se ejecute JavaScript. Pero, ¿cómo se integra Remix en el panorama de aplicaciones más amplio de una organización? Remix ofrece una gran utilidad, pero ¿cómo aprovecharla al máximo? ¿Qué cosas se deben manejar dentro de Remix y qué cosas es 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 ideas sobre cómo integrar mejor Remix en una pila (empresarial) más grande.

23 min
18 Nov, 2022

Video Summary and Transcription

Esta charla presenta los patrones de arquitectura de Remix para aplicaciones web, con más del 50% de los participantes que utilizan 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 implementación. La escalabilidad se puede lograr mediante la distribución de la capa de base de datos y la implementación de 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 funciones colaborativas a través de servidores WebSocket y Server-Sent Events.

Available in English

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

Short description:

Una arquitectura de software es el plan para 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 utilizan 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 plan para tu aplicación. Diseñas una arquitectura para cumplir con tus requisitos y adaptarse a tu caso de uso y resolver el problema que tienes. Y luego eliges un conjunto de herramientas para implementar la arquitectura que acabas de diseñar.

Resulta que React ahora también es una arquitectura. Esto es una idea genial de Dan Abramov, quien recientemente reflexionó en Twitter sobre el estado de React. Él afirma que React ya no es solo una biblioteca, sino también una arquitectura que puede ser implementada por diferentes meta frameworks. Una idea genial, 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 e 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, enseño 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 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? 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 ciertamente son suficientes para analizar o identificar patrones de uso comunes. Dicho esto, todavía quiero mostrar algunos de los números que obtuve de la encuesta, solo porque me sorprendieron mucho.

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 se lanzó hace solo un año, pero es genial ver que una parte tan grande de la comunidad ya está ganando dinero con Remix. De aquellos que utilizan 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 obviamente también la conexión entre las dos tecnologías. Pero resulta que la gente realmente se mueve desde todo tipo de tecnologías a Remix. Las aplicaciones de página única de React todavía eran la mayor fuente o región de donde la gente se mudaba pero también se mencionó mucho Next.js, 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 desde todo tipo de antecedentes y tecnologías a Remix. Creo que esto es realmente genial de ver, pero hablemos de los patrones de arquitectura. Antes de Remix, o en general, todos 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 controlador HUP que se ejecuta sobre un entorno de servidor. Crea una Aplicación de Página Única Mejorada Progresivamente (PASPA) que funciona sin JavaScript y se adapta a la plataforma. Sin embargo, Remix es agnóstico en cuanto a la capa de base de datos, lo que nos permite elegir la nuestra propia o utilizar una de las pilas de Remix. Este es el primer patrón de arquitectura para crear aplicaciones web con Remix.

Entonces, esto es el estándar de la industria en este momento. ¿Cómo se compara Remix con eso? Cuando usas Remix de grado MPX para arrancar tu aplicación de Remix y solo eliges lo básico, terminas con esto. Y esto es un entorno de servidor, ¿verdad? Remix es un controlador HUP que se ejecuta sobre un entorno de servidor. Y si arrancas una aplicación de Remix, viene con un entorno de servidor, que ya está un poco esbozado para ti. Y en ese entorno de servidor, tienes un servidor web en el que se ejecuta el controlador HUP. Eso fue mucho. Y eso crea esta aplicación PASPA. Y PASPA es un término que significa Aplicación de Página Única Mejorada Progresivamente, acuñado por Kenzie Dodds para promover que la aplicación creada por Remix hace mucho más que una SPA. Incluso funciona sin JavaScript. Utiliza la plataforma, se adapta a la plataforma, emula los comportamientos predeterminados del navegador si JavaScript está habilitado y hace muchas más cosas por ti. Por eso todos amamos Remix. Pero si lo comparamos con la arquitectura SPA, vemos que falta la capa de base de datos. Y aquí, Remix es agnóstico, así que tenemos que elegir una base de datos por nuestra cuenta o elegir una de las pilas de Remix y vendrá de forma gratuita 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 de cualquier manera, lo que tenemos aquí es nuestro primer patrón de arquitectura. Aquí es donde todos comenzamos con Remix y es una arquitectura del sistema que podemos utilizar para crear para la web.

3. Migración de SPA a la Arquitectura de Remix

Short description:

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

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

Lo realmente genial de esta arquitectura y enfoque es que ahora puedes refactorizar tu código de SPA paso a paso para aprovechar al máximo las características que Remix proporciona. Puedes refactorizar tus consultas de uso o tus efectos de uso con las llamadas de búsqueda a formularios y usar fetcher en Remix, y realmente mejorar progresivamente tu aplicación basada en las capacidades que Remix proporciona. Al mismo tiempo, mueves más y más código del servidor de API heredado al controlador HTTP de Remix, por lo que realmente puedes hacer esto en rebanadas de características verticales y aprovechar cada vez más las capacidades de Remix. Obviamente, esto también es un patrón de arquitectura, aunque esperemos que sea temporal, porque al final del día, quieres eliminar ese servidor de API independiente y mover todo a Remix, tener control total del servidor web y terminar con esa aplicación independiente de Remix de la que hablamos anteriormente.

Pero es muy genérico, ¿verdad? Solo decimos base de datos y un entorno de servidor, así que tenemos que ser más específicos aquí para que esto sea más productivo. Si hablamos de diferentes variaciones en un lenguaje de patrones, hablamos de variantes y las variantes son en realidad lo mismo, solo tienen diferentes características. También se te permite tener una variante favorita, pero aquí solo quiero hablar de los vínculos más comunes basados en los datos de la encuesta. Y la primera variante que se mencionó más es la independiente de Node.js. Entonces, usas el adaptador ExpressJS, el servidor de aplicaciones de Remix o cualquier otro objetivo de implementación basado en Node.js y ahora tienes este servidor de aplicaciones independiente de Node.js, tu aplicación de Remix ahora se ejecuta en Node.js.

Lo 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 un servidor de API independiente, puedes pensar que es lo mismo. Ahora solo tienes Remix ejecutándose encima de eso también. También es muy flexible porque no estás atado a un proveedor de alojamiento o servicio específico. Puedes implementar esto en cualquier lugar donde se pueda implementar Node.js. Y es muy compatible con todos los paquetes npm y el código que has escrito en el pasado. Realmente es una variante genial. Otra variante alternativa es la independiente de borde. Y esta es obviamente muy vanguardista, porque ahora implementamos en un entorno de borde. Realmente creo que es una tendencia, la implementación en el borde, que Remix realmente ayudó a acelerar. Siento que todo comenzó con Remix. Remix estaba impulsando tener adaptadores para la nube, para los workers y las páginas, que también fueron los adaptadores más mencionados en la encuesta. Y siento que todo comenzó desde allí. Y ahora tenemos tantos entornos de borde diferentes para elegir, ¿verdad? Tenemos dino deploy, tenemos fly.io, que crea estos servidores de ejecución prolongada distribuidos regionalmente, que es una experiencia similar al borde. Vercell y Netlify también agregaron sus propios entornos de borde. Así que es realmente genial ver que ahora tenemos todos esos diferentes adaptadores para Remix, para implementar en el borde. Pero lo que obtenemos de todos ellos es esta proximidad geográfica a nuestros usuarios. Al implementar en el borde, distribuimos nuestra aplicación en todo el mundo en diferentes entornos de borde, diferentes servidores de borde.

4. Escalabilidad, Caché y Empresa

Short description:

Un patrón interesante es crear una aplicación escalable utilizando entornos de borde. Sin embargo, es importante considerar la capa de base de datos y distribuirla regionalmente para un rendimiento óptimo. Otro patrón es utilizar una caché de aplicaciones, como Redis, para mitigar los cuellos de botella causados por consultas frecuentes a la base de datos. Este patrón no es específico de Remix y es útil para aplicaciones complejas. En escenarios empresariales, la arquitectura de 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 de borde en realidad son sin servidor. Así que obtenemos el mismo tipo de escalabilidad que nos proporciona el sin servidor. E incluso si los entornos no son sin servidor, 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 debemos tener en cuenta aquí con esta variante es que... Y por eso también resalté la capa de base de datos, que si implementamos en diferentes regiones, también debemos hacerlo con nuestra base de datos. De lo contrario, no aprovecharemos al máximo 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 obtendremos mucho provecho. Así que también debemos distribuir regionalmente nuestra base de datos. Solo algo para tener en cuenta, pero sigue siendo una variante de patrón increíble no obstante.

Y la tercera variante es probablemente mi favorita, y se llama caché de aplicaciones. Esta es agnóstica al entorno del servidor. No importa qué entorno del servidor elijas, este patrón siempre funcionará. Solo tienes que agregar una caché de aplicaciones en memoria, como Redis, para eliminar algunos cuellos de botella. El objetivo aquí es, si tu aplicación se vuelve más compleja y tienes que hacer muchas consultas en cada solicitud, mitigar algunas de las penalizaciones en cuanto al tiempo de respuesta, al agregar una caché. Esto no es realmente un problema específico de Remix. Cuando tu aplicación se vuelve complicada, tienes que contrarrestarlo. Pero es muy fácil hacer esto con Remix. Por ejemplo, personalmente siempre consulto muchos datos desde mi raíz, como la configuración del usuario, el objeto de usuario, el siguiente video preferido para ver y las compras promocionadas, entre otros. Y tener todo eso en caché, para no tener que consultarlo en cada mutación, es una excelente manera de mitigar los cuellos de botella que pueden surgir al consultar la base de datos con demasiada frecuencia. Definitivamente, un patrón interesante. Pero hablemos de la empresa. Cuando digo empresa, eso significa que se vuelve aún más complicado, ¿verdad? Ya dijimos que nuestra aplicación puede volverse más compleja. Tienes que agregar algo como Redis, ¿verdad? Para contrarrestarlo. Pero ¿qué pasa si se vuelve cada vez más complicado, ¿verdad? Esto es básicamente empresa. Es como el jefe final en complejidad. Y cuando miramos el estándar de la industria en este momento, tenemos esta arquitectura de SPA. Entonces, empresa 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 un sistema de arquitectura única.

5. Patrón Backend for Frontend y GraphQL

Short description:

Obtener datos de múltiples APIs en un frontend puede ser complicado. El patrón backend for frontend ayuda a simplificar esto creando un servicio de middleware que maneja la lógica de obtención de datos. 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 debas obtener datos de muchas APIs diferentes que proporcionan entidades diferentes para tu aplicación, lógica empresarial diferente para tu aplicación. Y luego tienes que manejar todos esos estados de carga, estados de error, autorización y reintentos, validación optimista, todo eso para esas diferentes APIs que probablemente funcionan de manera un poco diferente dentro del frontend, dentro de tu SPA. Y eso puede volverse muy complicado y un desastre.

Por eso, muchas personas recurren a implementar el patrón de backend for frontend. 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 que oculta parte de la complejidad del sistema. Y puedes mover mucha de esa lógica de obtención de datos dentro de esta capa de orquestación. Ahora tu SPA está protegido de obtener datos de diferentes APIs y lo haces en tu backend que es para tu frontend.

Y este también es un caso de uso realmente interesante para GraphQL. Porque si agregas GraphQL en el servidor, es donde realmente brilla, ¿verdad? Orquestar solicitudes, diferentes servidores, agregar datos y luego hacerlos accesibles. Obviamente, también puedes agregar GraphQL aquí en el SPA y luego solo tienes que obtener datos de un punto final. Pero esto sigue siendo un gran caso de uso para GraphQL.

6. Patrón Backend for Frontend y Tiempo Real

Short description:

Remix implementa naturalmente el patrón backend for frontend, brindando control total del servidor web y eliminando la necesidad de orquestaciones independientes o capas de middleware. Este patrón de arquitectura se puede utilizar en un contexto empresarial y se puede mejorar con GraphQL para la agregación de datos. Remix ofrece flexibilidad en la implementación, admitiendo servidores de larga duración, entornos serverless y despliegues en el edge. Los patrones en tiempo real, como los utilizados en Figma y Google Docs, requieren frameworks con fuertes capacidades en tiempo real.

Entonces, la pregunta ahora es cómo traducimos esto a Remix? Resulta que, y nunca lo había pensado de esta manera, y creo que es genial, es que Remix implementa naturalmente el patrón backend for frontend. Muchas personas en la encuesta afirmaron que utilizan específicamente Remix para implementar una arquitectura backend for frontend. Resulta que la documentación de Remix tiene contenido al respecto que explica 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 genial que si usas Remix, obtienes control total de tu servidor web, y tu servidor web reemplaza la necesidad de cualquier orquestación independiente o capa de middleware que de otra manera necesitarías. Entonces, cuando usas Remix para implementar tu SPA, obtienes el patrón backend for frontend de forma natural proporcionado por Remix. Creo que esto es realmente genial de pensar de esta manera. Y obviamente, este es un patrón de arquitectura que podemos usar en un contexto empresarial. E incluso podemos agregar GraphQL si es necesario, ¿verdad? Ahí es donde GraphQL brilla para agregar y orquestar datos de diferentes puntos finales. Y eso se traduciría en una variante de ese patrón backend for frontend en Remix. Genial. Tenemos tres posibles patrones que identificamos que, con suerte, pasarán temporalmente a la API heredada, que actúa como un paso de migración. Y luego tenemos la aplicación independiente de Remix. Aquí es donde todos comenzamos. Y luego, si se vuelve más complicado, obtenemos de forma natural este patrón backend for frontend implementado por Remix. Esto crea esos tres patrones diferentes que identificamos. Y vimos que hay muchas variantes diferentes, y hay muchas más variantes que ni siquiera mencioné. No hablé realmente sobre Fly.io, Netlify, Resell, esos proveedores de alojamiento geniales que nos brindan muchas otras cosas interesantes. Pero realmente muestra lo flexible que es Remix en general, ¿verdad? Puedes implementar en servidores de larga duración, en entornos serverless y en el edge. Y podemos agregar fácilmente algo como Redis a nuestra aplicación para mitigar cuellos de botella y realmente variar nuestra arquitectura según nuestro caso de uso y 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 hablamos sobre patrones de arquitectura generales y ahora quiero profundizar en el tiempo real. Esta es una discusión en curso entre experiencias estáticas y experiencias muy dinámicas y qué framework es más adecuado 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 se utilizan ejemplos como Figma o Google Docs para 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 lo suficientemente larga. El espectro entre estático y dinámico, necesitamos agregar 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 reconocimiento a convex.dev que hace mucho trabajo interesante en esa área. De hecho, hay muchas startups que intentan hacer algo en esta área.

7. Capacidades en Tiempo Real y Funciones Colaborativas

Short description:

Ninguno de los frameworks de React proporciona primitivas o convenciones para capacidades en tiempo real. Figma y Google Docs requieren construir sobre el framework. Las funciones serverless no admiten servidores de streaming o WebSocket, lo que dificulta la creación de una API común. Sin embargo, existen formas de crear capacidades en tiempo real en aplicaciones de React. Se mostrarán tres patrones para implementar funciones colaborativas en Remix.

Pero desde una perspectiva de framework, creo que ninguno de los frameworks que tenemos actualmente en el ecosistema de React proporciona primitivas o convenciones para implementar capacidades en tiempo real. Cuando hablamos de algo como Figma o Google Docs, esto no es algo en lo que el framework te ayude. Simplemente tienes que construir esas cosas sobre lo que el framework proporciona. Dicho esto, tampoco es realmente una falla de esos frameworks, porque hay muchas preguntas abiertas a nivel de infraestructura. Solo para darte un ejemplo, las funciones serverless intuitivamente no admiten algo como el streaming, 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. Aún hay muchas construcciones en curso y preguntas abiertas, pero aún existen formas en este momento para crear capacidades en tiempo real en tus aplicaciones de React. Solo quiero mostrar tres patrones diferentes sobre cómo implementar funciones colaborativas en Remix.

8. Servidor WebSocket y Despliegue de Remix

Short description:

Puedes crear un servidor WebSocket independiente y desplegarlo donde se admitan los WebSockets. Puede ser 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 WebSocket independiente. Probablemente sea el más sencillo. Simplemente creas un servidor independiente con un servidor WebSocket encima y ahora puedes desplegarlo donde se admitan los WebSockets, como un servidor Node.js en ejecución, por ejemplo. Y lo tienes separado de tu aplicación Remix. Lo bueno 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 actualmente no admiten WebSockets.

Dado que tu servidor WebSocket es independiente, aún puedes desplegar tu aplicación Remix allí. Y luego debes tener esto, como tu aplicación del lado del cliente de tu aplicación Remix, tiene que comunicarse con el servidor WebSocket. Y debes eliminar parte de la lógica que anteriormente manejabas en Remix con WebSockets ahora. Pero funciona y es una excelente manera de agregar capacidades en tiempo real. Aún mejor, creo, dependiendo de los casos de uso, es agregar el servidor WebSocket al mismo entorno de servidor que utilizas 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 hacer que tu servidor WebSocket se ejecute junto a tu controlador HTTP de Remix. Lo realmente genial de esto es que con Remix estábamos tan contentos de poder 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 debemos asegurarnos de que este entorno también admita WebSockets.

9. Server-SendEvents y Capacidades en Tiempo Real

Short description:

Server-SendEvents se puede utilizar 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 basado en el 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. Cabe destacar que un número significativo de participantes comenzaron a programar con Remix, lo que resalta la necesidad de contenido amigable para principiantes y una comunidad más accesible.

Esto 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. Ahora usamos Server-SendEvents 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. No es bidireccional como WebSockets, pero si lo piensas bien, la otra forma ya está cubierta con Remix.

Remix proporciona todo lo que necesitamos para mutar nuestro estado del servidor basado en nuestro estado del cliente. Entonces, esto incluye formularios y envío de formularios y uso de fetch. Ya podemos mutar data. Y luego, como Remix valida automáticamente nuestro estado del cliente y sincroniza nuestro estado del cliente con nuestro estado del servidor. Lo único que queda es informar a un cliente si otro cliente cambia el estado del servidor. Correcto. Eso es lo que significa la reactividad de pila completa en ese sentido. En el servidor de pila completa. Si cambias el estado, tu cliente reacciona a estos cambios y el servidor envía eventos para informar de un cambio. Y luego puedes desencadenar una nueva validación en el payload e incluso incluir la entidad que ha sido actualizada y luego gestionar eso en el estado de React.

Lo que es realmente genial acerca de los eventos del lado del servidor es que realmente puedes implementar en tu aplicación Remix. Entonces, 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 simplemente puedes usar la plataforma en el lado del frontend de tu aplicación remix y un factor de usuario react para crear la conexión a ese punto final. Y ahora tienes una reactividad de pila completa y capacidades en tiempo real para experiencias colaborativas multijugador en tu aplicación remix hoy. Remix no proporciona primitivas y convenciones para manejar eso, pero dado que Remix expone la plataforma para nosotros, esto está básicamente soportado de manera nativa con Remix hoy. Y creo que es simplemente genial.

Entonces, aquí tenemos tres patrones en tiempo real para 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 acerca de los eventos del lado del servidor. Y también hay mucho interés en este tema en GitHub, en la discusión sobre eventos del lado del servidor y Remix. Y estoy realmente emocionado de ver a dónde nos lleva esto. Pero al final, quiero dejarte con un dato 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 desarrollar web con Remix. Probablemente me hubiera ayudado a comprender mejor la plataforma antes de sumergirme en React. Ahora, siento que muchas veces pienso de manera React aunque quiero pensar de 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 es hacer que la comunidad sea más accesible para 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

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!
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.
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.
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.
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.
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

React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
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
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
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.
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
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.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
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)
Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
- 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
Remix Conf Europe 2022Remix Conf Europe 2022
156 min
Build and Launch a personal blog using Remix and Vercel
Featured Workshop
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