Revolucionando nuestra tubería de construcción de micro frontend

La aplicación web Roblox se ha creado como un monolito. Como en el diagrama a continuación, requiere que todos los ingenieros que se desarrollan en un proyecto se publiquen juntos. El proyecto se construye utilizando un marco .Net MVC, incluido el formulario web Asp .Net, por lo que aplicar cualquier cambio requiere MSBuild, incluso para cambios JS / CSS / Image.

Build and Deployment

En el lado del consumidor, la carga de activos web tiene dos escenarios: la primera vez que el navegador solicita el recurso y la extracción de CDN después de la primera solicitud. Nuestro diagrama de flujo a continuación muestra cómo la carga de activos a CDN se incluye en el esfuerzo de carga por primera vez.

Luego, después del primer escenario de carga, el navegador comenzará a extraer un recurso de la CDN como tal:

Con más de 10 años de desarrollo continuo y una base de código obsoleta, nuestras canalizaciones de desarrollo y lanzamiento carecen de la eficiencia que esperamos de la CDN. Esto ha sucedido por algunas razones:

• Incluso si solo hay cambios en los activos web (como Javascript, CSS, HTML, imágenes, etc.), todo el sitio web debe construirse e implementarse.
• Si surge algún problema debido a los cambios, todos los cambios comprometidos de diferentes equipos tienen que esperar a que se resuelva el problema antes de que se puedan liberar.

Además, los activos web se agrupan y cargan en la CDN mediante un método de clase, lo que hace que la tecnología Frontend moderna, como ES6 + (ECMAScript 6+) o TypeScript, sea difícil de adaptar para el desarrollo a largo plazo. Por lo tanto, la tubería actual de construcción e implementación crea obstáculos para todos.

Desde 2017, Roblox ha probado una variedad de enfoques para aislar los procesos de compilación y despliegue de activos web.

1. El primer enfoque exitoso ha sido aprender de la creación de sitios API más pequeños y aplicarlo para crear sitios de aplicaciones. Los sitios de aplicaciones contienen activos web por componente y se implementan como su propio proyecto. Un sitio de aplicaciones no es un sitio web individual: más bien, proporciona puntos finales para agrupar activos y devuelve la URL de CDN redirigida.
2. La segunda fase es introducir un sistema de paquete Webpack como reemplazo de nuestro método de clase de ensamblados, junto con un nuevo servicio de contenido estático. Esto nos permite cargar paquetes en la red CDN, lo que elimina la implementación del servidor web y solo actualiza la URL de la red CDN para cada componente.

Fase I: aplicación web (sitio)

Como ya hemos desarrollado un marco JS moderno para algunos de los componentes de la función, es natural comenzar aislando el proyecto de representación del lado del cliente del proyecto del sitio web principal de Roblox. Tratamos el proyecto principal como un esqueleto, por lo que el proyecto principal solo necesita saber qué sitio de aplicación web solicitar. Luego, cada proyecto alberga un grupo de componentes de características similares y sus propios activos.

Cada componente dentro del proyecto tendrá su propio controlador para proporcionar un punto final para agrupar Javascript, CSS, HTML, y la respuesta del punto final redirige a la URL de CDN. Por ejemplo, https://chatsite.roblox.com/chat/{version}/get-javascript-bundle como un punto final vuelve https://js.rbxcdn.com/{hashNumber}.js. La respuesta de redireccionamiento será el estado 301 Http, y la respuesta se almacenará en caché en el navegador después de la primera solicitud.

Para notificar un cambio al navegador, agregamos un número de versión en la URL del sitio de la aplicación con el fin de eliminar la memoria caché. El número de versión es un GUID y se agrega / actualiza desde el sitio de administración. Para cada cambio realizado desde el sitio de la aplicación, los desarrolladores deben implementar el sitio de la aplicación y luego ir al sitio de administración para actualizar el GUID para vaciar el caché.

Por lo tanto, heredamos el mismo sistema MSBuild para la agrupación, pero cada proyecto hará su propio MSBuild, por lo que el propietario de cada proyecto tiene flexibilidad para publicar sus cambios (como se muestra a continuación).

Build and Deployment

El beneficio de este enfoque es que cuando los ingenieros implementan un nuevo código, solo necesitan hacer dos pasos. Primero, lanzan un sitio de aplicación que tiene los cambios necesarios. Luego actualizan el valor hash para cada URL del sitio de la aplicación para notificar a los navegadores que hay actualizaciones y extraer recursos actualizados. Por primera vez, como se muestra a continuación, el navegador solicitará recursos mediante una URL actualizada y descargará recursos de la URL relativa antes de que la URL de CDN esté lista.

Después de la primera carga, una vez que la URL de CDN esté lista, el navegador comenzará a extraer recursos de CDN directamente. Al igual que:

Ahora con este enfoque, podemos proporcionar un recurso de traducción para cada componente sin tener que realizar un lanzamiento del sitio web. El recurso de traducción no necesita agruparse y tiene su propio punto final para obtener el recurso de traducción de LocaleResourceFactory como parte del archivo JS.

El proyecto hereda el mismo método de clase para agrupar activos y cargarlos en la CDN. Este mecanismo requiere que las cargas de imagen de la regla CSS permanezcan en la ruta relativa. Como el paquete CSS sigue siendo una granja de servidores estática, la imagen permanece físicamente en el mismo servidor. Entonces, para la Fase I, las imágenes continúan subiéndose desde el sitio web principal como antes.

Pros

• Los desarrolladores pueden desarrollar y lanzar sus propios activos web para cualquier cambio de FE, como Javascript, HTML o CSS.
• Los desarrolladores pueden actualizar la cadena de traducción solo lanzando el sitio de la aplicación de consumo en lugar de un lanzamiento web.
• Como efecto secundario, solo la página de representación del lado del cliente se puede implementar desde la canalización de compilación del sitio de la aplicación, lo que alienta a los equipos a moverse más rápido en el refactor de representación del lado del cliente.

Contras

• Debido a la reutilización del sistema de paquetes heredados, las imágenes y el JS moderno aún no se pueden desarrollar e implementar fácilmente desde el sitio de la aplicación.
• Debido a que los paquetes se generan cuando el navegador envía una solicitud al sitio de la aplicación, existe la posibilidad de que si la nueva URL de CDN no se genera correctamente o está en estado roto, el navegador podría almacenarse en caché antes de la próxima actualización.

Fase II – Aplicación web (Carpeta)

Después de la Fase I, surgió una pregunta obvia: ¿por qué todavía tenemos que redirigir la URL de CDN desde el sitio de la aplicación? ¿Por qué no podemos incrustar la URL de CDN en el código del sitio web principal?

Entonces, comenzamos la fase II tratando de introducir un servicio de contenido estático para cargar activos web en S3 durante el tiempo de compilación, y luego devolver la URL de CDN a DB mientras heredamos la estructura del componente Fase I (y manteniendo el sitio web de Roblox como un esqueleto). Cada paquete de recursos del componente se asignará a un nombre de cadena Enum de componente estático. El nombre del componente se incrustará en la página esqueleto del sitio web.

El sitio web solicitará el servicio de contenido estático para el último contenido habilitado por nombre de componente y obtendrá una URL de CDN que CDN extraerá de S3 si no lo tiene en caché. Luego, con este beneficio del servicio de contenido estático, terminamos de agrupar los activos durante el tiempo de compilación. La URL de CDN estará lista antes de habilitar la nueva versión y validación. Dado que incrustamos la URL de CDN en el proyecto del sitio web de Roblox directamente, no hay necesidad de implementar el servidor web para acceder a un sitio de aplicación adicional para obtener la URL de CDN. Esto salva a los desarrolladores de la implementación del servidor web.

Cuando los ingenieros implementan cambios por primera vez, solo se requiere un paso para actualizar cada URL de CDN de paquete de componentes estáticos desde el sitio de administración. La URL se extraerá de CDN directamente ya que aún no está en caché.

Después de la primera vez, la URL de CDN estará disponible cuando los navegadores soliciten servicios de contenido estático.

La segunda parte de la fase II está reemplazando el sistema de agrupamiento actual con una herramienta Webpack. Webpack se ha utilizado para aplicar un compilador SCSS, fusionar / minificar activos, cargar imágenes, compilar ES6, mapa fuente, etc. Esta herramienta webpack desacopla el proyecto de interfaz web de MSBuild, por lo que cada aplicación web es una carpeta para mantener el recurso. Y gracias al cargador de URL, podemos cargar una imagen en el CDN e incrustar el URL del CDN en el archivo de paquete CSS. Como puede ver a continuación, la carga de archivos y la generación de URL de CDN se produce durante el tiempo de construcción del proyecto, y la URL de CDN se ha incrustado en el sitio web de Roblox, por lo que no necesitamos ninguna implementación de MS para lanzar nuevas URL de CDN.

Entonces, la canalización actual de compilación e implementación de WebApp funciona así:

Pros

• Los desarrolladores no necesitan implementar un servidor web para lanzar un cambio. Solo necesitan ir al sitio de administración y actualizar la última URL de CDN con el nombre del componente relacionado. Esta es una gran mejora para nuestro canal de lanzamiento.
• Las imágenes se cargan y se implementan con cada componente y se envían desde la CDN.
• La introducción de la herramienta Webpack actualiza todo el entorno de desarrollo de la interfaz web, liberando a los ingenieros para que vayan a ES6 +, TypeScript, etc.

Contras

• Como compensación, perdimos el soporte de recursos de traducción de esta fase, por lo que cualquier recurso nuevo que presentemos debe pasar por el lanzamiento web.
• Al igual que en la Fase I, cualquier duplicación de código o dependencias entre paquetes es difícil de identificar.

Que sigue

Si bien hemos avanzado mucho, nos gustaría continuar estudiando Webpack y otras herramientas posibles para abordar el problema de las dependencias entre paquetes. Además, nuestra búsqueda de recursos de traducción debe ser capaz de buscar dinámicamente para permitir la implementación aislada para cualquier nueva introducción de espacio de nombres de recursos. Hemos recorrido un largo camino, pero siempre estamos buscando nuevas oportunidades para hacer que nuestra tubería de construcción sea más rápida y fácil de desarrollar.

Ni Roblox Corporation ni este blog respaldan ni respaldan a ninguna empresa o servicio. Además, no se hacen garantías ni promesas con respecto a la precisión, confiabilidad o integridad de la información contenida en este blog.

Esta publicación de blog se publicó originalmente en el Blog de tecnología de Roblox.