Nuevas formas de componer contenidos en el edge con Compute

La mayor parte del contenido que se distribuye a través de Fastly se crea en los servidores de nuestros clientes, pero no tiene por qué ser así. Siempre ha sido posible generar contenido de forma programática y, con la llegada de Compute, que permite escribir, probar y desplegar código en nuestro entorno informático sin servidores, ahora es más fácil que nunca crear y transformar contenido de una manera eficiente.

En el esquema típico, hay una red de distribución de contenidos (CDN) entre tus servidores web y tus usuarios finales en la que se almacena el contenido en caché para que esté más a mano que en el origen, sobre todo para usuarios que se encuentran lejos de tus servidores. Este es un componente esencial de la mayoría de los sitios web modernos que aspiran a ofrecer un buen rendimiento a escala.

Así, cuando tener una CDN delante de tu sitio se convierte en una necesidad, es una pena seguir generando todo el contenido en un solo lugar. Si tienes una herramienta tan potente para procesar peticiones, situada tan cerca del usuario final, ¿por qué no convertirla en una parte más integral de tu infraestructura?

Cómo empezar: robots, redireccionamientos y CORS

CORS, o el uso compartido de recursos entre orígenes, es un gran ejemplo de para qué puede servir el edge. Cuando se solicitan recursos entre orígenes, es posible que los navegadores tengan que emitir una petición OPTIONS preparatoria para validar que el host de destino esté dispuesto a atender la petición. La respuesta deberá citar el nombre del origen que envía la petición, así que no será un contenido totalmente estático, pero es lo suficientemente sencillo como para que se genere en el edge, ya sea en Compute o en VCL. Pulsa RUN en el cuadro para probarlo en un servicio VCL de Fastly:

Una respuesta sintética sencilla como esta puede abordar todo tipo de casos de uso. Otro caso común son los redireccionamientos; ya se trate de HTTP hacia HTTPS, normalizar un nombre de host (p. ej., añadiendo www. a un dominio raíz... ¡o eliminándolo!) o asignar rutas antiguas a nuevas.

Manejar redireccionamientos en el edge de esta manera es ideal para despejar el origen y, potencialmente, dar un gran impulso al rendimiento para los usuarios finales.

Por supuesto, las respuestas sintéticas también pueden incluir contenido en el cuerpo. En una arquitectura de microservicios, puedes dudar acerca del lugar desde donde atender archivos como robots.txt. ¡Hazlo desde el edge!

Subimos de nivel: API atendidas desde el edge y terminación de balizas

Fastly se utiliza a menudo como puerta de enlace de API (y resultamos ideales para ello), pero ¿has pensado en atender respuestas de API en el edge sin necesidad de enviarlas al origen? Esto es especialmente útil cuando se quiere dar a los clientes acceso a información que ya está disponible dentro de Fastly, como datos de geolocalización. Pruébalo en VCL:

Hay una gran cantidad de información que Fastly revela de forma automática a tus aplicaciones del edge, o tú puedes añadir tus propios conjuntos de datos de clave-valor utilizando los diccionarios Edge.

Y ya que estamos con las API: hemos hablado largo y tendido sobre la terminación de balizas en el edge, es decir, todas esas métricas que recopilas de clientes para medir el rendimiento y la experiencia de usuario. Bueno, pues no hace falta que bombardees tus propios servidores con esa información. Con algo de ayuda de nuestro envío de registros en tiempo real (una de mis funcionalidades de Fastly favoritas), puedes limpiar, validar, enriquecer y agregar los datos entrantes, para luego enviarlos desde el propio Fastly a cualquier lugar, desde S3 y Google Cloud Storage hasta BigQuery o Splunk, o incluso a tus propios servidores de recopilación.

Máximo provecho: creación de plantillas de páginas complejas en el edge

Hasta ahora, todo bien. Todas estas soluciones llevan años impulsando los sitios de nuestros clientes y ahora pueden realizarse tanto en VCL como en Compute. Sin embargo, algo que VCL nunca ha podido hacer es componer un cuerpo de respuesta procesando los datos de la API del nivel superior. Imaginad las posibilidades que se abrirían: poder consultar y cargar datos de manera eficiente desde múltiples fuentes en paralelo, incluidas algunas que pueden estar disponibles en la memoria caché, para luego generar páginas HTML utilizando plantillas almacenadas en el edge.

Menos tráfico en el origen, mayor facilidad para depurar y separar posibles problemas, rendimiento más rápido para el usuario final. Estaríamos hablando de pasar toda la capa de visualización de tu aplicación al edge.

Mi colega Kailan Blanks añadió hace poco al Developer Hub una guía por pasos sobre cómo hacer esto con una aplicación de pronóstico del tiempo utilizando Rust en Compute. Aquí tenemos la aplicación resultante ejecutada en un marco en esta misma página:

Me encanta este ejemplo porque muestra claramente todos los elementos necesarios para crear enormes aplicaciones en el edge:

1. Funcionalidades de la plataforma: utilizamos la API de geolocalización de Fastly para averiguar la ubicación del usuario final, así como un diccionario Edge para almacenar la configuración dinámica.

2. Peticiones de la API al origen: enviamos las peticiones a Openweathermap a través de la caché del edge de Fastly, utilizando el método send() de nuestra estructura Request del SDK de Rust.

3. Bibliotecas de la comunidad: analizamos las respuestas de la API de Openweathermap con serde_json y, a continuación, componemos preciosas páginas HTML con tinytemplate. Puedes utilizar cualquier módulo o biblioteca que compile en WebAssembly.

En muchos casos en los que el contenido se considera «no almacenable en caché», es porque se compone de muchos bits de datos diferentes combinados entre sí. Por ejemplo, una página HTML totalmente formada podría tener el nombre del usuario actual, un artículo basado en la URL y enlaces basados en el país desde el que se solicita la página.  

El encabezado Vary ofrece un potente mecanismo para mantener este tipo de variaciones de un objeto almacenable en caché por separado, pero puede llegar un momento en el que haya demasiadas variaciones para poder utilizar este método. ¡Ahí es donde la creación de plantillas en el mismo edge abre tantas posibilidades! Cada uno de los elementos individuales de los datos que entran en la composición de la página puede ser almacenado en caché por separado, y las páginas dinámicas se pueden montar juntando todas las piezas de contenido que correspondan.

Hace unos meses escribí sobre nuevas formas de plantear el diseño de aplicaciones «nativas del edge», pero puede que pasar algo de creación de plantillas al edge sea más fácil de lo que crees. ¿Por qué no eliges una página cuyo rendimiento quieras mejorar y lo intentas?