El Auge del Borde Dinámico

De acuerdo. Hola. Mi nombre es Glen. Mi charla de hoy es sobre el auge del borde dinámico, o otra forma de hablar de ello sería el pasado, presente y futuro del alojamiento frontend. Si no me conocen, mi nombre es Glen Madden, ese soy yo en Twitter, esa es probablemente la forma más fácil de ponerse en contacto. He realizado algunos proyectos de código abierto en el espacio de React. Algunos sobre estilos, CSS modules y styled components. Más recientemente, hace un par de años cambié de rumbo y comencé a pensar en el rendimiento en producción y la implementación y comencé un proyecto llamado paquetes de aplicaciones frontend, o FABs, que se encuentra en FAB.dev, así como un producto relacionado con implementaciones llamado link.sh. Emocionantemente, el año pasado Link fue adquirido por Cloudflare workers. Solo llevo un par de meses allí, pero ahora puedo abordar el mismo problema, pero desde el punto de vista de una plataforma completa, una plataforma global completa, lo cual es bastante emocionante.

Entonces, ¿por qué la gente usa CDNs? Bueno, están en todas partes, ¿verdad? Esta es la red de CloudFlare. Son más de 200 ubicaciones. Pero puede ser un poco sorprendente ver cuán importante es esa distribución geográfica. ¿Por qué necesitan estar en tantas ubicaciones? Así que quería comenzar la charla de hoy analizando algo que había visto hace un par de años, que es el impacto de la latencia. Esto fue un experimento que realicé para una serie web llamada Frontend Center, donde realicé una prueba de ancho de banda o una prueba de velocidad de descarga desde Melbourne, donde vivía en ese momento, contra tres ubicaciones diferentes. Sidney, San José y Londres. Sidney está a solo 15 milisegundos de distancia. San José está al otro lado del Pacífico. Y Londres está a 280 milisegundos por la velocidad de la luz, o como ahora vivo allí, es mucho más largo en avión, déjame decirte.

Entonces, cuando tienes un archivo pequeño, obtienes velocidades de descarga, o tiempos de descarga totales, prácticamente lo que esperarías. Es solo una sola ida y vuelta al servidor. Entonces, cuanto más lejos esté el servidor, más tiempo llevará descargar el archivo. Pero lo que podría ser sorprendente es cuando tienes una conexión rápida a una caja local, y esto es entre dos centros de datos , por lo que no hay restricciones de ancho de banda aquí en absoluto, realmente. Para un archivo de 250 kilobytes, todavía estamos en fracciones de segundo. Pero cuando agregas algo de latencia a esta imagen, las cosas comienzan a ser bastante diferentes. Con 200 kilobytes, ahora estás mirando 2 segundos en el mejor escenario para descargar ese archivo. Y si duplicas la latencia, el mismo efecto se duplica. Ahora esto puede ser sorprendente, porque esos servidores están solo, ya sabes, a 100 o 200 milisegundos más lejos, y sin embargo, los tiempos de descarga tardan 10 veces más, o 30 veces más en algunos casos. Y estos pasos son en realidad la latencia entre esos saltos. Entonces cada salto en el gráfico son 160 milisegundos. Cada salto en la línea roja son 280. Esto es debido a la forma en que TCP, el protocolo, funciona debajo de todo lo demás, donde comienza lento y se acelera a medida que detecta que las condiciones de la red son lo suficientemente buenas. Esto significa que los primeros 100 kilobytes cuestan mucho, ya sabes, que cada 100 kilobytes a partir de entonces, pueden costar cada vez más tu rendimiento. Y mucho más de lo que puedas pensar. Así que

Pero por ahora, voy a cambiar un poco de tema y hablar sobre cómo es relevante para nosotros hoy en día. Si eres un desarrollador de aplicaciones JavaScript, como yo, entonces cuando Webpack apareció en escena, probablemente notaste que generaba automáticamente estos esquemas de URL para ti. Ahora, Webpack no fue el primero en hacerlo. Yo lo hacía en Gulp antes. Pero Webpack definitivamente lo ha puesto desde el primer día. Esto es realmente importante, porque tiene un hash del contenido dentro de la URL, lo que significa que el contenido no puede cambiar a menos que lo haga la URL. Eso es perfecto para una CDN. Entonces, al establecer este control de caché inmutable, significa que todos saben que una vez que han visto ese archivo una vez, nunca tienen que volver a comprobar en el servidor de origen. Y si estás construyendo aplicaciones del lado del cliente, eso es suficiente, ¿verdad? Porque puedes servir una página vacía y luego mucho JavaScript, y luego la aplicación se ejecutará en el navegador. Y si haces división de paquetes, cada vez que algo cambie, solo actualizas las partes que cambian. Ahora, no todas las aplicaciones necesitan hacer algo mejor que eso. Si estás construyendo una aplicación en la que las personas pasan horas usándola, realmente no importa cuántos segundos tarda en iniciarse. Y si estás construyendo una aplicación bancaria, entonces realmente no importa lo mala que sea porque aún tienes el dinero de las personas y harán lo que sea necesario para obtenerlo. Pero para el resto de nosotros, y en cualquier momento en que tengas que empezar a adentrarte en cosas más sensibles al rendimiento, esto no está bien. Tienes que empezar a adoptar una red global . Y diría incluso que a menos que hagas de las CDNs parte de tu proceso de implementación , no puedes construir un sitio web rápido. Así que quería hablar sobre un par de cosas porque esta es una charla sobre el rendimiento, pero es muy tentador decir, hey, tienes que desechar todo lo que has hecho antes para obtener un mejor rendimiento. Cuando la verdad es que las CDNs son realmente geniales. Entonces, si tienes una delante, puede haber un par de cosas que puedes hacer con ella. La primera es el encabezado S maxage. Si esto no es tan antiguo, ese número significa un año, entonces no tienes que volver al origen para comprobar una nueva versión. Maxage cero aquí significa que el navegador nunca confía en tu versión antigua, siempre vuelve y comprueba. Pero SMaxage le está diciendo a la CDN que tiene esta copia durante un año, que siempre puede manejar estas solicitudes. Entonces, los navegadores se registran, pero solo llegan hasta el nodo de CDN más cercano. El truco con esto es que luego necesitas incluir alguna forma de decirle a la CDN que este contenido ha cambiado cuando el contenido cambie. Ahora,

La siguiente versión de esto es el encabezado 'stale while revalidate'. Esto le dice a la CDN que, si bien la versión en caché puede haber caducado y necesita obtener una nueva versión, puede seguir enviando la antigua durante este período de tiempo. Entonces, durante un año, puede servir la antigua. Pero el XMAX de 60 significa que una vez por minuto necesita verificar si hay una nueva versión. Y esto invierte un poco el proceso. Ahora la CDN está obteniendo datos del servidor de origen, pero a una velocidad muy baja. Todos tus usuarios siguen accediendo a la CDN local, por lo que obtienen respuestas muy rápidas, pero tu contenido nunca está más de 60 segundos desactualizado. La otra ventaja de esto es que podrías tener millones de personas accediendo a tu sitio web, pero tu origen solo verá una solicitud cada 60 segundos desde cada nodo en la red. Me encanta usar esto y creo que es genial, pero esperaba que fuera una parte mucho más importante de las implementaciones de las personas si no fuera por la parte 2, que es el surgimiento de Jamstack.

Jamstack es una de las tendencias más importantes en las implementaciones web recientes, y creo que es popular porque, bueno, oculta muchos de los detalles sobre las CDNs y te brinda algo mucho más fácil de entender. Tradicionalmente, tenías una CDN que se encontraba entre tus usuarios y tu origen, pero necesitabas que los tres estuvieran presentes, necesitabas que tu origen estuviera en vivo y la CDN solo era una mejora. Jamstack, aunque tiene la misma estructura, cambia eso y ahora dice que la CDN es tu host, tu CDN responde a cada solicitud, pero para cambiar el contenido, ahora le dices a la CDN: 'aquí está la nueva copia del archivo'. Es un cambio sutil, pero realmente aumenta la estabilidad de tu sitio, y creo que la estabilidad es lo mejor de Jamstack. Debido a que solo estás implementando archivos estáticos y lo estás haciendo a nivel global, tu capacidad de respuesta ante la carga aumenta considerablemente. No hay ninguna ruta que llegue a tu servidor de origen porque realmente ya no tienes un servidor de origen, por lo que puedes dormir tranquilo porque guardar archivos estáticos es muy sencillo. En cuanto al rendimiento, puede ser mucho mejor que lo que estás haciendo en este momento, pero debo decir que definitivamente hay algunas cosas que son difíciles de hacer en una implementación estática, lo que significa que terminas dependiendo mucho más del JavaScript del lado del cliente, por lo que en algunos casos puedes obtener un rendimiento peor incluso al pasar a un sitio estático. La misma historia se aplica a la complejidad, donde las implementaciones ahora son muy simples porque solo estás enviando archivos estáticos, pero generar una instantánea perfecta de tu compilación requiere un poco de esfuerzo adicional, y luego debes descubrir qué hacer con las piezas dinámicas y cómo ejecutarlas de manera eficiente en el navegador. Pero una de las cosas que más me desagrada de JAMstack es su ineficiencia. En el sentido tradicional, cada cambio en tu sitio necesita generar todo el sitio nuevamente, lo que significa que un sitio de 10,000 publicaciones de blog que cambia una ruta puede llevar 30 minutos a una hora para reconstruirse. Esto es un impedimento real para iterar rápidamente en tu código, y es algo que debe abordarse. La forma en que se aborda es mediante las mismas empresas que promueven JAMstack como una metodología y ofrecen plataformas que resuelven algunos de estos problemas. En lo que llamo el borde integrado. Entonces, no solo adoptan el enfoque simple de JAMstack, sino que también tienen estrategias para publicar o reconstruir solo las cosas que han cambiado o solo publicar las cosas que han cambiado. O en el caso de decirle a la CDN, ofrecer estrategias que hacen algo muy similar a 'stale while revalidate'. Ejecutando tu compilación como un servidor en segundo plano. Todo esto es realmente bueno, pero para mí no es tan bueno como lo que teníamos antes con el mundo HTTP puramente estático, lo siento, el mundo HTTP puramente estandarizado. Hay algunas cosas que creo que debilitan el atractivo de JAMstack.

Y lo primero es cuánto te atan todos estos proveedores. más fácil, más fácil en cada paso en un mundo JAMstack, tiene más y más problemas asociados con ello. Por ejemplo, estos son algunos fragmentos que se incluyen en un archivo de configuración de Netlify donde estás haciendo redireccionamientos simples o estableciendo algunos encabezados en algunas rutas. Esto es algo que podrías haber hecho con unas pocas líneas de código, si tuvieras un servidor Node cualquier tipo de servidor web, que ahora tienes que poner en un conflicto específico de la plataforma. No es peor en el mundo, pero cada vez que recurres a esto para resolver un problema, te alejas de algo que puedes obtener en otro lugar.

Lo otro es que ha habido una tendencia a mirar más allá de JAMstack hacia esta idea de un marco híbrido, donde algunas páginas son estáticas y otras son dinámicas. Pero algo de lo que me gustaría que la gente esté más consciente es que cuando estás pensando en el rendimiento y en pasar de estático a dinámico, puede haber una gran disparidad de rendimiento entre los dos. En realidad, ejecuté una prueba de referencia esta mañana en una aplicación Next.js de Vercel. Los datos aquí, los omitiré, pero son más para las diapositivas posteriores, pero puedes ver la diferencia entre una ruta estática y dinámica aquí. Donde una dinámica, en el mejor de los casos, sigue siendo unos cientos de milisegundos peor que la estática, pero a medida que llegas a los percentiles más altos, es decir, al 50% o al 25% de tu audiencia, obtienes tiempos de respuesta más lentos, de hasta aproximadamente un segundo. Y esto es el tiempo hasta el primer byte. Esto es antes de que el resto de tu aplicación se cargue. Esto es solo adicional a todo lo demás. Esta es una prueba sintética, y te animo a que nunca confíes en una prueba sintética o cualquier prueba que no hayas realizado tú mismo y comprendido las limitaciones. Realiza estas pruebas tú mismo. El único propósito de los números aquí es mostrar que hay una gran diferencia entre las tuberías de renderizado entre la mitad estática y dinámica de la plataforma Cells. Y eso es algo que puede que no sea obvio considerando lo fácil que es pasar de uno a otro.

Todo esto nos lleva al futuro. Bueno, que también es el presente pero no está distribuido de manera uniforme, que es el dynamic edge. Así que en lugar de mirar la arquitectura de la CDN y decir, bueno, hagamos una CDN estática, un edge estático, y enviemos actualizaciones a ella como lo hacemos en Jamstack. Si tenemos un dynamic edge, entonces realmente no necesitamos un servidor de origen en absoluto. De hecho, el objetivo principal de una CDN era ejecutarse cerca de nuestros usuarios. Ahora, ¿qué pasaría si aquí es donde lo alojamos? ¿Qué pasaría si lo alojamos en todo el mundo? Quiero decir, al fin y al cabo, es solo código front-end. No son bases de datos masivas y todas esas cosas. Así que esta es una nueva categoría de herramienta. Ahora voy a hablar de Cloudflare Workers, porque Workers en este espacio es el líder. Pero esta es una categoría que seguirá creciendo. Y aunque algunos productos de competidores harán algunas de estas cosas, pero no todas ellas, espero que todos mejoren con el tiempo. No debes pensar que solo te estás decantando por un proveedor, porque esto es simplemente una nueva forma de ejecutar código en el edge. En el caso de Workers, hay algunas cosas que debes saber, ¿verdad? Tienes un límite de script de un megabyte, porque se implementa en cada ubicación que tieneCloudflare.

Pero, por otro lado, se ejecuta en las 200 ubicaciones. Se ejecuta en un contenedor V8, no en Node.js. Así que es JavaScript, pero necesitas un nuevo modelo mental. Hay algunos límites más estrictos de CPU y RAM, aunque para cosas de propósito general, debería estar bien. Una de las cosas emocionantes es que no hay impacto de inicio en frío debido a esta diferente arquitectura. Cuando vimos en ese gráfico de Vercel, ese aumento de un segundo, fue debido a Amazon Lambda en segundo plano haciendo un inicio en frío para una nueva solicitud. En los workers, ese inicio en frío es realmente rápido. Ocurre en segundo plano mientras se realiza el handshake TLS. Así que mientras tu navegador está negociando con el servidor más cercano para cifrar una conexión SSL, el worker se está iniciando en segundo plano. Así que cuando el cuerpo de la solicitud realmente llega, tu trabajo está listo para funcionar, haciendo efectivamente invisibles los inicios en frío.

Ahora, una versión de este futuro es que salgan estos nuevos frameworks de edge y todos sean realmente geniales. Nux.js aún no se ha lanzado para su versión serverless de edge, pero lo estará muy pronto. Donde estos nuevos frameworks ofrecen cosas nuevas y geniales y cambias tu aplicación a ellos y tienes un gran tiempo, un rendimiento realmente genial, y esa es la próxima historia. Pero para mí, eso no es suficiente. Creo que tenemos la oportunidad de hacerlo mejor. Porque estamos pasando de un modelo en el que la CDN solo es capaz de almacenar en caché y, por lo tanto, solo es capaz de cosas estáticas, a poder ejecutar toda tu aplicación. Entonces, ¿por qué necesitamos limitarnos solo a los frameworks diseñados para eso? He estado tratando de lograr este futuro en el que cualquier persona pueda acceder a su código y portarlo para que se ejecute en el edge con los paquetes de aplicaciones front-end del proyecto. La arquitectura de un FAB es que debería poder ser eso, perdón, cualquier aplicación que use cualquier framework, sin importar si es estática o dinámica, debería poder compilarse en un FAB. El FAB es un único punto de entrada del servidor y un directorio lleno de activos. La clave es que los FABs se pueden implementar en nuevas ubicaciones globales del edge, así como en cualquier otro lugar. Entonces, en cualquier lugar que pueda ejecutar JavaScript, en cualquier lugar que pueda ejecutar Node, es completamente compatible hacia atrás. La idea es que puedas probar si tu aplicación es compatible con FABs en este momento, tal vez usarlo internamente, probarlo en el edge y ver cómo funciona antes de decidir adoptarlo realmente. Porque puede haber partes de tu aplicación que deseas reescribir para obtener el mejor rendimiento. Es genial poder verificar que las cosas realmente funcionan muy bien.

Ahora, no tengo mucho tiempo para entrar en esto, pero cuando un FAB se implementa de manera tradicional, se ejecuta de manera diferente a cuando se ejecuta en el edge. Algunas de las características de rendimiento son mucho mejores al ejecutarse en el edge. En la implementación tradicional, hemos intentado diseñarlo para que se ejecute lo mejor posible, pero las verdaderas mejoras se obtienen si comienzas a usar algo en los workers. Y esta mañana hice otra prueba de referencia de NextJS ejecutándose dentro de un FAB en Cloudflare Workers. Nuevamente, estos números son solo para las diapositivas. Es más fácil verlo en el gráfico.

El rendimiento estático es bastante bueno.

El rendimiento dinámico está bien.

NextJS es actualmente el peor caso de uso para los FABs.

Es el framework más pesado o voluminoso, debería decir.

Está diseñado principalmente para NodeJS.

Realmente no está diseñado para ejecutarse dentro de un FAB.

Por eso tenemos que hacer mucho en el compilador para que sea compatible.

Por eso ves una gran disparidad entre el rendimiento estático y dinámico aquí.

Es algo en lo que estaremos trabajando activamente e intentando mejorar.

Pero si usas FABs con otros frameworks, deberías obtener un rendimiento aún mejor que esto.

Y solo para comparar, estamos viendo un rendimiento estático extremadamente similar a Vercel.

Pero el rendimiento dinámico es claramente mucho mejor.

Aunque todavía hay algo de lentitud en la cola larga, en el percentil 75.

En el peor de los casos, se ejecuta en 400 milisegundos en lugar de 1.5 segundos.

Con eso, te animo a que lo pruebes.

Te animo a que vayas a fab.dev o al GitHub y eches un vistazo.

Intenta compilar tu aplicación en él, verifica si se ejecutará en workers.

Workers está disponible en workers.dev.

Si vas a fab.dev, encontrarás un servidor de Discord.

Puedes ponerte en contacto conmigo y te ayudaré, si puedo.

Pero aparte de eso, gracias por tenerme aquí.

Y ahora es el momento de las preguntas.

Wow, Glenn.

Eso fue fabuloso.

Increíble.

Gracias por esa gran charla.

Y perdón por este chiste malo.

Glenn, ¿puedes unirte a mí en el escenario para que podamos ver los resultados de tu encuesta?

Genial.

¡Hey, qué bueno verte de nuevo!

Entonces preguntaste a la gente, ¿cuánto han hecho con el servicio de CDN/dynamic edge? Y bueno, el 43% ha dicho que nunca ha utilizado uno. Y luego el mayor porcentaje es el uso de Jamstack. Por lo tanto, mi sitio básicamente puede construirse estáticamente y navegar desde el edge. ¿Qué opinas de los resultados? ¿Es esto lo que esperabas?

Sí, más o menos. Aunque me sorprende que el 8% implemente aplicaciones completas en el edge. Eso es genial. Creo que dentro de un par de años, eso será cada vez más alto. Pero el 8% ya es impresionante.

Sí. Eso es bastante nuevo. Antes de esta charla, ni siquiera había oído hablar de ello. Así que el 8% de nuestra audiencia, eso es bastante sorprendente.

Sí. Así que felicidades, supongo. Quiero recordarles a todos que pueden hacer sus preguntas en el canal de Discord. Y vamos a pasar a las preguntas ahora mismo. Y la primera es en realidad lo que me intrigaba. Cuando estaba viendo tu charla. Y sí, veo que es una gran solución de código abierto respaldada por una gran empresa. Pero, ¿cuál es el modelo de negocio detrás de esto?

Bueno, comenzó como una solución para resolver un problema de la empresa en la que trabajaba, Link, que era la necesidad de que las personas pudieran implementar aplicaciones y que pudiéramos construir vistas previas de las aplicaciones de las personas. Y todo lo que había por ahí, como Docker o cualquier otra cosa, o simplemente un archivo zip lleno de HTML y JavaScript, no encajaba bien. Entonces, el directorio estático, obviamente no se puede hacer ningún renderizado del lado del servidor. Y realmente quería ver el futuro del renderizado del lado del servidor y Docker es. Es realmente pesado, quiero decir, solo piensa en lo grande que es una imagen de Docker solo para unos pocos cientos de K, un par de Meg de HTML, CSS y JavaScript, es como usar un mazo para romper una nuez. Y así, básicamente, surgió para resolver ese problema. ¿Cómo llevamos a los clientes a Link de una manera en la que podamos construir cada confirmación y darles una URL para esa confirmación para siempre, pero sin encerrarlos en lo estático? Y desde ahí ha crecido para, básicamente, implementarlo en cualquier lugar, compilarlo desde cualquier framework. Todo esto son solo extensiones de esa primera idea, y ha crecido a partir de ahí.

Genial. Y luego, ¿el equipo eres tú ahora, o hay más personas? ¿Hay un equipo, o eres tú solo?

Principalmente soy yo, pero cada vez hay más colaboradores. He estado trabajando con alguien recientemente para adaptar Flare React a esto, y parte de la razón es que aunque Flare React ya puede implementarse directamente en los workers de Cloudflare, eso es para lo que está diseñado, es básicamente Next.js diseñado para workers, poder ponerlo en un FAB significa que es mucho más fácil probarlo localmente, es mucho más fácil revisarlo, puedes pasarlo por Link, puedes implementarlo en otra infraestructura y hace que ese proyecto sea mucho más portátil.

Así que me alegra ver que alguien se une para intentar lograrlo. He tenido mucha colaboración en el compilador de Next.js, que es uno de los objetivos más difíciles para nosotros, así que realmente lo estoy liderando yo, pero estamos sumando colaboradores todo el tiempo. Genial, siempre es bueno escuchar que la gente está dispuesta a ayudar.

Tengo una pregunta de Mike, ¿hay estadísticas disponibles también para aplicaciones de Angular, no AngularJS, y Vue.js implementadas usando fab.dev? No, no muchas. Básicamente porque, bueno, Vue y el renderizado del lado del servidor es algo en lo que he investigado, pero aún no tengo una historia de éxito muy exitosa. Nuxt.js, que es un framework construido sobre Vue y el renderizado del lado del servidor, estaba teniendo un poco de reestructuración antes de su versión 3, creo, que es la versión actual que está por salir, la cual es compatible directamente con el renderizado en el edge, como los workers, y en el ecosistema de Vue hemos pausado en gran medida ese desarrollo hasta que se realicen esos cambios. Parece que eso está realmente en el horizonte, así que espero volver a eso pronto.

En cuanto a Angular, no es un área en la que tenga mucha experiencia, pero cada proyecto de Angular que he visto se ha compilado estáticamente, y cualquier cosa estática es muy, muy rápida con FABs. Está optimizado de manera extremadamente eficiente para servir desde el edge, pero también es bastante fácil para cualquier cosa, puedes usar prácticamente cualquier CDN para hacer eso. Los FABs realmente destacan cuando quieres agregar un poco de lógica, quieres hacer proxies inversos de /API a tu backend, y luego quieres previsualizar eso de manera diferente en el entorno de pruebas y producción. Los FABs hacen que todos esos casos de uso funcionen muy fácilmente, pero la parte de Angular de tu código debería funcionar muy bien.

Genial, solo un pequeño aporte de mi parte. ¿Tienes alguna conexión con el equipo de Nuxt si necesitas ayuda, porque uno de mis compañeros es desarrollador principal allí, puedo ponerte en contacto. Oh, eso sería genial. Tengo una sala de chat en Discord en la que ocasionalmente intercambiamos mensajes, pero no he hablado con ellos desde hace algunas semanas. Me encantaría reabrir esas líneas de diálogo nuevamente. Muy bien, te pondré en contacto con él en Discord. Siguiente pregunta de Mark C, ¿qué consejo o guía tendrías para aprovechar Akamai Edge Workers con Next.js? Estamos alojando nuestros activos estáticos en S3 y nos encantaría ver cómo podemos integrarlo con Edge Workers. Sería fantástico hablar de eso después, porque es un objetivo que aún no he intentado implementar. Así que los FABs deberían ser perfectamente compatibles, pero no lo sé. No he tenido un caso de prueba para eso. No teníamos clientes en Lync que estuvieran buscando hacer eso todavía, así que no había impulso para hacerlo. La compilación de Next.js a un FAB es algo en lo que estoy trabajando en este momento y está mejorando rápidamente y preparándose para un lanzamiento adecuado en la próxima semana. Pero el tema de Edge Workers debería ser completamente compatible según entiendo. Pero sí, sería genial colaborar en eso. Genial. Entonces Mark puede contactarte. Sí. Genial. Si vas a FAB.dev, hay un enlace de Discord en la página de inicio.

Puedes unirte a nuestro Discord y enviarme un mensaje directo allí. Muy bien, genial. Chrissy pregunta, ¿funciona FAB con Node Express para admitir enrutamiento dinámico en aplicaciones frontend? Sí, cuando trabajas en FAB localmente, viene con su propio servidor express llamado FAB serve. Dentro de eso, hay una pequeña máquina virtual sandbox que se utiliza para aislar el tiempo de ejecución de FAB y simular entornos serverless para que FAB no pueda escapar. Hay ciertas restricciones en un FAB que lo hacen más seguro y permiten implementarlo en algo como Wekas. Puedes usar esos paquetes desde tu propio servidor express o llamarlos directamente y usar FAB serve en la línea de comandos para ejecutarlo.

Muy bien, genial. La siguiente pregunta es, ¿cuáles son los mayores desafíos de rendimiento en las soluciones web modernas a los que te enfrentas? Sí. Lo más importante es que los FABs se basan en un estándar en el que hemos dejado atrás a Node.js. Si miras un proyecto como Next.js como ejemplo, es un framework web perfectamente rápido, pero todo lo que contribuye a Next.js asume que tienes un entorno Node.js, asume que tienes express, asume que no necesitas preocuparte por el tamaño del paquete. Y convertir eso en un FAB significa que tienes que reemplazar muchas de esas modules. Así que tienes que proporcionar implementaciones en JavaScript para las API de Node para que se ejecuten dentro del FAB. Es bastante similar a compilar cosas para que se ejecuten en el navegador. Eso significa que incluso para cosas simples, puedes encontrar que el rendimiento no es tan bueno como debería ser. En el ejemplo que te mostré con los dos gráficos de cosas estáticas versus dinámicas en Next.js en workers, esas dos líneas deberían ser prácticamente idénticas. Pero debido a los diferentes caminos de código a través de un FAB y al trabajo adicional que tienes que hacer para que Next.js sea compatible, se producen disminuciones adicionales de rendimiento. A largo plazo, podremos resolver muchos de esos problemas. Pero encontrarás que algunos proyectos simplemente no podrán tener el mismo nivel de rendimiento que otros porque tendrán conexiones más profundas y suposiciones más profundas de que se están ejecutando en Node y, por lo tanto, requerirán más código de shim y más andamiaje para ejecutarse en un FAB.

Muy bien, gracias. Tenemos tiempo para una pregunta más. La pregunta es de Aston. ¿Podemos usar FAB como un proxy inverso para apuntar a las API del entorno con una única compilación para la parte frontal? Sí, eso es correcto. Una única compilación produce un FAB. El FAB puede tener tanta lógica de servidor.js como desees. Puede incluir un montón de activos y luego, de forma dinámica, el componente del servidor se puede iniciar con diferentes variables de entorno para apuntar a diferentes lugares. La idea es que un solo proyecto puede tener una especie de idea de un backend para frontend. Puede ser una API, puede ser un conjunto de rutas de proxy, puede ser tal vez no todo tu backend, pero es lo que hace posible escribir tu frontend. Y eso puede iterar juntos. Así que cada vez que implementas cada confirmación, estás implementando tu backend para frontend como parte de este proyecto, así como todos los activos estáticos que construiste para esa confirmación. Genial. Eso suena realmente poderoso, Glenn. Gracias por tu arduo trabajo y por compartir esto con nosotros. Vamos a aumentar ese 8%, ¿verdad? Sí, absolutamente. Gracias por estar con nosotros y espero verte de nuevo pronto. Adiós. De acuerdo, gracias.