Tu app publicada ahora sigue activa mientras la vuelves a publicar

Cuando vuelves a publicar una app en Mythex, tu sitio en vivo ahora sigue sirviendo la versión anterior hasta que la nueva compilación está lista, y luego cambia. Antes de este cambio, volver a publicar dejaba el sitio offline durante toda la compilación: los visitantes veían «Esta app publicada está desconectada o no se encontró el enlace» durante un minuto más o menos, y después la misma página volvía a funcionar al recargar. También arreglamos otras dos formas en que una app en vivo podía parecer desconectada por error.

1. Volver a publicar ya no tumba tu sitio

Entre bastidores, cada app publicada tiene un registro que indica qué compilación servir. Volver a publicar reutilizaba ese registro y lo marcaba como «compilando» durante todo el proceso, y la parte de nuestra red de borde que enruta a los visitantes solo servía registros marcados como «en vivo». Así que cada republicación hacía desaparecer el sitio hasta que terminaba la compilación. Lo reprodujimos en una app de prueba pequeña: unos 50 segundos offline por republicación.

Ahora, cuando una republicación empieza en una app que ya está en vivo, el registro recuerda que existe una compilación anterior y sigue apuntando a ella. El borde sirve esa compilación anterior mientras se compila la nueva, y el puntero solo se mueve a la nueva cuando tiene éxito. Si la nueva compilación falla, tus visitantes no se dan cuenta: la versión anterior simplemente sigue activa.

Una primera publicación, o la republicación de una app que estaba pausada o despublicada, sigue saliendo en vivo solo cuando termina la compilación, porque no hay versión anterior que mostrar.

2. Un fallo breve ya no parece «no encontrado»

El servicio que está delante de tu app publicada pregunta a nuestra API dónde vive cada sitio. Antes, trataba cualquier respuesta no exitosa (un error momentáneo del servidor, una conexión caída) como «este sitio no existe», y mostraba la página de desconectado. Una recarga un segundo después funcionaba, lo que lo hacía confuso.

Ahora solo una respuesta real de «no encontrado» cuenta como no encontrado:

• Cualquier otro fallo se reintenta una vez.
• Si sigue fallando, el borde sirve el sitio desde la última respuesta buena conocida, durante hasta una hora.
• Solo si nunca ha tenido una respuesta muestra una página de «no disponible temporalmente», nunca «no encontrado».

Los dominios propios también consultan nuestros sistemas de producción y de staging en paralelo, así que un servidor de staging lento nunca puede retener un dominio de producción.

3. Una app pausada dice que está pausada

Las apps publicadas consumen tu saldo de créditos. Si se agota, la app se pausa hasta que recargas, y vuelve sola cuando lo haces. Pero una app pausada antes se veía exactamente igual que una borrada.

Ahora un visitante de una app pausada ve «Esta app está en pausa», con una forma de volver para el propietario, y la respuesta nunca se guarda en caché, así que la app vuelve a ser accesible en cuanto se reanuda. Si una app no está disponible por otro motivo, los visitantes ven «Esta app no está disponible», sin que se les diga por qué.

Por qué importa

Una app publicada es algo que has compartido: en un enlace de tu biografía, en una tarjeta de visita, con tus primeros clientes. Debe comportarse como un sitio web de verdad: seguir activa mientras la mejoras, sobrevivir a un fallo momentáneo y ser honesta cuando está pausada.

Más sobre publicación en la documentación: cómo publicar y límites de alojamiento. Y el lado de infraestructura de la misma idea: cómo llegamos a cero errores 502 en nuestros propios despliegues.