Múltiples aplicaciones, un código para gobernarlas a todas

Hola a todos y bienvenidos a mi charla, múltiples aplicaciones, un código para gobernarlos a todos.

Hoy voy a hablar un poco sobre un caso de uso, uno muy interesante del que podemos aprender. Pero antes de comenzar, quiero hablar un poco sobre mí.

Me llamo Jem Agnesi, soy el CTO y cofundador de Wilco. En Wilco, estamos tratando de construir una plataforma de aprendizaje donde cada ingeniero pueda practicar sus habilidades de desarrollo y obtener escenarios de la vida real para practicar. Antes de Wilco, trabajé como ingeniero senior y ingeniero de personal en WeWork y Meta. Pueden encontrarme en Twitter con este nombre de usuario.

Y como dije, hoy quiero hablar un poco sobre un caso de uso interesante que tuvimos en Wilco cuando comenzamos. En Wilco, teníamos un par de pantallas, un par de experiencias.

Entonces, como dije, estamos construyendo una especie de plataforma que permite a los usuarios y desarrolladores realizar una especie de búsqueda, donde cada búsqueda es una práctica para las habilidades de desarrollo.

Una experiencia es la plataforma Wilco, como se llama. Y como pueden ver, tenemos un feed de búsquedas del stack del futuro, la búsqueda futura, la búsqueda anterior que el usuario hizo, la búsqueda actual que está en curso, el perfil del usuario, las habilidades, la cantidad de monedas y los puntos que obtuvieron.

Esto es, como pueden ver, muy elegante, con un aspecto y una sensación de tema oscuro.

Por otro lado, teníamos el juego. Cuando comienzas el juego, ingresas a una especie de portal de una empresa muy antigua y cooperativa. Nuevamente, puedes ver tu búsqueda actual, lo que necesitas hacer. Tienes todo tipo de enlaces. Tienes tus usuarios.

Estas dos experiencias son muy, muy diferentes. Este es uno de los primeros requisitos que recibimos de nuestra gestión de productos. Necesitamos crear dos experiencias para el usuario, que se mueve entre ellas. Sé lo que piensan de inmediato si tenemos un elemento.

Entonces, esta es una micro front-end, y podemos dividirla en micro front-end, y podemos jugar con las últimas novedades que siempre están de moda en JavaScript.

Y entiendan, esto es lo que teníamos en mente cuando pensamos por primera vez en ello desde nuestra gestión de productos. Y antes de implementar esta arquitectura tan complicada, quiero decirle a nuestro equipo que espere un minuto y piense en esta arquitectura, si es realmente lo que queremos hacer. Porque no quiero que esto sea una crítica contra el micro front-end, me encanta el micro front-end, entiendo el valor. Incluso di una charla al respecto, como pueden ver. Y como alguien que ha jugado con el micro front-end y ha visto todo tipo de soluciones que tenemos allí, realmente necesitamos entender que el micro front-end puede introducir mucha complejidad en la implementación y en cómo trabajamos con esas aplicaciones. Hay muchas cosas en las que debes pensar antes de sumergirte en la implementación de este tipo de arquitecturas. Y en esta charla, quiero convencerlos y tal vez detenerlos antes de que sigan adelante.

Otra cosa que obtenemos de forma gratuita cuando trabajamos en una sola aplicación es el manejo de análisis e informes, porque recuerda que en nuestro caso de uso, cuando el recorrido del usuario parece muy sólido, comienza desde la página de inicio de Wilco y se sumerge más en el juego y el portal de finalización del juego y queremos mantener estos análisis en la misma vista para rastrear el flujo del usuario a lo largo del camino, así que necesitamos tener los mismos análisis, lo mismo ocurre con el informe de errores, no queremos dos instancias de informe de errores para seguir y muchas más. También tenemos mucho código que se comparte entre esas dos aplicaciones, ya sea la sesión de usuario que necesitamos gestionar, ya sea el código que obtiene cosas del servidor, tal vez sea el manejo de errores y cosas así, así que una vez que tenemos una sola aplicación de React el intercambio de código es algo muy simple. De nuevo, también hay algunas soluciones para micro-frontend pero es un poco más complicado y muchas cosas que configurar. Cuando tienes una sola aplicación, puedes aprovechar un solo repositorio. No necesitas dividirlo en varios repositorios que debas mantener, vigilar y gestionar. Un solo repositorio, al igual que una sola aplicación, nuevamente, como dije antes, también para un micro-frontend. Puedes trabajar en un solo repositorio pero debes configurarlo. Hay cierta sobrecarga para configurar espacios de trabajo o aprendices y así que hay soluciones pero hay cierta sobrecarga pero lo obtienes de forma gratuita. Y una última cosa, en el aspecto técnico, puedes obtener solo una implementación, una implementación para vigilar y una implementación para monitorizar. Hay pros y contras, por ejemplo, si introduces un cambio en solo una aplicación, también obtendrás una implementación en la otra aplicación, pero por lo que vimos, en la mayoría de los casos se cambian en ambas direcciones, así que está bien para nosotros. Pero más allá del aspecto técnico que debes tener en cuenta, también hay una cosa de la que quiero hablar cuando se divide un repositorio y se dividen las aplicaciones y esta es la ley de Conway. Para aquellos que no están familiarizados con la ley de Conway, dice que tu producto, lo que construyes y las cosas que los usuarios obtienen, realmente es una copia de la estructura de tu equipo o cómo te comunicas. Por ejemplo, si tienes muchos equipos dentro de tu organización, por ejemplo, uno para el front-end y otro para el back-end y otro para la vista de mensajes, otro para el menú, el producto se verá así. Verás pilares aislados donde se ve que hay algunos equipos aislados y en nuestro caso solo teníamos un equipo, un equipo muy pequeño, recuerda que somos una startup que acaba de comenzar somos muy pequeños y no quería crear algún tipo de aislamiento en el producto porque nuestro equipo era muy pequeño y muy cercano entre sí, así que quería que todos los equipos pudieran trabajar en ambas aplicaciones y poder escribir una solicitud de extracción o escribir código que los cambie a todos juntos y eso es una de las cosas que debes tener en cuenta. No es solo técnico, tal vez los problemas técnicos. Estos son más fáciles de evaluar, pero tal vez lo más difícil que necesitarás cambiar es la estructura del equipo. Esto es muy, muy importante para tener en cuenta.

De acuerdo, espero haberlos convencido de que hay valor en mantener este tipo de aplicación como una sola aplicación. Entonces, veamos cómo vamos a hacer esto. Al final del día, lo que vas a construir es una aplicación shell. Esta es la aplicación de alojamiento que podrá decidir cuál es la aplicación correcta que deben agrupar o cuál es la aplicación correcta que deben conectar a la vista del usuario. En esta aplicación shell, recibiremos una solicitud y, en función de todo tipo de requisitos o parámetros, podremos decidir cuál es la mini-aplicación correcta que deben conectar a la aplicación shell. Y esta decisión puede basarse en todo tipo de propiedades. Por ejemplo, en nuestro caso de uso, se basó en la ruta del usuario. Si el usuario va a la aplicación vilko, obtendrá la oscura, y si va a anything.vilko, obtendrá el portal de anything. También puedes hacerlo no solo en función del subdominio. Puedes hacerlo en función de la ruta de la aplicación. Tal vez lo hagas en función del rol del usuario. Tal vez un usuario regular obtenga una experiencia y los administradores o internos o usuarios conectados obtengan la otra. Tal vez

De acuerdo. Entonces manejamos la aplicación Shell y luego necesitamos decidir qué tipo de enrutamiento queremos hacer. Específicamente para nosotros, teníamos dos opciones. Ya sea utilizar el dominio, el subdominio, como digo, app.will.gg o anything.portal.gg. Así que tenemos la opción de decidir en función del dominio o de la ruta. Utilizarán el mismo dominio, pero decidiremos en función de la ruta, tal vez. will.gg/barra-aplicacion will.gg/portal. Esto es algo de lo que hablamos junto con nuestro producto. Una cosa muy importante que debemos tener en cuenta al utilizar el enrutamiento por dominio, es que no puedes aprovechar el estado compartido de manera transparente dentro de React con un solo contexto, porque al moverte entre dominios, hay una especie de actualización. No puedes simplemente usar push state, esto está en la especificación de Mozilla. Así que esto es algo de lo que discutimos mucho con nuestro producto y decidimos seguir utilizando el dominio para distinguir entre las dos aplicaciones y tal vez perder una gestión de estado muy sencilla o el almacenamiento de estado entre estas dos aplicaciones. Todavía hay algunas soluciones, como utilizar iframes en segundo plano, estado compartido y mover el estado al servidor, pero no es tan fácil. No es tan fácil y no lo obtienes de forma predeterminada.

Entonces tenemos la aplicación shell, decidimos sobre el enrutamiento, ahora necesitamos manejar la autenticación. Y lo que necesitábamos en nuestro caso, porque usamos Auth0, pero no importa realmente qué proveedor de autenticación utilices, debes manejar la sincronización entre esas dos aplicaciones. Cuando inicio sesión en Wolco, en la aplicación, también quiero iniciar sesión automáticamente en Portal sin que yo o los usuarios necesitemos registrarnos nuevamente o ingresar su nombre de usuario y contraseña nuevamente, y lo mismo ocurre cuando inicias desde Portal. Y también cuando cierras sesión, debes borrar todas las sesiones de todas las demás aplicaciones. Nos enseñaron que es sencillo, pero no es tan simple, porque el intercambio entre subdominios, como vimos, no funciona tan fácilmente, porque no puedes compartir cookies fácilmente entre ellos.

Lo que hicimos fue crear y configurar un subdominio dedicado para la autenticación que podemos aprovechar para esas dos aplicaciones. Y en una de ellas, creamos un iframe en segundo plano que realiza la autenticación, la autenticación de cierre de sesión para obtener un token. No voy a hablar mucho al respecto. Es muy, muy específico para la solución que, si eliges un subdominio, pero si también tienes esto en mente, te recomendaría leer nuestro blog escrito por Eric de nuestro equipo. Hay mucha explicación allí. Cómo hacerlo, qué código necesitas escribir, cómo se mueve la sesión entre todos los subdominios, y qué necesitas hacer para admitirlo. Una última cosa que debes recordar es la división de código, porque al final del día estamos creando algo como esto. Una aplicación shell que contiene tanto la aplicación Wilco como la aplicación Portal y si, por ejemplo, entro en la aplicación Wilco, obtendré toneladas de basura o recursos que no se utilizan realmente y que manejan la aplicación Portal y es solo una pérdida de tiempo y de red, ¿de acuerdo? Entonces, lo que podemos hacer, afortunadamente tenemos React para resolverlo muy fácilmente para nosotros. Cargamos cada una de las aplicaciones con React Lazy. Eso significa que detrás de escena React creará para nosotros dos paquetes diferentes. Uno para el Portal y otro para el Wilco y los dividirá y solo cargará el que realmente vamos a usar. Entonces, si voy a Wilco, cargará la aplicación Shell y la Shell solo cargará el paquete de la aplicación Wilco y solo cuando vaya al Portal cargará todos los recursos relevantes. Lo mismo ocurre con el paquete compartido porque, como dijimos, hay mucho código que se comparte entre estas dos aplicaciones y no queremos volver a descargarlo. Cuando voy a la aplicación Wilco, se agrupará junto con la aplicación Wilco muchas bibliotecas que también se utilizan en la aplicación Portal. Entonces no quiero volver a descargarlo. Entonces, nuevamente, el mismo truco se aplica allí, vamos a dividir el código compartido en su propio paquete para que cuando vaya a la aplicación Wilco obtenga el paquete compartido y cuando vaya a la aplicación Portal el paquete compartido ya esté en mi caché y ya lo haya descargado. También ayudará al cambiar el código. Si estoy cambiando todo el código compartido, la aplicación Wilco y la aplicación Portal no lo cambiarán, ya estará en caché. Entonces, como resumen de lo que hicimos aquí antes de seguir este camino de microfronted por favor, piensa antes. Romper puede ser tu solución predeterminada, pero puede ser muy, muy difícil después invertirlo. Si decides usar una sola aplicación, piensa cómo dividir y cuál es la lógica de dar a cada uno la aplicación correcta, ya sea en la sesión del usuario, en un rol, una contraseña, un subdominio o una ubicación geográfica. El manejo de sesiones, especialmente si usas diferentes subdominios, puede ser complicado, pero también no olvides manejar el cierre de sesión y borrar la sesión. Y una última cosa, piensa en la experiencia del usuario, cómo agrupar el código, cómo ahorrarles tiempo y red y entregar una aplicación más rápida. Eso es todo, muchas gracias, pueden encontrarme en Twitter con este nombre y me encantaría que prueben Wilco en esta dirección. Gracias, adiós.