Sitios web estáticos y sin origen: ahora en el edge

La mayoría de los sitios web son estáticos. Eso significa que, cada vez que accedes a alguna de sus páginas, la red de distribución de contenidos de Fastly debe acceder a un origen para conseguirla. Nosotros hemos querido ir un paso más allá: hemos imaginado y puesto a prueba todo el proceso, sin un origen.

¿Estás diseñando tu sitio web con un generador de sitios estáticos? Entonces, es posible que estés usando un entorno conocido que genera archivos estáticos (como create-react-app, Gatsby, Docusaurus o Vite). ¿O solo necesitas distribuir algunos archivos estáticos? En cualquier caso, nuestra herramienta compute-js-static-publish te permite desplegar y distribuir contenidos desde nuestra increíblemente rápida plataforma Compute@Edge.

La naturaleza de la red sigue siendo estática. Es verdad que hay muchos sitios web que son interactivos, pero la mayoría del contenido de internet —artículos de blog, páginas de consultas o especificaciones de productos— es estático. Es decir, el contenido de las páginas se modifica o actualiza en algunos archivos o en un sistema de gestión de contenidos; y el sitio web distribuye la versión más reciente de toda esa información. 

Algunos sitios web utilizan generadores de sitios estáticos (como Gatsby). Son herramientas que permiten diseñar sitios web enteros combinando datos de origen en Markdown o HTML con plantillas. Fastly no es una excepción y también utiliza este tipo de generadores. Por ejemplo, Gatsby, con el que generamos Developer Hub, que alberga todos nuestros tutoriales y materiales de consulta; y Docusaurus, que genera nuestro sitio web Expressly. En líneas generales, la salida de estos generadores es un paquete de archivos.

Estos archivos se suelen cargar en un servidor web y se distribuyen por medios estáticos. Además, la práctica recomendada actualmente es utilizar una red de distribución de contenidos (como la de Fastly) delante de ese servidor. Así, tu sitio web se puede almacenar en caché en cualquier parte del mundo.

Pero reflexionemos un momento: hasta aquí, la única función que realiza el servidor web es almacenar una copia íntegra del sitio web para que la CDN la almacene en caché; además, es posible que cada uno de los POP contenga subconjuntos del sitio web.

¿Qué ocurriría si pudiéramos cargar todo el sitio web en Fastly? Todos los POP contendrían la totalidad de archivos necesarios para distribuir el sitio web. ¡Y ya no necesitaríamos el origen!

Publicación estática en el edge

Ya es posible realizar publicaciones estáticas en el edge. Y todo gracias a @fastly/compute-js-static-publish. Se trata de una herramienta de línea de comandos y una biblioteca de tiempo de ejecución, que te permite distribuir tu sitio web estático íntegramente en el edge, sin servidor de origen.

Imagina que tienes los archivos de un sitio web almacenados en un directorio llamado «public». Escribe el comando siguiente (suponemos que tienes instalado NodeJS 16+):

npx @fastly/compute-js-static-publish --public-dir=./public

Se genera una aplicación de Compute@Edge en un directorio llamado compute-js. El archivo src/index.js del proyecto generado contiene las líneas de código que permiten distribuir los archivos estáticos.

Ahora puedes poner a prueba tu sitio en el servidor de desarrollo local de Fastly. Si tienes instalada la CLI de Fastly, escribe lo siguiente:

cd ./compute-js
fastly compute serve

Deberías poder acceder a tu sitio web desde http://localhost:7676/.

Por último, cuando estés listo para poner en marcha el sitio, utiliza estos comandos:

cd ./compute-js
fastly compute publish

Cada vez que crees tu proyecto de Compute@Edge (ejecutando fastly compute serve o fastly compute publish), la herramienta compute-js-static-publish examinará tu directorio public y volverá a generar el programa de Compute@Edge.

Entonces, ¿qué pasa con los archivos estáticos?

Todo lo que haya en la carpeta de origen se compila en un solo archivo binario Wasm que podemos desplegar en Fastly.

En nuestro caso, el secreto está en el archivo src/statics.js que se genera. Si echas un vistazo a su contenido, algunas líneas de código se parecen a estas (el contenido real suele variar en función de los archivos de tu proyecto):

import file0 from "../../public/index.html?staticText";
import file1 from "../../public/main.css?staticText";

export const assets = {
  "/index.html": { contentType: "text/html", content: file0, module: null, isStatic: false },
  "/main.css": { contentType: "text/css", content: file1, module: null, isStatic: false },
};

Estas líneas, a través de la función de webpack asset modules (módulos de activos), hacen que los archivos estáticos acaben en el módulo compilado. La función fuerza la creación de varios módulos por cada archivo especificado, cuyo valor es el contenido de cada archivo referenciado. Cada vez que se compila la aplicación, la herramienta examina el directorio public y vuelve a generar el archivo src/statics.js de modo que enumere todos los archivos que haya en el directorio. El contenido de cada archivo acaba en el objeto de activos exportado por este archivo. En el objeto, las claves son los nombres de cada archivo en relación con el directorio del proyecto.

Así que, si queremos saber qué contiene el archivo index.html, solo tenemos que obtener el valor de assets['/index.html'].content.

En cuanto a los archivos binarios (no textuales), la idea principal es la misma, aunque el proceso se complica un poco. Si quieres saber cómo los gestionamos, consulta esta guía de webpack sobre el tipo de módulo asset/inline. ¡Y no olvides leer el código generado!

En consecuencia, la herramienta @fastly/compute-js-static-publish consigue que tus archivos acaben en los POP de Fastly sin origen alguno. El proceso tendría este aspecto:

Otro factor que debes tener en cuenta son las limitaciones y restricciones de Compute@Edge sobre lo que se permite hacer con archivos binarios Wasm. En concreto, procura que el tamaño del paquete compilado no supere los 50 MB. Al tratarse de un tamaño de paquete comprimido, quizás puedas incluir más de 50 MB de archivos de origen. Aun así, recuerda esta limitación.

Intégralo todo

¿Va a cambiar el comando «compute-js-static-publish» la forma de diseñar y desplegar tu sitio web actual? Si ya has recurrido a la integración continua para desplegarlo, podrías publicarlo directamente en Fastly. (Si todavía no lo has hecho, echa un vistazo al recurso GitHub Actions y aprende a utilizarlo con Compute@Edge).

El comando «compute-js-static-publish» se adapta a la perfección a tu canal de despliegues, ya que te permite proporcionar un argumento con el que especificar un Service ID. Suponiendo que tu procedimiento general se parezca a este:

estarías ahorrándote los dos últimos pasos, así:

El último paso quizás tenga esta apariencia:

npx @fastly/compute-js-static-publish --public-dir=/path/to/built/site --service-id=<YOUR_SERVICE_ID>
cd compute-js
fastly compute publish

¿Lo ves? Ya no es necesario cargar en un servidor web los archivos con los que trabajes. Además, dado que el programa en el edge contiene todos tus activos estáticos, tampoco tendrás que realizar purgas. Es decir, una vez que tu paquete se haya difundido a los nodos en el edge de Fastly, todos estos contarán con la versión actualizada del contenido.

¿Qué generador de sitios estáticos usas? Tenemos valores predefinidos para todos.

Durante la fase de diseño de esta herramienta, algunos usuarios de distintos generadores de sitios nos contaron qué opinaban. Para poder trabajar con ellos, a menudo debíamos darles instrucciones según el tipo de generador que escogían. Por lo general, cada generador de sitios genera archivos de salida con un método distinto (p. ej., utilizan una nomenclatura diferente para los directorios de salida). Sin embargo, los usuarios que utilizan un generador concreto suelen emplear los mismos ajustes. Por eso decidimos integrar valores predefinidos: ajustes predeterminados para un generador específico. Eso sí, con la capacidad de anular cualquier ajuste a la carta.

Imagínate que utilizas <u>create-react-app</u> para poner en marcha tu aplicación: utilizarías el comando «npm run start» para iniciar el servidor de desarrollo. Y, cuando estuvieras listo para publicar el contenido, ejecutarías «npm build». De este modo, todos los archivos de salida irían a parar al directorio «build»; y los archivos estáticos (cuyos nombres llevan un hash y se pueden almacenar en caché para siempre), al directorio build/static. Se acabó tener que adjuntar los nombres de esos directorios al comando compute-js-static-publish. En su lugar, solo tendrás que ejecutar esta sencilla línea de código:

npx @fastly/compute-js-static-publish --preset=create-react-app

A día de hoy tenemos valores predefinidos para Vite, SvelteKit, Gatsby, Docusaurus e incluso Next.js (paquete creado con el comando next export).

Compute@Edge, plataforma multiusos

Compute@Edge es una plataforma informática multiusos que permite ejecutar casi cualquier cosa en el edge. Gracias a herramientas como la presentada en este artículo, no tenemos dudas de que se te ocurrirán nuevas formas de usar nuestra plataforma.

En Fastly, nos centramos en idear soluciones que te permitan ejecutar todavía más código en el edge y programar con más rapidez. Y, al mismo tiempo, que te brinden una amplia gama de herramientas novedosas y conocidas. Así que nos gustaría saber si las utilizas y con qué propósito: ¡cuéntanoslo en Twitter¡