00 · Produto
A engenharia por trás do WisyLink
Uma referência simples, seção a seção, sobre como o produto é concebido, o que pode e não pode fazer, como se mantém fiável e como é suportado.
Sem nomes de fornecedores. Sem métricas inventadas.
01 · Arquitetura
Como é realmente construído
Cada site é um backend real e independente — não é um modelo partilhado. Eis o que isto significa por baixo.
A sua própria capacidade de computação, não a partilhada
Cada site que constróis funciona com a sua própria capacidade de computação dedicada — nunca partilha um runtime com o código de outro site. Um problema num site não tem caminho para o de outro.
Um backend real desde a primeira construção
Cada site recebe o seu próprio banco de dados e armazenamento de ficheiros, e — quando precisa deles — contas reais, pagamentos e canais ao vivo, integrados desde o primeiro dia em vez de acrescentados mais tarde.
Um pipeline de construção multiagente que não requer nada para ter acesso
O processo de construção é um pipeline coordenado de agentes especializados, com uma camada de orquestração acima deles — e nenhum deles possui acesso permanente à sua conta, às suas credenciais, aos dados de qualquer outro site, ou às variáveis de ambiente e à configuração interna da plataforma. Mesmo uma instrução manipulada só pode afetar o único site que já está a ser trabalhado.
Cada requisição é verificada antes de ser executada
Uma requisição não assinada ou forjada nunca chega ao código do seu site — é rejeitada na porta de entrada, antes de qualquer computação começar.
Servido a partir de uma rede global, mantida atualizada automaticamente
As páginas são servidas a partir de uma rede global próxima dos seus visitantes. Uma nova construção fica disponível em segundos; uma alteração de dados chega aos visitantes em cerca de um minuto — sem qualquer passo manual.
As implantações são tudo ou nada
Uma nova versão substitui totalmente a anterior, ou não é publicada. Não existe estado em que os visitantes acedem a um site parcialmente atualizado.
02 · Escopo
O que faz — e o que não faz
O que é produzido é um produto real, de produção — construído dentro de um ambiente ao vivo, totalmente isolado, seguro, coordenado através de várias camadas de orquestração e agentes especializados. Eis exatamente o que isso inclui, e onde estão os limites intencionais.
O que está incluído
Uma aplicação web real hospedada
Páginas renderizadas no servidor no seu próprio domínio, com conteúdo visível aos motores de busca desde o primeiro byte — não é uma maquete estática.
Um backend funcional, não apenas um front-end
Armazenamento de dados, uploads de ficheiros, e — quando o site precisar deles — contas reais, pagamentos e atualizações em tempo real, já integrados.
O seu próprio endereço
Um subdomínio hospedado por defeito, ou o seu próprio domínio personalizado conectado ou adquirido através da plataforma.
Funciona continuamente enquanto o altera
Cada alteração passa pelo mesmo processo de construção isolado e, se funcionar, é publicada; caso contrário, mantém a versão anterior ativa.
Os limites intencionais
Nunca consome utilização faturável em seu nome sem aviso
Qualquer ação que consome utilização faturável além da franquia incluída no seu plano só é executada depois de a acionar explicitamente — nunca automaticamente, e nunca além do que aprovou.
Não guarda as suas contas de terceiros
Processadores de pagamentos, e-mail e qualquer outro serviço que conecte são configurados com as suas próprias credenciais, criptografadas em repouso e apenas legíveis pelo código do seu site.
O uso tem um teto, e esse teto é aplicado, não presumido
Armazenamento, banco de dados e largura de banda são medidos continuamente e limitados por conta — um limite é aplicado no momento em que é atingido, nunca retroativamente.
Cria back-ends web reais, não binários da App Store
O que constróis é uma aplicação web, acessível a partir de qualquer navegador e de qualquer dispositivo — não é uma aplicação compilada submetida à App Store.
03 · Engenharia de fiabilidade
Projetado para manter-se online, não apenas para lançar
Nenhuma plataforma é imune a falhas. O que importa é o quão grave é a falha que ela tolera e quão rapidamente se recupera.
Falha contida
Como cada site funciona na sua própria infraestrutura de computação, uma falha ou pico de tráfego num site não pode derrubar outro site.
Uma build com falha nunca chega aos visitantes
Se uma nova versão não é concluída com sucesso, o site continua a funcionar na última que o fez — fiabilidade aqui significa que nada é enviado a meio.
Abuso absorvido antes de o atingir
O tráfego passa por uma camada global protetora antes de chegar a qualquer infra de computação — abusos de alto volume são detidos antes de se tornarem num problema para o seu site.
Contabilidade de recursos sem condições de corrida
Os limites de uso são aplicados como parte da mesma operação de escrita que os consome, na própria camada de dados — não por uma verificação separada que possa atrasar-se ou contar o dobro.
Nenhuma janela de manutenção partilhada
Cada site é implementado e atualizado de forma independente, por isso não existe uma janela de manutenção a nível de plataforma que coloque todos os sites offline de uma vez.
04 · Histórico de desenvolvimento
Como é que a arquitetura chegou a este ponto
A plataforma não chegou a este design por acaso — chegou aqui em etapas deliberadas.
Fundação
Um backend por site
A decisão central: cada site tem o seu próprio backend real na sua própria infraestrutura de computação, com o seu próprio banco de dados — não linhas num aplicativo de outra pessoa.
Endurecimento
Garantir o caminho das requisições
Cada requisição para a computação de um site passou a ser exigida por assinatura criptográfica, de modo que uma requisição não assinada ou forjada é rejeitada antes de custar qualquer processamento.
Isolamento
Removendo privilégios do agente de build
O processo de build de IA foi movido para ser executado sem permissões permanentes — o acesso a segredos e à infraestrutura foi removido na fonte, não filtrado depois.
Hoje
Entrega instantânea orientada por eventos
A invalidação de cache passou de depender de um temporizador para disparar no momento em que algo muda — uma nova build ou uma gravação de dados chega aos visitantes quase imediatamente.
05 · Suporte
Como os pedidos de apoio são tratados
Envie uma questão ou pedido de suporte através do canal de contacto — é o que acontece assim que chegar.
Cada relatório é recebido no momento em que chega
Uma questão submetida entra no sistema de imediato e é triada sem atraso — nada fica numa fila à espera.
A maioria dos problemas técnicos é resolvida autonomamente
O sistema investiga o problema relatado e, na maioria dos casos, resolve-o por conta própria — e continua a monitorizar depois para confirmar que permanece resolvido.
Se precisar de intervenção humana, entraremos em contacto consigo diretamente
Quando um relatório requer uma resposta, entraremos em contacto o mais rapidamente possível — não fica numa fila de tickets.
Começa com uma mensagem
Cada passo acima começa no momento em que chega uma mensagem — envie uma dúvida ou pedido de suporte através do formulário de contacto e o processo começa de imediato.
Veja por si próprio
A prova mais rápida é uma prova real — descreva o que pretende e veja-o a ser construído.
De uma frase a uma aplicação em funcionamento.