Quatro cliques até ficar online. Trinta segundos, do início ao fim. Uma aplicação com suporte de servidor online por conta no plano gratuito. Meio segundo de latência extra apenas no primeiro pedido que um subdomínio novo alguma vez atende, e nenhum depois disso. Três destes números são curiosidades — do tipo que se acena e se esquece no capítulo seguinte. O "um", porém, é o número que realmente muda a forma como se deve trabalhar, por isso é aí que quero passar a maior parte deste capítulo.
Porque é que o limite é um, e não zero nem ilimitado
A maioria das ferramentas sem código que permitem publicar um frontend de graça, ou não tocam de todo em aplicações com suporte de servidor, ou limitam-nas tão severamente que "grátis" é apenas uma formalidade. Aqui, uma construção com contas, uma base de dados ou estado multiutilizador é publicada através do mesmo botão Publicar de uma página estática, e o lado do servidor é alojado e gerido como parte dessa mesma ação — sem provisionamento separado de base de dados, sem variáveis de ambiente para configurar, sem descobrir três dias depois que o início de sessão funciona na pré-visualização mas dá erro 500 em produção porque o backend nunca chegou a implementar-se. Isso é real, e é por isso que as pessoas ficam surpreendidas ao atingir o limite: até esse ponto, tudo parecia ilimitado.
Não é. Tem exatamente uma aplicação com suporte de servidor online de cada vez no plano gratuito. As construções estáticas não contam para esse limite — publique quantas páginas de marketing e sites de portefólio quiser, sem restrições aí. Mas a segunda construção que precise da sua própria base de dados ou processo persistente tem de esperar a sua vez, ficando totalmente construída e pronta a pré-visualizar, apenas sem estar online no seu endereço. Se estiver a prototipar três ideias de SaaS na mesma semana, só uma pode ocupar computação real; as outras duas são produtos acabados sem morada. Considero que o limite está definido num ponto razoável — um pacote estático custa quase nada à plataforma para servir na periferia, um processo de servidor ativo já não — mas isso significa que a decisão sobre qual ideia merece o lugar tem de ser tomada antes de clicar em Publicar, não depois de já se ter ficado apegado a ter duas online ao mesmo tempo.
Os quatro cliques, para que fique registado
- No cartão da construção, escolha Publicar.
- Escolha um nome de subdomínio — o oseuutilizador em
yourname.buildmidas.com. Nomes já ocupados sugerem alternativas. - Confirme.
- Copie o URL do cartão, ou encontre-o mais tarde na sua página Publicados.
Sem DNS, sem contas externas, sem espera pela propagação. E quanto a esse meio segundo: não é uma fila nem um atraso de "volte a verificar daqui a 24 horas", é apenas o aquecimento normal da cache da CDN. O primeiro visitante de um subdomínio novo pode notar um momento de latência extra enquanto o nó de periferia mais próximo obtém o pacote de recursos; o segundo visitante, e todos os seguintes, recebem-no já da cache. Na prática nem vai reparar — vai publicar, tocar na ligação, e já vai parecer instantâneo. Só o menciono porque alguém que tire capturas de ecrã de tempos de carregamento por profissão há de perguntar, mais cedo ou mais tarde, por que razão o primeiro pedido e o décimo não são idênticos, e agora já sabe.
O nome do subdomínio é a única decisão que vale a pena parar para pensar
Tudo o resto neste processo é mecânico; o nome do subdomínio é a parte que uma pessoa tem de dizer em voz alta ou escrever de memória, por isso vale a pena pensar um pouco. "demo-v2-final-final" serve para testes internos, mas é péssimo para enviar a um cliente por mensagem. Diga o URL em voz alta antes de confirmar — riverside-cafe.buildmidas.com lê-se bem, riverside-cafe-mvp2.buildmidas.com não. Palavras curtas e genéricas esgotam-se depressa numa plataforma que já existe há algum tempo, e é por isso que um nome já ocupado gera sugestões em vez de um simples erro. Aceite uma ou rejeite-a, mas decida propositadamente — já vi pessoas aceitarem o que a caixa sugeria a meio de uma demonstração, por precisarem de uma ligação imediatamente, e ficarem depois meses com um nome estranho porque nunca surgiu o momento certo para o corrigir.
Republicar não toca no que está online até se decidir
Eis um facto que vale a pena interiorizar desde já: editar uma construção publicada não altera o site online. Pode desfazer coisas, experimentar uma mudança de layout radical, iterar durante uma semana — o URL que um cliente já guardou nos favoritos continua a servir o que foi publicado por último, até publicar de novo, deliberadamente.
Essa é toda a sua história de recuperação, e é boa precisamente por ser aborrecida. A versão 6 é lançada com um erro — um formulário que deixa de submeter silenciosamente — e não é preciso recorrer a um comando de reversão nem a um pedido de suporte. Abre-se o histórico de versões, encontra-se a versão 5, republica-se. Mesmo botão, artefacto mais antigo, o URL online muda imediatamente. Depois corrige-se a versão 6 sem qualquer pressão, porque a produção não está avariada enquanto se trabalha. O custo disto é um clique extra por lançamento, já que é preciso lembrar-se de publicar de facto em vez de presumir que uma edição saiu automaticamente. Comparado com ferramentas em que cada gravação fica logo online — ótimo numa demonstração, complicado três semanas depois de uso real — o clique extra é uma troca que vale sempre a pena fazer.
Despublicar significa que o URL deixa de resolver, não "deixa de estar listado"
Muitas plataformas usam "despublicar" para significar ocultar de uma página de galeria, enquanto o URL continua discretamente a funcionar. Aqui significa que o endereço fica inativo, ponto final — sem página em cache, sem placeholder, nada resolve. A construção em si sobrevive com todas as versões intactas; republique mais tarde e o mesmo nome de subdomínio volta exatamente onde ficou. Já usei isto pela razão mais comum (uma colaboração com um cliente terminou e ninguém quer o logótipo antigo à solta numa ligação pública) e pela menos comum (uma construção divulgou algo que não devia, e precisava de ficar offline no tempo que leva a clicar num botão, não no tempo que leva a abrir um pedido junto de um fornecedor de alojamento). Ambas as situações querem a mesma garantia, e ambas a obtêm.
Mais uma coisa que vale a pena não confundir: publicar torna um URL acessível a qualquer pessoa com a ligação; se é descobrível — listado publicamente, por vezes destacado na Vitrina — é uma opção totalmente separada. Muitos sites publicados legítimos devem permanecer para sempre acessíveis apenas por ligação direta, e uma construção com a listagem pública ativada continua a ser, por baixo, um site publicado normal, com o mesmo histórico e o mesmo botão de despublicar.
