Renderizado remoto con Web Workers

Hola a todos. Mi nombre es Trish Thao. Gracias por acompañarme en esta charla sobre la representación remota con web workers. Hoy, les guiaré a través de cómo construimos Argo, un marco extensible que permite la representación de contenido remoto dentro de las aplicaciones de Shopify. Esto es lo que cubriremos hoy. Hablaré sobre los conceptos clave. Cómo construimos Argo, el flujo de extremo a extremo. Cómo podemos reemplazar React. Y luego haré una demostración rápida de todas las piezas trabajando juntas. Estos son los conceptos clave detrás de la representación remota. Primero, necesitamos crear un sandbox de JavaScript. Este sandbox nos permite ejecutar código de manera segura en un hilo de fondo. La comunicación con el hilo principal se puede lograr mediante el envío de mensajes. Esto se implementa como un web worker en la web. En iOS y Android, esto se implementa como un motor de JavaScript sin cabeza. Luego, necesitamos implementar una capa de llamada a procedimientos remotos, RPC por sus siglas en inglés. Este es un protocolo que permite que un programa llame al servicio en otro programa. Por último, hacemos uso de proxies. Un proxy es un envoltorio que intercepta y redefine las operaciones principales del objetivo, como invocar funciones o acceder a propiedades. Hablaré sobre cómo construimos Argo. En primer lugar, lo que intentábamos lograr es habilitar la representación remota. Lo que esto significa es permitir que un script externo defina la interfaz de usuario y luego permitir que la aplicación principal la represente de forma nativa. El marco permite que el script externo intercambie datos con la aplicación principal. Esto resulta en la representación de la interfaz de usuario y la ejecución de comportamientos personalizados. Entonces, los objetivos que intentábamos lograr son proporcionar una buena experiencia de usuario. El contenido de la interfaz de usuario inyectado es indistinguible del contenido nativo propio de Shopify en todas las plataformas. Queríamos proporcionar una buena experiencia de desarrollo. Los scripts externos se pueden construir utilizando lenguajes familiares como JavaScript y TypeScript, y marcos como React o Vue, y también queríamos proporcionar una capa de seguridad. El script externo solo puede acceder y ejecutar las API proporcionadas por Shopify. En resumen, esto es lo que intentábamos hacer. Tenemos un JavaScript

A continuación, configuramos una instancia del receptor remoto. Este receptor gestiona un árbol de componentes internos en respuesta a los mensajes. También configuramos un controlador que especifica la implementación a utilizar al representar la interfaz de usuario. En este ejemplo, permitimos que los botones se representen utilizando el componente de botón de la biblioteca de interfaz de usuario Polaris. El host puede decidir qué componentes se utilizarán. Esto permite cambiar los componentes según sea necesario. El último paso es representar el componente renderizador remoto de la biblioteca de interfaz de usuario remota y pasarle el receptor y el controlador. El renderizador remoto es responsable de convertir el árbol de componentes que recibe en una interfaz de usuario utilizando la implementación especificada por nuestro controlador.

Ahora veamos qué hay dentro del script del worker. Dentro del worker, definimos una función de representación que el host podrá llamar con una URL de script, un punto de extensión y un controlador de mensajes. El primer paso es llamar a import scripts con la URL del script externo para cargarlo. Luego creamos una ruta remota y pasamos nuestro controlador de mensajes. Esto establece la conexión entre el receptor del host y la raíz remota del worker. También creamos un mapa de devoluciones de llamada de extensión registradas. Dependemos del script externo para poblar el mapa. Cuando se llama a la función de representación, obtenemos la devolución de llamada registrada para el punto de extensión y la llamamos con la raíz remota. Aquí también podemos pasar datos adicionales o APIs para que el script externo pueda acceder a ellos. Pero este ejemplo solo muestra que pasamos la raíz remota. A continuación, configuramos la capa RPC del worker creando un punto de conexión al worker. Esto es el contraparte del punto de conexión creado en el host. Luego llamamos a exponer la función de representación. Internamente, la capa RPC gestiona automáticamente el almacenamiento de la función en memoria y luego responde a un mensaje del host para activar la función de representación cuando sea necesario. Esto permite de manera transparente que el worker y el host intercambien datos y realicen llamadas de proxy entre sí. Otra cosa que se encuentra dentro del archivo del worker es configurar variables globales disponibles para el script externo. Aquí es donde exponemos la función extend bajo el espacio de nombres Shopify. El script externo podrá llamar a esta función para registrar una devolución de llamada que se guardará en el mapa que vimos anteriormente. Y también podemos restringir las variables globales disponibles para el script externo. Estamos eliminando la capacidad de llamar a import scripts para que no se puedan cargar scripts adicionales. Finalmente, una vez que la función de representación está configurada dentro del worker, el host solo necesita llamar a render con el script externo y el punto de extensión. El punto de extensión se configura a través de un playground de cadena. Esto es solo una representación de un punto disponible en el host en el que los scripts externos pueden ejecutar un comportamiento personalizado. También estamos pasando el método receiver.receive que servirá como controlador para los mensajes que llegan desde la ruta remota. Vamos a ver el script externo dentro del worker. Una vez cargado, se puede ejecutar un comportamiento personalizado. Aquí hay un ejemplo de un script externo JSX que representa una interfaz de usuario personalizada. Primero, el script importa un componente de botón de nuestra biblioteca React. Luego, el script crea un componente de aplicación que representa el botón con un título y una devolución de llamada asignada a través de la propiedad onpress. La escritura del script es exactamente

Si profundizamos en el método extend proporcionado por la biblioteca, simplemente llama a Shopify extend, el método que hemos definido anteriormente en el script del worker. La biblioteca se encarga de los detalles de implementación al proporcionar la función extend. De manera similar, la biblioteca Argo también proporciona el método render que se encarga de los detalles de implementación. A alto nivel, esta función recibe una devolución de llamada de renderizado y devuelve una función que puede ser activada con una raíz remota. Luego configura un reconciliador personalizado de React. Para simplificar las cosas, he omitido nuestros convicts personalizados que se pasan al reconciliador, pero puedes pensar en este reconciliador como un reconciliador similar a React DOM o React Native. Sin embargo, está conectado a nuestra raíz remota, lo que permite que la raíz remota administre el árbol de componentes interno y se comunique con el host para realizar el renderizado de la interfaz de usuario.

Una vez que se configura el reconciliador, llamamos a la devolución de llamada de renderizado del script externo. Y luego agregamos los resultados al contenedor de la raíz remota. Y finalmente, llamamos a mount en la raíz remota. En el lado del host, recibimos un mensaje de montaje y los hijos desde la raíz remota como carga útil. Al profundizar en la carga útil de renderizado, obtenemos una matriz de objetos que representan cada nodo en el árbol. Recuerda que configuramos las props de la siguiente manera en el script externo. Tenemos un botón con un título y onPressedCallback. Esto se convierte en un nodo que tiene un ID único, el tipo que representa su implementación y las props especificadas. Puedes ver que onPress ahora se convierte en una función proxy. Cuando se llama al proxy, la capa RPC se encarga de llamar al controlador correcto con el ID de proxy coincidente desde dentro del worker, y luego se activa la devolución de llamada SayHi. También recibimos los hijos como una matriz de objetos. En este caso, no tenemos hijos, por lo que la matriz está vacía.

Finalmente, el renderizador en el lado del host convierte la carga en una interfaz de usuario. Internamente, el renderizador se encarga de convertir cada nodo en el árbol de componentes llamando recursivamente a React CreateElement con la implementación y las props para cada hijo. Ahora que hemos cubierto cómo se renderiza la interfaz de usuario, te explicaré cómo se actualiza la interfaz de usuario según las entradas del usuario. Aquí tenemos un ejemplo de un script externo que renderiza un campo de texto con la prop value gestionada internamente mediante state. Cuando un usuario escribe en el campo de texto, se llama al proxy onChange, lo que activa el método setTextValue para actualizar el state dentro del worker. La prop value del campo de texto se actualiza con un nuevo valor de texto. Internamente, React Reconciler llama a la ruta remota para manejar la actualización de su árbol de componentes. Esto a su vez envía un mensaje actualizado a través del receptor en el host, lo que desencadena una actualización en su ruta interna. Finalmente, se llama al renderizador con la ruta actualizada que contiene la prop actualizada para el campo de texto, lo que resulta en la renderización de una interfaz de usuario.

Ahora que hemos cubierto cómo se construye Argo en la web utilizando React, hablaré sobre cómo se puede intercambiar React. Al mirar nuevamente el flujo de extremo a extremo para renderizar la interfaz de usuario, se pueden reemplazar algunas piezas. Se pueden utilizar diferentes bibliotecas de cliente para construir la interfaz de usuario en el script. Por ejemplo, la biblioteca Argo React se puede reemplazar con vanilla JS o Vue.js. De manera similar, se puede intercambiar el renderizador en el lado del host por otra implementación. React DOM se puede reemplazar con Swift o Kotlin o React Native. Es posible intercambiar las piezas siempre que se mantenga el contrato entre el sandbox de JavaScript y el host. Se envía la misma carga de renderizado con el árbol de componentes serializado sin importar qué biblioteca esté utilizando el script externo para construir la interfaz de usuario. De manera similar, no importa cómo se renderice la interfaz de usuario en el host, cuando una interacción del usuario en la interfaz de usuario provoque la llamada a un controlador en el script externo, el host activa el controlador a través de un proxy.

Ahora, mostraré una demostración rápida pregrabada de cómo todas las piezas funcionan juntas. Aquí tengo un script externo que renderiza un formulario y un banner en Shopify en la web y en iOS. Para este ejemplo, he habilitado la recarga en vivo, lo que nos permitirá ver la interfaz de usuario actualizada a medida que cambiamos nuestro código. Ahora, demostraré cómo podemos utilizar APIs adicionales proporcionadas por Shopify. La biblioteca proporciona ganchos útiles para hacer eso. Llamaremos al gancho de API use extension. Y desde la API, extraeremos el objeto Toast que contiene un método para mostrar un mensaje Toast. Ahora, todo lo que queremos hacer es mostrar el contenido de nuestro formulario en un mensaje Toast como una cadena JSON. Una vez que se actualice, podemos probar nuestro nuevo callback. Así que estoy completando el formulario. Y ahora, si presiono enviar, obtengo un mensaje Toast con los datos de mi formulario. También puedo hacer lo mismo en iOS.

Observa que iOS ha renderizado el Selector como un componente Selector nativo. Y cuando enviamos, obtenemos un mensaje Toast, al igual que en la web. El mismo script externo se utiliza para renderizar contenido tanto en iOS como en la web. Y el contenido es exactamente como aparece el contenido nativo de Shopify. Así concluye la presentación. Nuestro objetivo fue construido teniendo en cuenta la flexibilidad y la seguridad. Espero que esta charla te haya permitido aprender más sobre cómo funciona. Gracias por ver.

Es bueno verte de nuevo. Entonces, gente, Trisha ha preguntado qué pasatiempos han adoptado durante la pandemia y parece que el 50% de ustedes ha comenzado a jugar video juegos o tal vez han jugado más video juegos. El 44% hace ejercicio, es bueno ver que las personas se mantienen saludables y hacen ejercicio. Sé que muchos desarrolladores tienden a no hacer ejercicio, así que es bueno ver que muchas personas lo están haciendo. Leer, por supuesto, genial. Es genial ver juegos de mesa, oh, me encanta eso. Y algunos planos de casas. Realmente es bueno ver a las personas invirtiendo en el aire fresco de su hogar. ¿Y tú, Trish? ¿Qué has estado haciendo? Como puedes ver en mi fondo, principalmente planos de casas. He recogido como unos 50 planos de casas desde que comenzó COVID. También video juegos, desearía haber hecho más ejercicio. Eso está en mi lista de tareas pendientes. Bueno, si tienes 50 planes, eso es uno por semana. Y eso implica mucho caminar y andar en bicicleta para obtener los planos, ¿verdad? Así que eso es un tipo de ejercicio. Oh sí, y caminar por la casa, regarlos, bajarlos, ya sabes, limpiarlos y regarlos. Sí, es mucho trabajo. Llevar toda esa agua. Exactamente. No, buen trabajo. Yo mismo he estado aprendiendo carpintería. No diría que soy bueno, pero hey, es algo diferente al desarrollo.

Así que vamos a pasar a las preguntas del público y sí, espero que puedas brindar información sobre las cosas que quieren saber.

Para mí, los web workers siempre han parecido magia negra. Así que es genial ver que has logrado hacerlos tuyos.

La primera pregunta es de Sasha. ¿En qué contexto usarías esta estrategia? Es un concepto completamente nuevo para mí, así que sería bueno entender por qué querríamos usarlo.

Bueno, el concepto aquí es permitir que cualquier código externo se renderice dentro de una aplicación principal. En Shopify, tenemos diferentes aplicaciones que pueden ser ampliadas por desarrolladores de terceros. Entonces, los desarrolladores pueden construir sobre nuestra plataforma. Eso significa que queremos poder ejecutar su código de forma segura y luego hacer que ejecuten comportamientos personalizados, renderizar una interfaz de usuario personalizada en nuestras propias aplicaciones. Y un desafío adicional es que nuestras aplicaciones están escritas en muchos lenguajes diferentes. Podría estar construida en React Native, podría estar escrita en Kotlin o simplemente ser una aplicación web. Queremos que el mismo código externo esté escrito en un lenguaje familiar. Así que digamos que un desarrollador externo puede escribir en React y ese mismo código React puede renderizarse nativamente en todas nuestras plataformas. Entonces, la estrategia, supongo, sería la flexibilidad para ambos lados. El host puede elegir la tecnología que utiliza para renderizar y el script externo también puede elegir la tecnología en la que quiere escribir el código. Espero que eso lo aclare. Si Sasha no lo cree así, entonces puede unirse a ti en tu chat facial y tener una conversación. Sí.

La siguiente pregunta es de Thorne. Como continuación a la pregunta de Sasha, en realidad, esto parece excesivo para este ejemplo. ¿En qué situación es útil esto? Creo que ya has tocado ese tema. ¿O quieres ampliar tu respuesta? Sí. Supongo que el ejemplo que di puede ser simplista. Pero creo que ya lo he cubierto. Queremos flexibilidad. Queremos que el host use la tecnología que necesite para renderizar la interfaz de usuario y hemos construido un contrato. Lo mencioné en mi charla. Podemos intercambiar las piezas y la tecnología que se utiliza puede intercambiarse siempre que se siga el contrato. Genial.

La siguiente pregunta es de nuestro usuario, visitante, Solal.

¿Por qué Argo en lugar de módulos federados modules si podemos usar un módulo federado? Correcto. Entonces, para nuestro caso particular, el código es externo, proporcionado por diferentes desarrolladores. Y debe ejecutarse de forma segura. Por lo tanto, no podemos simplemente importar modules. Es un requisito adicional que hemos construido una plataforma para permitir a los desarrolladores enviar su código a nosotros, pero también pueden versionarlo y volver a versiones anteriores. Por lo tanto, ellos mismos gestionan esa parte. Y en Shopify, simplemente renderizamos su código. Es como una separación adicional básicamente. Por lo tanto, no estamos importando código que hayamos escrito nosotros mismos. Todo esto es externo.

Muy bien. La siguiente pregunta es de P. Tarek. ¿Cuál es el punto de usar un renderizador remoto? ¿Y cuál es la motivación detrás de ello? ¿Se trata de obtener performance en el hilo principal? Entonces, la motivación es principalmente seguridad y flexibilidad. Bien, bastante justo. Así que hay un sandbox en el que se ejecuta el script externo que está separado del hilo principal. Y luego, básicamente, podemos exponer diferentes APIs según lo consideremos adecuado para ese sandbox externo. Así que hay una separación que hemos creado por seguridad. Y a veces supongo que el rendimiento es una bonificación gratuita que se obtiene mientras se implementa por seguridad. Sí. Esa es la motivación detrás de ello. Principalmente es seguridad. Sí. Puedo imaginar que esa es la fuerza impulsora en tu empresa para la mayoría de las decisiones tecnológicas, seguridad. Sí. Como mencioné, todo es código externo. Queremos permitir flexibilidad, pero también mantener el control sobre lo que ese código podría hacer. Así es como hemos logrado que funcione. Genial. Impresionante.

La siguiente pregunta es de Nippuna777. ¿Cuáles son las ventajas de usar el worker aquí en lugar de hacerlo en la propia aplicación? Sí. Creo que mencioné esto. Queremos una separación entre la aplicación principal y el sandbox básicamente en el que se puede ejecutar el script externo. Genial. Entonces, nuevamente, seguridad. Nuevamente, seguridad. Siguiente pregunta. Esta parece la misma pregunta. Esta es de Sosia.

¿Alguna vez se usaría en React Native o solo en la web? Sí. Esa es una buena pregunta. La belleza de construir este marco es que React Native es solo una tecnología que podemos elegir para implementar el host. Entonces, dependiendo de cómo se haya creado la aplicación principal de Shopify, podemos comenzar a desarrollar en React Native. Entonces, algunas de nuestras aplicaciones están escritas en React Native, la aplicación de la tienda lo está, por lo que ese es un lugar donde, si queremos ofrecer extensiones, podemos escribir la implementación utilizando React Native.

Genial. Esto es realmente poderoso. La siguiente pregunta es de John B. Él pregunta, sé que Angular o Blazor permiten la renderización en el lado del servidor, ¿es esta una implementación de renderización en React? En realidad, todo sucede en el navegador, en el cliente. Lo siento, no en el navegador. No diría eso, está sucediendo en el cliente. Entonces, en realidad no es una renderización en el lado del servidor. Entonces, la interfaz de usuario, básicamente, una carga proviene del sandbox y luego el host toma esa carga y renderiza la interfaz de usuario real. Por lo tanto, todo sucede en el lado del cliente.

De acuerdo, luego Paolo Henrique pregunta, pero ¿qué sucede si el host está inactivo? Sí, en este caso, si el host, que es la aplicación principal, está inactivo, entonces toda la aplicación estaría inactiva y nada se renderizaría. Entonces, sí, esto es como scripts externos que se conectan a una aplicación existente. Entonces, si la aplicación existente no se ejecuta, entonces básicamente todos los componentes o piezas externas tampoco se ejecutarían. En cualquier lado.

De acuerdo, tenemos tiempo para algunas preguntas más. Así que pasemos a la siguiente de Werner Bafa. ¿Cuál fue el esfuerzo para configurar toda esta arquitectura? Esa va a ser una respuesta loca, supongo. Sí, en realidad me gustaría dar un reconocimiento a Kris Helvé. Él es el autor de Remote UI. Esta es una biblioteca de código abierto. Puedes visitar el repositorio en GitHub. Kris Helvé estableció como una especie de base y nuestro equipo construyó las piezas a su alrededor. Así que fue un esfuerzo realmente grande porque tuvimos que pensar en muchas cosas como asegurarnos de lo que exponemos a los desarrolladores de terceros se pueda extender y personalizar según la aplicación en la que se están extendiendo. Como mencioné antes, Shopify tiene una gran cantidad de aplicaciones diferentes para diferentes propósitos. Así que necesitábamos que esto fuera flexible. Pero sí, el esfuerzo es difícil de cuantificar, pero Kris Helvé sentó las bases y luego muchas personas utilizaron esa base para construir todas estas piezas.

¿Y este fue un proyecto de código abierto o Kris es un empleado de Shopify que luego, después de construirlo para Shopify, lo hizo de código abierto? Creo, no sé, Kris sería la mejor persona para responder esto, pero siempre se construyó teniendo en cuenta el código abierto. Cualquiera puede ir al sitio y obtener la biblioteca y construir cosas a su alrededor. Pero quiero decir, él es un empleado de Shopify. Sí, lo siento, Kris Helvé trabaja en Shopify. Sí, muchas de nuestras bibliotecas, intentamos contribuir de vuelta a la comunidad de código abierto. Y esta es una de ellas.

De acuerdo, genial, genial. Gracias y Shopify. La siguiente pregunta es de Zex, ¿este enfoque ya está en producción y en las aplicaciones de producción de Shopify y durante cuánto tiempo? Sí, está en producción. Ofrecemos un cierto grado de estabilidad en algunos de nuestros productos y luego ofreceremos más y más en el futuro. Está en vivo. Lo lanzamos, creo que fue en octubre pasado y habrá muchos más, los llamamos extensiones de Argo, en diferentes lugares de Shopify. Así que habrá más cosas que ver el próximo año. Tal vez vuelvas a dar una charla el próximo año sobre cómo funciona esto. O alguien más tenga la oportunidad. Tenemos un gran equipo construyendo esto. No solo soy yo. Sí, de acuerdo. Para nosotros, ahora eres la cara pero, por supuesto, hay un equipo detrás.

Siguiente pregunta. Y la última pregunta, desafortunadamente solo tenemos tiempo para una. Es una pregunta difícil. Es de Nikhil Bittekar. ¿Alguna lección aprendida al usar esto con el navegador IE? Oh, veo que para el navegador IE, solo admitimos Edge, por lo que no hay ninguna lección aprendida. Supongo que el lado de la renderización, es igual que construir un sitio web. Debes asegurarte de que funcione. Afortunadamente para nosotros, la extensibilidad que elegimos ofrecer está en una de nuestras aplicaciones llamada Shopify admin, que está construida utilizando Polaris. Es un marco de interfaz de usuario con componentes de interfaz de usuario que han sido probados en diferentes navegadores. Así que obtuvimos eso de forma gratuita. Pero la construcción de todo el lado depende de dónde se muestre.

Debes asegurarte de que funcione. Así que todo el lado de la web, parte de él tiene que funcionar en diferentes navegadores, básicamente. Y Android e iOS tienen desafíos diferentes porque tienen que funcionar en el teléfono. Así que sí, depende. Tenemos que hacer que todo funcione.

Pero afortunadamente pudimos usar Polaris. Ahorra mucho trabajo, por supuesto.

Bueno, desafortunadamente, eso es todo el tiempo que puedo darte aquí en esta encantadora etapa. Pero gente, si tienen más preguntas para Trish o quieren profundizar en Web Workers, ella estará en su chat espacial. Así que Trish, muchas gracias por unirte a nosotros y espero verte de nuevo pronto. Y diviértete en tu sala de oradores en el chat espacial. Gracias por recibirme.