Los sitios estáticos siguen online mientras se republican

Republicar un sitio estático en Mythex solía borrar primero los archivos en vivo y luego subir la nueva versión, así que durante la subida algunos visitantes veían una página 404 o una página a la que le faltaban sus scripts. Una subida fallida podía dejar el sitio vacío o a medio actualizar. Ahora la nueva versión se escribe encima de la antigua, las páginas al final, y los restos se eliminan unos minutos después. Una segunda corrección hace que una republicación se vea en segundos en lugar de en un minuto, o, para archivos como un logotipo, en hasta un día.

Cómo se sirve un sitio estático

Un sitio estático es un conjunto de archivos: páginas HTML, JavaScript, CSS, imágenes. Cuando lo publicas en Mythex, lo compilamos, subimos el resultado al almacenamiento de objetos en una carpeta de tu sitio y lo servimos a través de una red de edge: servidores cercanos a tus visitantes que obtienen los archivos del almacenamiento y guardan copias durante un tiempo. (Si esto te resulta nuevo, nuestra guía sobre qué es una CDN explica la idea.)

Había dos cosas mal: el orden en que una republicación cambiaba los archivos y el tiempo que se conservaban las copias antiguas.

Problema 1: la subida vaciaba el sitio primero

Una republicación borraba todo lo que había en la carpeta del sitio y después subía la nueva versión. Durante el tiempo que tardaba la subida (12 segundos para un sitio de 250 archivos en nuestra prueba local), un visitante cuya petición no estuviera ya en caché en el edge recibía un 404, o una página HTML cuyos scripts devolvían 404.

Una subida fallida era peor. La carpeta ya estaba vacía, y en una de las dos rutas de subida el nuevo index.html podía llegar antes que el archivo que había fallado. Una publicación informada como fallida podía dejar en vivo un sitio a medio nuevo.

La solución: escribir encima, páginas al final, limpiar después

1. No borrar primero. La nueva versión se sube encima de la antigua.
2. Recursos antes que páginas. Una página nombra los scripts y estilos que necesita, así que las páginas suben las últimas. Hasta que lleguen las nuevas, los visitantes reciben la página antigua, que nombra los recursos antiguos, que siguen ahí. Cuando llegan, los nuevos recursos que nombran ya están en su sitio.
3. Eliminar los restos más tarde. Antes de la subida, listamos de qué está formado el sitio. Tres minutos después de una subida correcta, se borra todo lo de esa lista que la nueva versión no haya reescrito. Tres minutos es más que los 60 segundos que una página puede estar en caché en el edge y en el navegador, así que un visitante que todavía tenga la página antigua puede encontrar los recursos que nombra.
4. En caso de duda, no borres nada. Si el listado previo a la subida falla, no se elimina nada. Los archivos sobrantes no hacen daño, y la siguiente publicación los limpia. Borrar sin saber qué había es la forma en que un sitio acaba vacío.

Una subida fallida ahora deja el sitio anterior exactamente como estaba.

Lo probamos de extremo a extremo en local, con el script de subida real, la ruta de subida real y el servicio de almacenamiento real, y con visitantes que llegaban con la caché del edge en frío. Con el código antiguo, 55 de 91 visitas se rompieron durante una republicación y 61 de 92 durante una fallida. Con el código nuevo, 0 se rompieron en unas 3.500 visitas que cubrían las dos rutas de subida, una subida fallida y la publicación posterior, y se eliminaron exactamente los archivos sobrantes.

Problema 2: una republicación tardaba demasiado en verse

Aunque la subida fuera bien, los cambios tardaban en aparecer. El edge conservaba su copia de una página durante 60 segundos y la de cualquier otro archivo durante un día, e indicaba a los navegadores que hicieran lo mismo. Los archivos con nombre fijo, como logo.png, una fuente o cualquier cosa de una carpeta public/, podían mostrar la versión antigua hasta un día después de una republicación.

La solución: copias de archivos bajo la compilación

Cuando el edge pregunta a nuestra API dónde vive un sitio, la respuesta incluye ahora un marcador de compilación que cambia cada vez que se publica algo. El edge guarda sus copias bajo ese marcador. Así, una publicación se convierte en un conjunto completamente nuevo de claves de caché en cuanto caduca la consulta de 30 segundos del edge. Las copias antiguas simplemente ya no se encuentran, así que el edge puede conservar copias durante un día sin servir nunca una que sea anterior a la publicación que la reemplazó.

Los navegadores reciben dos reglas distintas:

• Salida de compilación con hash: archivos como assets/index-CzLcxDO8.js, cuyo nombre cambia cuando cambia el contenido, se guardan durante un año y se marcan como inmutables. Con ese nombre nunca pueden estar obsoletos.
• Todo lo demás: páginas y archivos de nombre fijo como un logotipo, se marcan como no-cache, es decir, «comprobar antes de usar». Si nada ha cambiado, la respuesta es un 304 Not Modified diminuto sin cuerpo, ya que ahora respetamos la comprobación If-None-Match del navegador.

Distinguir ambos casos requiere cuidado: un archivo copiado desde public/assets/ conserva su propio nombre, y guardar assets/logo.png durante un año fijaría el logotipo antiguo durante un año. Por eso un archivo solo cuenta como con hash si está en una carpeta de salida de compilación y su nombre tiene un segmento que parece un hash, y no una palabra corriente.

En local, la nueva página y el logotipo se veían 6 segundos después de que la publicación entrara en vivo. Antes eran 60 segundos para la página y un día para el logotipo.

Dos correcciones menores por el camino

• Páginas en blanco con peticiones HEAD. Una petición HEAD pide las cabeceras de una página sin su cuerpo. Estábamos guardando en caché esas respuestas vacías, así que el siguiente visitante de esa página recibía una página en blanco. Las respuestas HEAD ya no se guardan en caché.
• Una página real para «aquí no hay nada». Una dirección sin app devolvía un texto plano «Esta app publicada está fuera de línea o el enlace no se encontró» con código de error 502. Ahora recibe una página adecuada, «Aquí no hay ninguna app», con estado 404 y un enlace de vuelta a Mythex para el propietario. Los dominios personalizados desconocidos reciben la misma página.

Lo que sacamos de todo esto

• El orden forma parte de la corrección. Los mismos archivos subidos en otro orden son la diferencia entre un sitio roto y uno que funciona.
• Borra tarde, y solo lo que conoces. Eliminar con un listado tomado antes de la subida es seguro; vaciar una carpeta y esperar a que la subida termine no lo es.
• Cachea por versión, no por tiempo. Los tiempos de caducidad son una suposición sobre cuándo cambia el contenido. Una clave que cambia con la compilación es un hecho.

Relacionado: tu app publicada ahora sigue online mientras la republicas. Más sobre publicación en la documentación.