Escalando Aplicaciones React con Paralelismo: Patrones para UIs Multi-Hilo

Hola a todos. Estoy realmente emocionado de profundizar en un tema que se está convirtiendo rápidamente en un elemento imprescindible en las aplicaciones web modernas, que es la multitarea en React. A medida que nuestras UIs se vuelven más ricas, tal vez piensen en tablas de datos gigantes, paneles en tiempo real y animaciones en canvas. Mantenerse en un solo hilo puede llevar a atascos, congelamientos y experiencias de usuario frustrantes. Así que hoy vamos a liberarnos de esas limitaciones utilizando web workers y canvas fuera de pantalla.

Estas son dos características del navegador que pueden ayudarnos a mantener nuestras aplicaciones increíblemente fluidas sin importar la carga de trabajo. Antes de comenzar, una rápida introducción. Soy Sribam Gautam, un ingeniero de software senior en Headout. Durante los últimos años, he trabajado en aplicaciones React a gran escala, desde flujos de reserva en tiempo real hasta UIs inmersivas con miles de usuarios activos diarios. Las técnicas que compartiré provienen de desafíos del mundo real que enfrento al empujar los límites de lo que es posible en el navegador.

Todos sabemos esto, JavaScript se ejecuta en un solo hilo. Eso significa que si algo está bloqueando el hilo, digamos un cálculo pesado, toda la aplicación se congela. Incluso operaciones simples como mapear o filtrar grandes arreglos pueden bloquear la UI. En React, es peor, porque tanto la lógica de tu componente como el renderizado ocurren en el mismo hilo. Así que echemos un vistazo a lo que eso podría significar para los usuarios. ¿Alguna vez han escrito en un cuadro de búsqueda y notaron que sus pulsaciones de teclas se retrasan? O tal vez intentaron desplazarse por una tabla masiva que simplemente se congela por un momento?

Es probable que el hilo principal esté sobrecargado. En las aplicaciones React modernas, esto puede suceder por todo tipo de razones. Tal vez ordenando tablas masivas, renderizando visualizaciones complejas, y tal vez validando formularios profundamente anidados. Pero lo que es frustrante aquí es que muchos equipos simplemente aceptan que este tipo de problemas es inevitable. Pero, honestamente, no lo es. Hay una mejor manera. Una que te brinda experiencias de usuario fluidas y receptivas sin comprometer realmente la complejidad o las características de tu aplicación. Así que vamos a profundizar.

¿Entonces, qué podemos hacer sobre la naturaleza de un solo hilo de JavaScript? Afortunadamente, los navegadores modernos nos dan herramientas para liberarnos del hilo principal sin romper realmente nuestras aplicaciones. Las dos características clave de las que hablaremos hoy son web workers y canvas fuera de pantalla. Los web workers nos permiten crear hilos en segundo plano. Piénsalos como pequeños motores de JavaScript que están funcionando en paralelo, que son absolutamente perfectos para cálculos pesados. Luego, hablando de canvas fuera de pantalla. El canvas fuera de pantalla va un paso más allá. Nos permite mover el renderizado mismo del hilo principal. Eso significa animaciones y gráficos también. Pero aquí está el truco. No se trata solo de lanzar todo a un worker. Se trata de descargar estratégicamente para averiguar qué está ralentizando las cosas, qué no necesita acceso al DOM y qué se puede hacer de manera segura en segundo plano.

Nuestro objetivo aquí es asegurar que nuestro hilo principal esté enfocado en la responsividad del usuario, mientras que los hilos en segundo plano manejan todo el trabajo pesado. Así que ahora comencemos con los web workers. En su núcleo, un web worker es JavaScript ejecutándose en un hilo separado. Así es como podría verse en un componente de React. Creas un worker cuando el componente se monta. Te comunicas con él usando postMessage. Luego escuchas los resultados mediante onMessage, y siempre limpias cuando el componente se desmonta. La comunicación aquí ocurre a través de un sistema de mensajería. Enviamos datos al worker con postMessage, y recibimos resultados a través del evento onMessage. Esto realmente mantiene nuestro hilo de UI libre, incluso cuando estamos procesando grandes datos.

Así que aquí está cómo se ve el worker en sí. Lo primero a notar es que los web workers se ejecutan en un contexto completamente separado. No tienen acceso al DOM ni a los componentes de React. Escucha mensajes, ejecuta tus tareas pesadas de CPO, como transformar o filtrar datos, y luego envía los resultados de vuelta con postMessage. Piénsalo como un mini servidor que está funcionando dentro de tu navegador, que está realmente diseñado para descargar todo el trabajo pesado. Así que con esta configuración, tu aplicación se vuelve más inteligente sobre la delegación. Las tareas pesadas van al worker, mientras que tu UI se mantiene enfocada en la interacción del usuario. Ahora, veamos cuánto puede marcar la diferencia los web workers. En esta demostración, estamos calculando números primos hasta 100,000.

Cuando la computación se ejecuta en el hilo principal, notarás que la tasa de fotogramas cae drásticamente. Baja de 120 FPS a solo 54 FPS. Eso significa que el desplazamiento se volverá entrecortado, los clics tendrán retraso y la UI se sentirá lenta. Ahora, cuando la misma tarea se cambia a web workers, la tasa de fotogramas se mantiene constante en 120 FPS.

Esto significa que nuestra UI seguirá siendo suave como la mantequilla. No habrá retrasos, no habrá entrecortes. Hablando del tiempo de computación, es ligeramente mejor con web workers, pero lo más importante es que no bloquea la experiencia del usuario. Aquí está la clave.

Cuando llevé esto a un millón de puntos de datos, la versión del hilo principal realmente se bloqueó en mi navegador. Mientras tanto, la versión impulsada por el worker aún completó la tarea, así que sin congelamientos, sin bloqueos, sin preocupaciones. Ahora, antes de continuar, es imperativo entender las limitaciones de los web workers. Los workers no tienen acceso al DOM, lo que significa que no pueden manipular directamente la conferencia de React o acceder al documento. También no tienen acceso a todas las APIs del navegador, y se ejecutan en un espacio de memoria completamente separado de tu aplicación principal.

Esta separación es en realidad por diseño. Previene condiciones de carrera y otros problemas de subprocesos que vienen con la programación multihilo. Así que, significa que necesitamos ser reflexivos sobre lo que descargamos a los workers y cómo estructuramos nuestra comunicación. Pero la buena noticia aquí es que la mayoría de las operaciones intensivas en CQ que realmente se beneficiarían de ser movidas a un worker no necesitan acceso al DOM, así que esta limitación realmente se convierte en un obstáculo.

Ahora, llevémoslo un paso más allá. ¿Qué pasa si queremos descargar el renderizado gráfico? Ahí es donde entra el canvas fuera de pantalla. Este ejemplo de código que ves, en realidad muestra cómo puedes transferir el control de un elemento canvas a un worker. La magia sucede con el método de transferencia de control a offscreen, que en realidad crea un objeto de canvas fuera de pantalla que puede ser enviado a un worker.

Una vez transferido, el worker puede dibujar en este canvas sin tocar realmente el hilo principal. Eso es perfecto para visualizaciones en tiempo real, simulaciones o tal vez animaciones pesadas también. Siguiendo adelante, así es como se ve la implementación del worker para nuestro ejemplo de canvas fuera de pantalla. Así que, una vez que recibe el canvas del hilo principal, puede comenzar a renderizarlo directamente. El worker configura un bucle de animación usando request animation frame, justo como lo harías en el hilo principal.

Pero la diferencia aquí es que todas las operaciones de dibujo ocurren en el segundo plano. Así que, incluso si el hilo principal está ocupado, tus animaciones continúan ejecutándose sin problemas. Esto es realmente un cambio de juego para paneles de control, mapas, juegos y mucho más.

Así que, hay un desafío al trabajar con WebWorker, que es gestionar la comunicación de manera efectiva. El simple post message o patrón de mensaje funciona para escenarios básicos, pero en aplicaciones reales, a menudo tendrás múltiples tipos de tareas y tal vez necesites una comunicación más sofisticada.

Así que, este ejemplo muestra un enfoque basado en promesas para la comunicación con el worker. Creamos un ID único para cada tarea, configuramos un listener de una sola vez para la respuesta, y envolvemos todo en una promesa. Así que, este patrón en realidad nos permite usar async con nuestra tarea de worker y realmente hace que nuestro código sea mucho más legible.

Este patrón también incluye manejo de errores, que es crucial para aplicaciones robustas. Hablaremos de esto más tarde. Así que, si algo sale mal en este hilo, en realidad podemos capturar todo eso en nuestro código de aplicación principal. Ahora, pasemos a otro tema.

Hablemos sobre cómo podemos hacer que nuestra transferencia de datos entre hilos sea más eficiente. Así que, por defecto, cuando pasas datos a un WebWorker usando post message, esos datos se copian. Para cargas pequeñas, eso sigue siendo aceptable, pero una vez que comienzas a tratar con grandes conjuntos de datos, la copia se convierte en un serio cuello de botella de rendimiento. Y es tanto en términos de tiempo como de uso de memoria. Ahora, para resolver esto, tenemos dos técnicas avanzadas que optimizan drásticamente este flujo. La primera son los objetos transferibles. Los objetos transferibles en realidad permiten una transferencia de cero copias de objetos como el buffer de arreglo. Esto es increíblemente útil al trabajar con datos binarios, imágenes, o tal vez grandes arreglos numéricos. Así que, lo que sucede aquí es que, en lugar de copiar los datos, la propiedad de la memoria se transfiere al trabajador. Pero hay una trampa. El hilo principal ya no puede acceder a esa memoria una vez que ha sido transferida.

Así que, necesitas planificar en consecuencia. Luego, tenemos el buffer de arreglo compartido, que en realidad lleva esto un paso más allá. El buffer de arreglo compartido en realidad permite el uso de memoria compartida entre hilos, lo que significa que tanto el hilo principal como el hilo del trabajador pueden leer y escribir en el mismo buffer. Y este es en realidad el enfoque más eficiente para grandes conjuntos de datos que necesitan acceso simultáneo a la memoria. Sin embargo, con gran poder viene una gran responsabilidad. El acceso a la memoria compartida requiere una cuidadosa sincronización para evitar condiciones de carrera y también para asegurar la consistencia de los datos. Así que, usar estas técnicas sabiamente puede reducir drásticamente la sobrecarga de comunicación y tal vez desbloquear un rendimiento mucho mejor en aplicaciones intensivas en datos, especialmente en áreas como procesamiento en tiempo real, gráficos, y tal vez computación científica. Ahora, hablemos sobre grupos de trabajadores.

En algunas aplicaciones, podrías necesitar ejecutar tareas paralelas o tal vez aprovechar los procesadores de múltiples núcleos. Así que, en lugar de crear un nuevo trabajador para cada tarea, en realidad es más eficiente crear un grupo de trabajadores que se puedan reutilizar. El grupo de trabajadores crea un número fijo de trabajadores basado en los núcleos de CPU disponibles, luego mantiene una cola de tareas y asigna tareas a los trabajadores inactivos a medida que se vuelven disponibles. Con este enfoque, puedes distribuir eficientemente el trabajo a través de múltiples hilos sin tener que preocuparte por la sobrecarga de crear y destruir constantemente hilos de trabajadores manualmente.

Ahora, retrocedamos y discutamos cuándo deberías usar realmente estas técnicas de multihilo. Así que, no todas las operaciones se benefician de ser trasladadas a un trabajador y siempre hay un costo de comunicación a considerar. Esta tabla proporciona un marco general para tomar estas decisiones. Las actualizaciones de la interfaz de usuario siempre deben permanecer en el hilo principal, mientras que el procesamiento de datos y los cálculos complejos son candidatos ideales para los trabajadores. Las animaciones y visualizaciones también pueden beneficiarse enormemente del canvas fuera de pantalla. El símbolo de advertencia en esta tabla indica las situaciones donde la decisión depende de lo específico.

Por ejemplo, animaciones simples podrían estar bien en el hilo principal pero las complejas deberían ser trasladadas al canvas fuera de pantalla o a un trabajador. Así que, aquí está mi regla general, si toma más de 100 milisegundos o tal vez bloquea las entradas del usuario, en realidad es un candidato para un trabajador. Ahora, hablemos sobre algunos errores comunes a evitar al implementar multihilo en tus aplicaciones de React. Primero es el exceso de hilos. No traslades operaciones a trabajadores solo porque puedes. Siempre hay una sobrecarga al configurar trabajadores y comunicarse entre hilos.

Así que, solo traslada operaciones que realmente se beneficien de estar fuera del hilo principal. Segundo, ten en cuenta la sobrecarga de comunicación. Pasar grandes cantidades de datos frecuentemente entre hilos puede anular los beneficios de rendimiento de usar trabajadores. Así que, agrupa tu comunicación y minimiza el tamaño de los datos que estás transfiriendo entre el hilo principal y los hilos de trabajadores.

En tercer lugar, recuerda siempre terminar tus trabajadores cuando ya no sean necesarios. Los trabajadores olvidados continúan consumiendo recursos y pueden llevar a fugas de memoria. Finalmente, implementa un manejo de errores adecuado en tus trabajadores. Los errores de los trabajadores pueden ser silenciosos si no se capturan y reportan adecuadamente al hilo principal. Así que, eso es algo a considerar también.

Ahora, pasemos a lo siguiente. Ahora, déjame compartir algunas mejores prácticas para implementar patrones de multi-hilo en aplicaciones web. Primero, siempre perfila tu aplicación antes de optimizar. Usa la pestaña de rendimiento en Chrome DevTools para identificar qué operaciones están causando realmente el bloqueo del hilo principal. Una vez que hayas identificado esas, enfoca tus esfuerzos allí. Segundo, comienza con tareas pequeñas y aisladas al implementar trabajadores. Esto realmente facilita la depuración de problemas y medir el impacto de tus cambios. Tercero, siempre implementa detección de características y alternativas para navegadores que no soportan ciertas características. Esto es para asegurar que tu aplicación siga siendo funcional para todos los tipos de usuarios. Finalmente, monitorea tu rendimiento en producción. Esto es para asegurar que tus optimizaciones realmente beneficien a los usuarios reales. A veces, las optimizaciones que pueden parecer buenas en desarrollo o que pueden funcionar bien en desarrollo, no se traducen bien en mejoras en el mundo real. Así que, monitorear el rendimiento en producción es realmente importante.

Ahora, hablemos sobre lo que viene en el futuro del paralelismo en el front-end. Primero está el shared array buffer más Atomix, que en realidad es para desbloquear la verdadera memoria compartida entre los hilos principales y los hilos de trabajadores. Nos da un control muy detallado sobre la sincronización. Luego, tenemos módulos de trabajadores. Los módulos de trabajadores nos permiten importar y exportar dentro de los propios trabajadores. Esto realmente hace que la lógica del trabajador sea más modular, escalable y estable. Luego, tenemos la API de programador, que todavía es experimental, pero ofrece un gran control sobre colas de prioridad, colas de tareas prioritarias. Realmente nos da un control más detallado sobre la programación. Piensa en ello como el programador interno de React. Luego, tenemos WebGPU. WebGPU le da a nuestras aplicaciones de JavaScript acceso directo a la GPU para aplicaciones intensivas en cómputo como tal vez aprendizaje automático, renderizado y simulaciones. Así que, estaré feliz de responder cualquier pregunta que puedas tener sobre la implementación de multi-hilo en tus aplicaciones de React, ya sea que estés lidiando con problemas de rendimiento en aplicaciones existentes o diseñando nuevas para manejar cargas de trabajo complejas. Estos patrones pueden realmente ayudarte a crear experiencias de usuario más suaves o más receptivas. No dudes en contactarme con preguntas de seguimiento o para compartir tus propias experiencias con estas técnicas. Y con esto, vamos a concluir. ¡Muchas gracias!