Patrones de Arquitectura Remix

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at Remix Conf Europe 2022, check out the latest edition of this React Conference.

FAQ

Una arquitectura de software es el plano de una aplicación, diseñada para cumplir con requisitos específicos, adaptarse al caso de uso y resolver problemas particulares.

Dan Abramov ha mencionado que React ha evolucionado de ser solo una biblioteca a ser también una arquitectura que puede ser implementada por diferentes meta frameworks.

Más del 50% de los participantes de la encuesta afirmaron que utilizan Remix de manera profesional.

PASPA significa Aplicación de Página Única Mejorada Progresivamente, un término acuñado por Kenzie Dodds para describir las aplicaciones creadas con Remix, las cuales incluso funcionan sin JavaScript y emulan comportamientos predeterminados del navegador.

El patrón 'Backend para Frontend' implica crear un servicio de middleware que maneja la complejidad y las solicitudes para un frontend. Remix implementa naturalmente este patrón, permitiendo que el servidor web maneje la orquestación necesaria para el frontend.

Los eventos del lado del servidor (Server-SendEvents) son preferidos para agregar capacidades en tiempo real a una aplicación Remix, permitiendo una conexión unidireccional entre el servidor y el cliente para la reactividad completa.

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: Remix Architecture Patterns

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

Escalando con Remix y Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Escalando con Remix y Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
No resuelvas problemas, elimínalos
React Advanced 2021React Advanced 2021
39 min
No resuelvas problemas, elimínalos
Top Content
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
Entendiendo la Arquitectura Fiber de React
React Advanced 2022React Advanced 2022
29 min
Entendiendo la Arquitectura Fiber de React
Top Content
This Talk explores React's internal jargon, specifically fiber, which is an internal unit of work for rendering and committing. Fibers facilitate efficient updates to elements and play a crucial role in the reconciliation process. The work loop, complete work, and commit phase are essential steps in the rendering process. Understanding React's internals can help with optimizing code and pull request reviews. React 18 introduces the work loop sync and async functions for concurrent features and prioritization. Fiber brings benefits like async rendering and the ability to discard work-in-progress trees, improving user experience.
Thinking Like an Architect
Node Congress 2025Node Congress 2025
31 min
Thinking Like an Architect
Top Content
In modern software development, architecture is more than just selecting the right tech stack; it involves decision-making, trade-offs, and considering the context of the business and organization. Understanding the problem space and focusing on users' needs are essential. Architectural flexibility is key, adapting the level of granularity and choosing between different approaches. Holistic thinking, long-term vision, and domain understanding are crucial for making better decisions. Effective communication, inclusion, and documentation are core skills for architects. Democratizing communication, prioritizing value, and embracing adaptive architectures are key to success.
Componentes de Full Stack
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Componentes de Full Stack
Top Content
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.

Workshops on related topic

Domina los Patrones de JavaScript
JSNation 2024JSNation 2024
145 min
Domina los Patrones de JavaScript
Top Content
Featured Workshop
Adrian Hajdin
Adrian Hajdin
Durante esta masterclass, los participantes revisarán los patrones esenciales de JavaScript que todo desarrollador debería conocer. A través de ejercicios prácticos, ejemplos del mundo real y discusiones interactivas, los asistentes profundizarán su comprensión de las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables. Al final de la masterclass, los participantes ganarán una nueva confianza en su capacidad para escribir código JavaScript de alta calidad que resista el paso del tiempo.
Puntos Cubiertos:
1. Introducción a los Patrones de JavaScript2. Patrones Fundamentales3. Patrones de Creación de Objetos4. Patrones de Comportamiento5. Patrones Arquitectónicos6. Ejercicios Prácticos y Estudios de Caso
Cómo Ayudará a los Desarrolladores:
- Obtener una comprensión profunda de los patrones de JavaScript y sus aplicaciones en escenarios del mundo real- Aprender las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables- Mejorar las habilidades de resolución de problemas y la legibilidad del código- Mejorar la colaboración y la comunicación dentro de los equipos de desarrollo- Acelerar el crecimiento de la carrera y las oportunidades de avance en la industria del software
IA a demanda: IA sin servidor
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
IA a demanda: IA sin servidor
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
En esta masterclass, discutimos los méritos de la arquitectura sin servidor y cómo se puede aplicar al espacio de la IA. Exploraremos opciones para construir aplicaciones RAG sin servidor para un enfoque más lambda-esque a la IA. A continuación, nos pondremos manos a la obra y construiremos una aplicación CRUD de muestra que te permite almacenar información y consultarla utilizando un LLM con Workers AI, Vectorize, D1 y Cloudflare Workers.
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
React Day Berlin 2022React Day Berlin 2022
86 min
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
Top Content
Workshop
Hussien Khayoon
Kahvi Patel
2 authors
Usar una biblioteca puede parecer fácil a primera vista, pero ¿cómo eliges la biblioteca correcta? ¿Cómo actualizas una existente? ¿Y cómo te abres camino a través de la documentación para encontrar lo que quieres?
En esta masterclass, discutiremos todos estos puntos finos mientras pasamos por un ejemplo general de construcción de un editor de código usando CodeMirror en React. Todo mientras compartimos algunas de las sutilezas que nuestro equipo aprendió sobre el uso de esta biblioteca y algunos problemas que encontramos.
Webinar gratuito: Construyendo aplicaciones Full Stack con Cursor
Productivity Conf for Devs and Tech LeadersProductivity Conf for Devs and Tech Leaders
71 min
Webinar gratuito: Construyendo aplicaciones Full Stack con Cursor
Top Content
WorkshopFree
Mike Mikula
Mike Mikula
Para asistir al webinar, por favor regístrate aquí.En este webinar cubriré un proceso repetible sobre cómo iniciar aplicaciones Full Stack en Cursor. Espera entender técnicas como usar GPT para crear requisitos de producto, esquemas de base de datos, hojas de ruta y usar esos en notas para generar listas de verificación que guíen el desarrollo de la aplicación. Profundizaremos más en cómo corregir alucinaciones/errores que ocurren, indicaciones útiles para hacer que tu aplicación se vea y se sienta moderna, enfoques para conectar cada capa y más. Al final, ¡espera poder ejecutar tu propia aplicación Full Stack generada por IA en tu máquina!
Fundamentos de Remix
React Summit 2022React Summit 2022
136 min
Fundamentos de Remix
Top Content
Workshop
Kent C. Dodds
Kent C. Dodds
Construir aplicaciones web modernas está lleno de complejidad. Y eso solo si te molestas en lidiar con los problemas
¿Cansado de conectar onSubmit a las API del backend y asegurarte de que tu caché del lado del cliente se mantenga actualizada? ¿No sería genial poder utilizar la naturaleza global de CSS en tu beneficio, en lugar de buscar herramientas o convenciones para evitarla o trabajar alrededor de ella? ¿Y qué te parecería tener diseños anidados con una gestión de datos inteligente y optimizada para el rendimiento que simplemente funciona™?
Remix resuelve algunos de estos problemas y elimina completamente el resto. Ni siquiera tienes que pensar en la gestión de la caché del servidor o en los conflictos del espacio de nombres global de CSS. No es que Remix tenga APIs para evitar estos problemas, simplemente no existen cuando estás usando Remix. Ah, y no necesitas ese enorme y complejo cliente graphql cuando estás usando Remix. Ellos te tienen cubierto. ¿Listo para construir aplicaciones más rápidas de manera más rápida?
Al final de esta masterclass, sabrás cómo:- Crear Rutas de Remix- Estilizar aplicaciones de Remix- Cargar datos en los cargadores de Remix- Mutar datos con formularios y acciones