El Auge del Borde Dinámico

Rate this content
Bookmark

En los últimos años, la comunidad de aplicaciones web de JS ha visto un creciente enfoque y conciencia en cuanto a rendimiento y escalabilidad. Los días en que los sitios de producción prominentes servían páginas completamente en blanco esperando paquetes monolíticos de megabytes de JavaScript están (¡en su mayoría!) detrás de nosotros.

Una gran parte de esto ha sido una integración más profunda con las CDNs, después de todo, la latencia de ida y vuelta es uno de los principales determinantes del rendimiento para una audiencia global. Pero los frameworks, y las compañías que los respaldan, tienen enfoques diferentes en cómo pueden ser utilizados, y las complejidades operativas que sus estrategias introducen tienen consecuencias reales.

Pero ¿qué pasaría si, en lugar de un origen dinámico que envía instrucciones a una CDN estática, pudieras ejecutar tu aplicación directamente en el borde? Resulta que eso no solo mejora el rendimiento, sino que también simplifica enormemente nuestras vidas en cuanto a implementación y mantenimiento.

32 min
01 Jul, 2021

Video Summary and Transcription

La Charla discute el auge del borde dinámico y el pasado, presente y futuro del alojamiento frontend. Se enfatiza el impacto de la latencia en el uso de las CDNs y la relevancia de las CDNs en el desarrollo de aplicaciones JavaScript. Se exploran el uso de CDNs para contenido que cambia rápidamente y los beneficios del enfoque Jamstack. El futuro del borde dinámico se encuentra en plataformas como Cloudflare Workers. La Charla también destaca los beneficios de rendimiento de ejecutar paquetes de aplicaciones frontend (FABs) en el borde y los desafíos que se enfrentan para lograr un rendimiento óptimo.

Available in English

1. Introducción al auge del borde dinámico

Short description:

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. He realizado algunos proyectos de código abierto en el espacio de React. Más recientemente, 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. El año pasado, Link fue adquirido por Cloudflare workers. 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.

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.

2. El impacto de la latencia en el uso de CDN

Short description:

Hoy, discutiré cómo las CDNs se han convertido en una parte integral de nuestros flujos de trabajo de aplicaciones frontend. Las CDNs se utilizan ampliamente debido a su distribución geográfica, que desempeña un papel crucial en la reducción de la latencia. Realicé un experimento comparando las velocidades de descarga desde diferentes ubicaciones y descubrí que incluso un pequeño aumento en la latencia puede afectar significativamente los tiempos de descarga. Esto se debe a la forma en que funciona TCP, donde la transferencia de datos inicial es más lenta y aumenta gradualmente. Por lo tanto, es esencial estar cerca del servidor para un rendimiento óptimo.

plataforma global completa, lo cual es bastante emocionante. Así que hoy quería profundizar en algo que encontré realmente interesante en los últimos años al adentrarme en este tema, que es cómo hemos llegado a depender y cómo las CDNs se han convertido en parte de nuestros flujos de trabajo de aplicaciones frontend. Así que para recapitular, una arquitectura de CDN tradicional tiene la CDN entre tus usuarios y tu servidor de origen, tu host real. Y las solicitudes fluyen y las respuestas vuelven. La CDN tomará copias de esas solicitudes, respuestas, dependiendo de algunos algoritmos, algunas directivas. Tu servidor de origen es la verdad absoluta.

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

3. Relevance of Latency and CDN Usage

Short description:

En esta parte, discuto la relevancia de la latencia en el desarrollo de aplicaciones JavaScript de hoy en día y la importancia de utilizar CDNs. Las CDNs con control de caché inmutable permiten una entrega eficiente de aplicaciones del lado del cliente, especialmente cuando se utiliza la división de paquetes. Si bien no todas las aplicaciones requieren esta optimización, adoptar una red global e integrar CDNs en el proceso de implementación es crucial para construir un sitio web rápido. También destaco los beneficios de utilizar el encabezado S maxage para reducir las solicitudes al servidor de origen y la necesidad de un mecanismo para notificar a la CDN los cambios de contenido.

Ser local es realmente importante. Esto fue en realidad en un video llamado Por qué importa la latencia, que fue el episodio 10 de Frontend Center. También está en YouTube. Si esa información es nueva para ti, te animo a que lo veas. También hablo sobre TCP.

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,

4. El Impacto de las CDNs y Jamstack

Short description:

Esta parte discute el uso de CDNs para contenido que cambia rápidamente y los beneficios del encabezado 'stale while revalidate'. Luego presenta a Jamstack como una tendencia que simplifica las implementaciones web y aumenta la estabilidad del sitio. Sin embargo, Jamstack tiene limitaciones en términos de rendimiento y complejidad, especialmente al tratar con contenido dinámico. También se destaca la ineficiencia de reconstruir todo el sitio cada vez que hay un cambio. Las empresas están abordando estos desafíos con plataformas integradas en el borde que ofrecen estrategias para publicar solo el contenido que ha cambiado. A pesar de sus ventajas, Jamstack tiene algunas debilidades en comparación con el mundo HTTP tradicional estandarizado.

Esto no se aplica a los activos con huella digital. Esto es para tu índice HTML, cualquier cosa que cambie rápidamente. Pero las CDNs son realmente buenas para actualizar lo que está en caché. Entonces, enviarles un comando para decirles: 'oye, estas URL han cambiado como parte de tu implementación' te brinda un rendimiento realmente bueno y una carga muy baja en tu origen.

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.

5. El Futuro: Dynamic Edge y Cloudflare Workers

Short description:

Los proveedores en el mundo de JAMstack te hacen estar más atado a medida que avanzas. Pasar de estático a dinámico puede tener una gran disparidad de rendimiento. Las pruebas sintéticas muestran una gran diferencia entre las tuberías de renderizado estáticas y dinámicas. El futuro está en el dynamic edge, donde no necesitamos un servidor de origen. Cloudflare Workers lidera en este espacio, pero es una categoría en crecimiento. Hay un límite de script de un megabyte para Workers.

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.

6. Ejecución de FAB en el Edge y Beneficios de Rendimiento

Short description:

Pero, por otro lado, ejecutarlo en las 200 ubicaciones, en un contenedor V8, no en Node.js, trae un nuevo modelo mental. No hay impacto de inicio en frío con los workers, ya que se inician en segundo plano mientras se realiza el handshake TLS. El futuro no se limita a los marcos diseñados para almacenar en caché contenido estático. Los paquetes de aplicaciones front-end (FABs) del proyecto permiten compilar cualquier aplicación, independientemente de su naturaleza estática o dinámica, en un FAB y desplegarlo en ubicaciones globales del edge. Probar la compatibilidad y el rendimiento antes de adoptarlos es crucial. Desplegar FABs en el edge proporciona mejores características de rendimiento que la implementación tradicional, especialmente con Cloudflare Workers.

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.

7. Rendimiento de los FABs y Llamado a la Acción

Short description:

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. 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. 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.

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!

QnA

CDN/Uso de Dynamic Edge y Modelo de Negocio

Short description:

El 43% nunca ha utilizado un servicio de CDN/dynamic edge. El 8% implementa aplicaciones completas en el edge. El modelo de negocio detrás de la solución de código abierto comenzó resolviendo un problema para la empresa Link, permitiendo la implementación y vista previa de aplicaciones. El equipo está compuesto principalmente por el orador, pero hay cada vez más colaboradores, incluido alguien que trabaja en la adaptación de Flare React a la solución.

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.

Colaboración, Compatibilidad e Integración

Short description:

Me alegra ver colaboración en el compilador de Next.js. Aún no hay estadísticas disponibles para aplicaciones de Angular y Vue.js en fab.dev. Vue.js y el renderizado del lado del servidor se están reestructurando para ser compatibles con el renderizado en el edge. Los proyectos de Angular compilados estáticamente funcionan bien con FABs. Los FABs destacan al agregar lógica, proxies inversos y previsualizar diferentes entornos. Puedo ponerte en contacto con el equipo de Nuxt. La integración de Akamai Edge Workers con Next.js no se ha probado, pero los FABs deberían ser compatibles. La compilación de Next.js a un FAB está mejorando rápidamente. Contáctame en el Discord de FAB.dev para obtener más información.

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.

FABs and Performance Challenges

Short description:

Puedes usar FAB con Node Express para enrutamiento dinámico en aplicaciones frontend. FAB viene con su propio servidor express llamado FAB serve, que incluye una máquina virtual sandbox para aislar el tiempo de ejecución de FAB. Los FABs enfrentan desafíos de rendimiento ya que se basan en un estándar que se ha alejado de Node.js. Convertir frameworks como Next.js a FABs requiere código de shim y trabajo adicional, lo que resulta en una disminución del rendimiento. Los FABs se pueden utilizar como un proxy inverso para apuntar a las API del entorno con una única compilación para la parte frontal, lo que permite un enfoque de backend para frontend.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion