O Que É um Servidor? Guia Simples para Criadores de Apps

Um servidor é um computador — ou um programa a correr num computador — que aguarda pedidos e lhes responde. Quando abre um site, o seu navegador (o cliente) envia um pedido através da internet, e um servidor algures envia de volta a página, as imagens ou os dados. Todas as apps que usa, do email à banca online, dependem de servidores a fazer isto milhões de vezes por dia.

Porque é que os servidores importam quando cria com IA

Quando um construtor de IA lhe cria uma app, parte do código corre no navegador do visitante e parte normalmente corre num servidor. A parte do servidor faz as coisas em que o navegador não pode ser confiado ou que não consegue fazer sozinho:

• Guardar e carregar dados de uma base de dados.
• Guardar segredos, como chaves de API de pagamentos ou de fornecedores de IA, que nunca podem chegar ao navegador.
• Verificar permissões — garantir que um utilizador só vê e altera os seus próprios registos.
• Falar com outros serviços: cobrar um cartão, enviar um email, chamar um modelo de IA.

Saber o que o servidor faz ajuda-o a perceber onde as regras da sua app realmente vivem, porque algumas alterações exigem nova publicação, e o que está a pagar quando aloja uma app. Para a divisão entre as duas metades, veja frontend vs backend.

Uma analogia do dia a dia

Um servidor é como o funcionário do balcão de uma estação de correios. Não sai à procura de clientes; espera. Um cliente (o cliente do pedido) aproxima-se com um pedido — "enviar esta encomenda", "há correio para mim?" — e o funcionário trata do pedido e devolve um resultado. Um só funcionário pode atender muitos clientes, um a seguir ao outro, e uma estação movimentada abre mais balcões.

A estação de correios também tem regras que o cliente não pode contornar: tem de mostrar o documento de identificação para levantar uma encomenda. É esse o papel do servidor numa app — o navegador pode pedir o que quiser, mas o servidor decide o que recebe.

Como um pedido chega a um servidor

Quando alguém visita https://bookings.example.com/schedule:

1. Consulta DNS. O navegador pergunta ao sistema de nomes de domínio que endereço IP corresponde a bookings.example.com. Veja como funcionam os domínios e o DNS.
2. Ligação. O navegador liga-se a esse endereço, na porta 443 para HTTPS, e estabelece uma ligação encriptada. Veja o que é HTTPS.
3. Pedido. Envia um pedido HTTP: GET /schedule.
4. Trabalho. O servidor corre o código que trata de /schedule — talvez procurando as marcações de hoje na base de dados.
5. Resposta. Envia de volta um código de estado (200 OK) e o conteúdo — uma página HTML, ou dados JSON para a página apresentar.

Tudo isto costuma demorar uma fração de segundo.

Tipos de servidores que vai ouvir mencionar

Repare que "servidor" significa tanto a máquina como o programa. "O servidor caiu" pode querer dizer qualquer uma das duas coisas.

Um exemplo prático: uma app de marcações para um salão

Eis o que o servidor faz numa pequena app de marcações para um salão:

• Um visitante abre o site. O servidor (ou uma CDN à frente dele) envia os ficheiros da página.
• A página pede ao servidor GET /api/slots?date=2026-10-03. O servidor consulta a base de dados para os horários livres e devolve-os em JSON.
• O visitante marca as 14:00. A página envia POST /api/bookings. O servidor verifica se o horário continua livre — não confia na palavra do navegador — guarda a marcação e devolve 201 Created.
• O servidor chama um serviço de email com uma chave secreta, guardada no servidor, para enviar a confirmação.

Se desligasse o servidor, a página poderia continuar a carregar a partir de uma CDN, mas não conseguiria mostrar horários nem guardar marcações.

O que um servidor precisa para funcionar bem

• Memória (RAM) e CPU. Pouca memória e a app bloqueia sob carga; pouca CPU e fica lenta.
• Estar a correr. Um servidor desligado não consegue responder. Algumas plataformas põem as apps inativas em repouso e acordam-nas na visita seguinte, o que poupa dinheiro mas pode tornar o primeiro pedido mais lento.
• Configuração e segredos, fornecidos como variáveis de ambiente.
• Registos (logs) — o registo do servidor do que aconteceu, que é onde se olha primeiro quando algo falha.
• Atualizações e correções de segurança, que o alojamento gerido trata por si.

Equívocos comuns

• "A cloud significa não haver servidores." A cloud são os servidores de outras empresas, alugados à hora ou pelo uso.
• "Um servidor é um computador grande e especial." Qualquer computador pode funcionar como servidor. O seu portátil corre um quando abre localhost durante o desenvolvimento.
• "Se o botão estiver escondido, os utilizadores não o conseguem usar." Qualquer pessoa pode enviar pedidos diretamente ao seu servidor. As verificações de permissões têm de acontecer no servidor, e não apenas na página.
• "Mais servidores resolvem a lentidão." Muitas vezes a causa real é uma consulta lenta à base de dados ou uma API externa. Encontre primeiro o estrangulamento.
• "Preciso de gerir um servidor para ter uma app." As plataformas geridas tratam dos servidores por si; você implementa o código e elas tratam das máquinas.

O que pedir ao seu construtor de IA

• "Que partes desta app correm no servidor e quais correm no navegador?"
• "Mantenha todas as chaves de API no servidor e leia-as de variáveis de ambiente."
• "Verifique as permissões no servidor para cada pedido que leia ou altere dados."
• "Onde encontro os registos do servidor, e o que dizem sobre este erro?"
• "Esta app precisa mesmo de um servidor, ou pode ser um site estático?"
• "O que acontece ao primeiro pedido depois de a app ter estado inativa?"

Servidores na Mythex

Na Mythex não configura nem gere servidores. Enquanto constrói, a sua app corre numa sandbox de cloud privada para a pré-visualização em direto. Quando publica, a Mythex implementa-a: as interfaces estáticas como sites estáticos, e os backends (Node, Python, C#, Java e outros) como contentores construídos a partir de um Dockerfile — sem alojamento para configurar por si. A Mythex escolhe o tamanho da máquina ao implementar: por defeito 1 CPU e 512 MB de memória, com mais disponível mediante pedido (até 1 GB no Free, e até 2 CPUs, 4 GB e 3 máquinas no Pro). As apps publicadas entram em repouso quando inativas e acordam na visita seguinte, e uma app em repouso não gasta nada em computação. Os detalhes estão na documentação sobre backends de API e limites de alojamento, e o nosso guia sobre alojamento web cobre o panorama geral.

Perguntas