React on the Edge

Hola. Bienvenido a React on the Edge, construyendo aplicaciones de React para dispositivos Edge con recursos limitados. Mi nombre es Amir Sami. Soy un ingeniero de software en S&C Electric Company. Para que nos conozcamos mejor, les contaré sobre mí rápidamente. En mi tiempo libre me gusta hornear deliciosos productos horneados como este pastel. Me gusta programar. No es solo una profesión. También es un pasatiempo mío.

Me gusta hacer senderismo y explorar la naturaleza y me gusta levantar círculos pesados por alguna extraña razón. Ahora, trabajo para una empresa llamada S&C Electric Company y S&C Electric es un proveedor global de equipos y servicios para sistemas de energía eléctrica. Fuimos fundados en 1911 en Chicago, donde diseñamos y fabricamos productos de conmutación y protección. Hoy, nuestra diversa fuerza laboral global desarrolla soluciones innovadoras para una red eléctrica más inteligente y resiliente.

Basándonos en este legado de innovación tecnológica y servicio al cliente, S&C impulsa la transformación de la red para un futuro de energía eléctrica sostenible y sin interrupciones. Estoy seguro de que todos hemos oído hablar de React porque estamos en React Summit. Y cuando piensas en React y aplicaciones de React, piensas en crearlas para dispositivos web, ¿verdad? Para un navegador. Así que un dispositivo de escritorio o un dispositivo móvil con React Native, por ejemplo. Pero ¿qué pasa con las cosas que van más allá del navegador web, fuera de estos tipos de dispositivos? ¿Qué pasa con el Edge? Probablemente te estés preguntando, ¿qué diablos quiero decir con el Edge? El Edge puede significar un montón de cosas diferentes.

Pero en el contexto de esta charla, estoy definiendo Edge como una multitud de diferentes dispositivos como un quiosco o una especie de sistema de punto de venta que tiene su propia pantalla incorporada. También podría ser un dispositivo más embebido, como un router Wi-Fi. Estoy seguro de que todos han tenido un router Wi-Fi y han tenido que configurar algunos ajustes en él. Y la forma en que lo haces es navegando a una URL web, que es servida por el router Wi-Fi. Y luego estás configurando los ajustes del router Wi-Fi de esa manera. Otros dispositivos HMI o interfaz humano-máquina que tienen algún tipo de pantalla con la que estás interactuando.

Y por último, solo por diversión, un cohete. Y con esto, me refiero específicamente a esta cápsula Dragon de SpaceX, si recuerdas de hace unos años. Ellos alojaron o crearon una aplicación web que los astronautas, lo cual es realmente genial decir, que los astronautas estaban usando para interactuar con su cápsula Dragon. Así que te mostraré eso en solo unos momentos.

Pero todos estos juntos, puedes crear aplicaciones de React y desplegarlas en cualquier tipo de dispositivo Edge como los que acabo de definir. Y solo por diversión, aquí hay un pequeño fragmento rápido de la cápsula Dragon de SpaceX. Y toda la interfaz de usuario en las pantallas aquí, hasta donde yo sé, al menos está ejecutando una aplicación web. No está usando React, desafortunadamente. Está usando su propio marco interno que desarrollaron.

Pero es realmente genial ver tecnologías web funcionando en algo tan increíble como una cápsula Dragon que va al espacio. Así que podemos crear aplicaciones de React para este tipo de dispositivos.

Ahora hay dos subcategorías separadas dentro de esto que estoy dividiendo para el propósito de esta charla también. Así que hay dispositivos que tienen su propia pantalla, por lo que es una especie de sistema cerrado. Y eso es lo que pondría como un quiosco o un sistema de punto de venta o la cápsula Dragon, la interfaz de usuario para los astronautas. Y luego hay dispositivos que no tienen una interfaz, sino que están enviando una aplicación web a un dispositivo cliente para consumir, como un portátil o dispositivo de escritorio o un dispositivo móvil también. Entonces, ¿cómo construimos aplicaciones de React para este tipo de dispositivos, este tipo de plataformas?

Hay cuatro cosas diferentes de las que quiero hablar específicamente para ayudarte a desplegar aplicaciones para este tipo de plataformas. Y la primera es PWAs o aplicaciones web progresivas. Así que, como acabo de mencionar, dispositivos como un router Wi-Fi, tradicionalmente para enviar una página web a tu dispositivo, tu dispositivo cliente, al igual que cualquier otro servidor web lo haría, que es exactamente a lo que estamos acostumbrados para desarrollar aplicaciones web.

Pero hay un puñado de problemas con la construcción de aplicaciones web o aplicaciones de React para dispositivos edge de esta manera. El primero es que existe la posibilidad de conexiones de red más lentas e inestables. En el caso de un router Wi-Fi, no es necesariamente cierto porque es un router Wi-Fi que se supone que debe ser bastante estable. Pero si piensas en otros dispositivos edge que están transmitiendo una señal inalámbrica, por ejemplo, o simplemente sirviendo un servidor web, una aplicación web, la conexión podría no ser estable porque podría ser a través de Bluetooth o Wi-Fi desde una placa que tiene chips poco potentes. Podría ser a través de algo como una conexión serie o una conexión ethernet también que podría no ser tan estable además de ser simplemente lenta.

Podría ser a través de algo como una conexión serie o una conexión ethernet también que podría no ser tan estable además de ser simplemente lenta.

Lo siguiente es la limitación de recursos. Así que si alguna vez has trabajado con este tipo de dispositivos edge y equipos que trabajan más de cerca con el lado del hardware, sabrás que hay muchas restricciones de recursos en estos dispositivos. Y así que si intentas construir una aplicación web tradicional o aplicación de React, digamos que es tal vez como 500 kilobytes de tamaño o 300 kilobytes de tamaño, vendrán a ti y dirán algo como, oh, ya sabes, no tenemos el espacio físicamente en el dispositivo para almacenar tu aplicación, y mucho menos el servidor que sirve tu aplicación al lado del cliente. Así que hay muchas restricciones de recursos que vienen con el despliegue de aplicaciones a estos dispositivos edge.

Luego está el almacenamiento innecesario de activos de la aplicación que va de la mano con las restricciones de recursos. Así que si quieres tener imágenes o videos o documentos o PDFs o lo que sea, cualquier tipo de activo estático, te encuentras con el problema de que simplemente la restricción de recursos de almacenamiento en el dispositivo. Luego está el tráfico de red pesado para el primer renderizado. Así que si lo estás estructurando como una aplicación web tradicional en combinación con la conexión de red lenta o inestable, si tienes múltiples solicitudes de red yendo y viniendo para recuperar múltiples recursos, tu aplicación podría retrasarse o podría simplemente, ya sabes, potencialmente romperse si la conexión se vuelve realmente, realmente inestable. Así que eso es otro problema.

Y por último, si nuevamente, si has trabajado con este tipo de plataforma o desplegando aplicaciones a este tipo de plataformas embebidas, sabrás que cualquier tipo de actualización, ya sea a la interfaz de usuario o al firmware, requiere una actualización de firmware porque la aplicación web está almacenada y alojada y servida desde el dispositivo embebido. Y no sé tú, pero no sé cuándo fue la última vez que actualicé el firmware en mi router Wi-Fi, por ejemplo, o incluso mi placa base en mi PC. Y, ya sabes, eso causa muchos problemas, ya sabes, en la situación actual donde hay muchas CVEs saliendo como hemos visto en el último año, abordar esos o solucionar esos puede requerir un esfuerzo realmente grande de tu usuario. Y eso es solo un problema que viene con alojar la aplicación en el dispositivo embebido.

Entonces, ¿cómo abordamos todos estos problemas, todos estos problemas que acabo de mencionar? Bueno, podemos aprovechar PWAs o aplicaciones web progresivas. Así que en teoría, es bastante simple. Todo lo que realmente haces es desplegar tu aplicación web a un servicio en la nube como lo harías tradicionalmente. Proporcionas algunas instrucciones a tu usuario sobre cómo guardar la aplicación como una aplicación web progresiva en su respectivo dispositivo, y luego se almacena en caché en ese dispositivo. Y luego ellos inician una conexión a tu firmware, tu dispositivo edge, y a través de la PWA, simplemente establece una conexión y comienza a poblar la interfaz de usuario o la interfaz con los datos de tu dispositivo edge. Y es tan simple como eso. Al final del día, al hacer esto, el dispositivo edge se vuelve realmente simple porque es solo una API delgada que sirve datos en lugar de un servidor web completo que sirve una aplicación web. Mejora el SCP, el primer renderizado con contenido, para la aplicación porque está almacenada en caché en el dispositivo del cliente. No hay restricciones de recursos porque todo está en el dispositivo del cliente que tiene más RAM y más almacenamiento. Es más fácil actualizar la interfaz de usuario de la aplicación porque simplemente haces tu cambio y lo despliegas a tu servicio en la nube. Y la PWA, configurarás un Service Worker que buscará actualizaciones de ese servicio en la nube, ese servidor en la nube, y extraerá esos últimos cambios una vez que se establezca una conexión de red regular. Y por último, libera recursos en el dispositivo edge, lo cual es increíble porque tu equipo de firmware realmente lo amará porque les dará más espacio para registros o simplemente otras aplicaciones críticas en el firmware, el dispositivo edge. Así que eso es PWAs. Y no entraré en los detalles de desarrollar PWA porque realmente varía dependiendo del framework que estés usando. Pero diría que la mayoría de los, si no todos los grandes frameworks o frameworks populares que están ahí fuera soportan PWAs con alguna configuración realmente simple. Incluso Vite lo hace, por ejemplo, y eso es solo como un plugin de Vite que luego configuras.

Pasando al empaquetado. Así que todos sabemos que hay un montón de empaquetadores en el ecosistema como ESBuild o RSPack o Vite, Webpack, Rollup, así como Rolldown, que salió muy recientemente, y Bunn, entre muchos otros. Estos son solo algunos de los que quería listar en esta diapositiva. Y elegir el empaquetador correcto para tu caso de uso realmente varía. Así que no hay un empaquetador específico que pueda recomendar para desarrollar y desplegar aplicaciones de React en dispositivos edge. Pero quería señalar una cosa, que es realmente importante elegir el empaquetador correcto. Así que hice una comparación rápida entre Webpack y Rollup en términos de empaquetar una aplicación con una configuración muy similar. Y pude lograr una diferencia de aproximadamente un 17% entre los dos. En este caso, fue una mejora o disminución en el tamaño del paquete al usar Rollup. Así que usar el empaquetador correcto puede hacer una gran, gran diferencia para ti. Y por eso te animo mucho a seleccionar el correcto para tu caso de uso.

A continuación están los activos. Así que si tu aplicación tiene activos, lo cual es muy probable, es realmente importante elegir el formato de archivo correcto para tus activos. Así que para imágenes, por ejemplo, es realmente importante usar un formato de archivo de imagen como WebP en lugar de JPEG. Y por qué es importante es porque puedes lograr una optimización del tamaño del archivo de aproximadamente un 25 a 35%, 34% solo cambiando a WebP como tu formato de archivo. Y hay un montón de herramientas de conversión por ahí si quieres usarlas, o puedes usar ffmpeg también para hacer esa conversión. Y ahorrarás una gran cantidad de espacio en términos del tamaño de tu aplicación. Además de las imágenes, puedes configurar tu empaquetador para incrustar tus activos estáticos. Ahora, obviamente hay contras con esto, pero creo que es realmente genial y también realmente importante notar que puedes desactivar las importaciones dinámicas incrustadas y forzar a tu empaquetador, en este caso esto es como una configuración simple de beat, para incrustar todos tus activos estáticos. De esa manera, cuando tu página simplemente carga tus activos allí y no hay una solicitud de red de ida y vuelta a tu dispositivo edge. Y nuevamente, esto tiene algunos contras donde el tamaño de tu paquete aumentará porque no hay división de tu aplicación en diferentes fragmentos. Así que solo toma eso con pinzas y ve si eso funciona para tu caso de uso.

Ahora, Preact. Así que nuevamente, este es React Summit. Estoy asumiendo que todos han oído hablar de React, pero ¿qué hay de Preact? Preact es como un primo de React, si quieres pensarlo así. Y para aquellos de ustedes que no saben qué es Preact rápidamente, Preact es una alternativa de tres kilobytes a React. Esto es directamente de sus propios documentos. Es un reemplazo directo para React. Y lo pongo entre comillas, entenderás por qué en un momento. Y es independiente.

No es, no reemplaza todas las APIs de React, desafortunadamente, pero hay una forma de solucionar eso. Y la forma de solucionarlo es Preact compat, que es una biblioteca separada que resuelve los problemas de compatibilidad con las APIs de React y hace que soporte casi todas las APIs de React. Ahora, las APIs de React que no soporta. Así que no soporta los componentes de servidor de React. No soporta el hook use o el hook use action state o el hook use effect event o el componente de actividad. Así que básicamente cualquiera de las APIs o componentes o hooks realmente nuevos que React está lanzando, Preact no los lanzará, desafortunadamente. Pero si estás construyendo una aplicación para dispositivos edge, creo que puedes prescindir de esos por las optimizaciones de tamaño de paquete que Preact te proporciona al cambiar a Preact. Y lo que eso parece aquí es que con React, con React DOM es alrededor de 93 kilobytes frente a Preact con Preact compat es 9.6 kilobytes. Así que, ya sabes, hay una disminución drástica en el tamaño del paquete solo al cambiar a Preact. Y obtienes la mayoría de la funcionalidad que estás buscando. También hay toneladas de bibliotecas por ahí que sí soportan Preact o tienen una variante de Preact. Incluso algo como React Query tiene una variante para Preact, lo cual creo que es increíble. Y, ya sabes, si estás usando React Query, te facilita mucho cambiar también. Así que, nuevamente, alrededor de un 90% de disminución en el tamaño del paquete. Y aún te permite usar una mayoría de las bibliotecas y herramientas de React que existen. Y si estás construyendo una aplicación para dispositivos edge, entonces te recomiendo encarecidamente que cambies a esto ya que liberará mucho espacio en tu dispositivo edge.

Y por último está la compresión. Así que, puede que sepas o no, pero la mayoría de los empaquetadores por ahí habilitarán automáticamente Gzip para tu compresión para tus activos, tu salida de tu empaquetador. Y Gzip es un algoritmo de compresión increíble. Así que, es como el algoritmo de compresión estándar para aplicaciones web. Fue creado en 1992 y es compatible con todos los navegadores. Y logra alrededor de un 50 a 70% de compresión para activos web. Pero puede que no sepas esto. Hay un algoritmo de compresión diferente o más nuevo que está por ahí y se llama Brotli. Y este es su logo. Realmente no entiendo su logo, pero este es su logo. Así que, Brotli fue creado en 2015 y es compatible con todos los navegadores. Y lo más importante es que logra alrededor de un 20 a 30% mejor compresión que Gzip. Y la forma en que lo hace es que tiene un diccionario estático para aplicaciones web específicamente. Eso es alrededor de 13,000 palabras de longitud.

Y así es como logra esta mejora sobre Gzip. Es porque está construido específicamente para aplicaciones web. Y así, puedes cambiar a Brotli y todos los navegadores entenderán el formato de archivo de compresión Brotli y lo descomprimirán en el cliente.

Así que, puedes reducir aún más tus paquetes simplemente cambiando a Brotli. Así que, esos son algunos consejos y trucos rápidos sobre cómo puedes construir aplicaciones React para dispositivos Edge. Nuevamente, depende mucho de la configuración de tu dispositivo Edge y de cómo estás desplegando en él. Y cada equipo es muy diferente.

Pero al final del día, el tamaño del paquete realmente importa. Y eso es todo. Así que, muchas gracias. Por favor, mantente en contacto. Conéctate conmigo en LinkedIn, mi sitio web. Si tienes alguna pregunta o quieres hablar más sobre el desarrollo de aplicaciones React para dispositivos Edge, envíame un correo electrónico y trataré de responder lo más rápido posible. Muy bien. Gracias. Adiós.