Seu app publicado agora continua no ar enquanto você o republica

Quando você republica um app no Mythex, seu site ativo continua servindo a versão anterior até o novo build ficar pronto, e só então troca. Antes desta mudança, uma republicação tirava o site do ar durante todo o build: os visitantes viam “Este app publicado está offline ou o link não foi encontrado” por um minuto mais ou menos, e depois a mesma página voltava a funcionar ao recarregar. Também corrigimos duas outras formas de um app ativo parecer indevidamente offline.

1. Republicar não derruba mais o seu site

Por trás dos panos, cada app publicado tem um registro que diz qual build servir. Uma republicação reaproveitava esse registro e o marcava como “em build” durante todo o processo, e a parte da nossa borda que roteia os visitantes só servia registros marcados como “ativos”. Assim, toda republicação fazia o site desaparecer até o build terminar. Reproduzimos isso em um app de teste pequeno: cerca de 50 segundos offline a cada republicação.

Agora, quando uma republicação começa em um app que já está ativo, o registro lembra que existe um build anterior e continua apontando para ele. A borda serve esse build anterior enquanto o novo é construído, e o ponteiro só passa para o novo build quando ele dá certo. Se o novo build falhar, seus visitantes nunca percebem: a versão antiga simplesmente continua no ar.

Uma primeira publicação, ou a republicação de um app que estava pausado ou despublicado, ainda só vai ao ar quando o build termina, porque não há versão anterior para mostrar.

2. Um pequeno soluço não parece mais “não encontrado”

O serviço na frente do seu app publicado pergunta à nossa API onde fica cada site. Antes, ele tratava qualquer resposta sem sucesso (um erro momentâneo do servidor, uma conexão perdida) como “este site não existe” e mostrava a página de offline. Um recarregamento um segundo depois funcionava, o que deixava tudo confuso.

Agora só uma resposta real de “não encontrado” conta como não encontrado:

• Qualquer outra falha é tentada de novo uma vez.
• Se ainda falhar, a borda serve o site a partir da última resposta conhecida como boa, por até uma hora.
• Só se nunca tiver recebido uma resposta é que mostra uma página de “temporariamente indisponível”, nunca “não encontrado”.

Domínios personalizados também consultam nossos sistemas de produção e de homologação em paralelo, então um servidor de homologação lento nunca consegue segurar um domínio de produção.

3. Um app pausado diz que está pausado

Apps publicados usam o seu saldo de créditos. Se o saldo acabar, o app é pausado até você recarregar, e volta sozinho quando você faz isso. Mas um app pausado parecia exatamente igual a um app excluído.

Agora, quem visita um app pausado vê “Este app está pausado”, com um caminho de volta para o dono, e a resposta nunca fica em cache, então o app fica acessível de novo no instante em que for retomado. Se um app estiver indisponível por outro motivo, os visitantes veem “Este app não está disponível”, sem que lhes digam o motivo.

Por que isso importa

Um app publicado é algo que você compartilhou: em um link da bio, em um cartão de visita, com seus primeiros clientes. Ele deve se comportar como um site de verdade: continuar no ar enquanto você melhora, sobreviver a um soluço e ser honesto quando estiver pausado.

Mais sobre publicação na documentação: como publicar e limites de hospedagem. E o lado da infraestrutura da mesma ideia: como chegamos a zero erros 502 nos nossos deploys.