O que é um servidor? Um guia em linguagem simples para quem constrói apps

Um servidor é um computador — ou um programa rodando em um computador — que espera requisições e as responde. Quando você abre um site, o seu navegador (o cliente) envia uma requisição pela internet, e um servidor em algum lugar devolve a página, as imagens ou os dados. Todos os apps que você usa, de e-mail a internet banking, dependem de servidores fazendo isso milhões de vezes por dia.

Por que os servidores importam ao construir com IA

Quando um construtor de IA cria um app para você, parte do código roda no navegador do visitante e parte normalmente roda em um servidor. A parte do servidor faz o que o navegador não pode ser confiável para fazer ou não consegue fazer sozinho:

• Salvar e carregar dados de um banco de dados.
• Guardar segredos, como chaves de API de pagamento ou de IA, que nunca podem chegar ao navegador.
• Verificar permissões — garantindo que um usuário só veja e altere os próprios registros.
• Conversar com outros serviços: cobrar um cartão, enviar um e-mail, chamar um modelo de IA.

Saber o que o servidor faz ajuda a entender onde as regras do seu app realmente vivem, por que algumas mudanças exigem uma nova publicação e pelo que você paga ao hospedar um app. Para a divisão entre as duas metades, veja frontend vs. backend.

Uma analogia do dia a dia

Um servidor é como o atendente do balcão de uma agência dos Correios. Ele não sai procurando clientes; ele espera. Um cliente (o cliente) chega com um pedido — “quero enviar esta encomenda”, “tem correspondência para mim?” — e o atendente resolve e entrega o resultado. Um mesmo atendente pode atender muitos clientes um após o outro, e uma agência movimentada abre mais guichês.

A agência também tem regras que o cliente não pode contornar: você precisa mostrar documento para retirar uma encomenda. É esse o papel do servidor em um app — o navegador pode pedir qualquer coisa, mas o servidor decide o que recebe.

Como uma requisição 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 qual endereço IP bookings.example.com aponta. Veja como funcionam domínios e DNS.
2. Conexão. O navegador se conecta a esse endereço, na porta 443 para HTTPS, e estabelece uma conexão criptografada. Veja o que é HTTPS.
3. Requisição. Ele envia uma requisição HTTP: GET /schedule.
4. Trabalho. O servidor roda o código que trata /schedule — talvez buscando os agendamentos do dia no banco de dados.
5. Resposta. Ele devolve um código de status (200 OK) e o conteúdo — uma página HTML ou dados em JSON para a página exibir.

Tudo isso geralmente leva uma fração de segundo.

Tipos de servidor que você vai ouvir falar

Repare que “servidor” significa tanto a máquina quanto o programa. “O servidor caiu” pode se referir a qualquer um dos dois.

Um exemplo prático: um app de agendamento de salão

Veja o que o servidor faz em um pequeno app de agendamento de salão:

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

Se você desligasse o servidor, a página ainda poderia carregar a partir de uma CDN, mas não conseguiria mostrar horários nem salvar agendamentos.

O que um servidor precisa para funcionar bem

• Memória (RAM) e CPU. Pouca memória e o app trava sob carga; pouca CPU e ele fica lento.
• Estar rodando. Um servidor desligado não responde. Algumas plataformas colocam apps ociosos para dormir e os acordam na próxima visita, o que economiza dinheiro, mas pode deixar a primeira requisição mais lenta.
• Configuração e segredos, fornecidos como variáveis de ambiente.
• Logs — o registro do servidor do que aconteceu, que é onde você olha primeiro quando algo quebra.
• Atualizações e correções de segurança, que a hospedagem gerenciada cuida para você.

Ideias erradas comuns

• “Nuvem significa que não há servidores.” A nuvem são os servidores de outras empresas, alugados por hora ou por uso.
• “Servidor é um computador grande e especial.” Qualquer computador pode atuar como servidor. O seu notebook roda um quando você abre o localhost durante o desenvolvimento.
• “Se o botão está escondido, os usuários não conseguem fazer a ação.” Qualquer pessoa pode enviar requisições diretamente ao seu servidor. As verificações de permissão precisam acontecer no servidor, não apenas na página.
• “Mais servidores resolvem a lentidão.” Muitas vezes a causa real é uma consulta lenta ao banco de dados ou uma API externa. Encontre o gargalo primeiro.
• “Preciso gerenciar um servidor para ter um app.” Plataformas gerenciadas rodam os servidores para você; você implanta o código e elas cuidam das máquinas.

O que pedir ao seu construtor de IA

• “Quais partes deste app rodam no servidor e quais rodam no navegador?”
• “Mantenha todas as chaves de API no servidor e leia-as de variáveis de ambiente.”
• “Verifique as permissões no servidor em cada requisição que lê ou altera dados.”
• “Onde encontro os logs do servidor, e o que eles dizem sobre este erro?”
• “Este app precisa mesmo de um servidor, ou pode ser um site estático?”
• “O que acontece com a primeira requisição depois que o app ficou ocioso?”

Servidores no Mythex

No Mythex você não configura nem gerencia servidores. Enquanto constrói, o seu app roda em uma sandbox privada na nuvem para a prévia ao vivo. Quando você publica, o Mythex faz o deploy: front-ends estáticos como sites estáticos, e backends (Node, Python, C#, Java e outros) como contêineres construídos a partir de um Dockerfile — sem hospedagem para configurar. O Mythex escolhe o tamanho da máquina no deploy: por padrão, 1 CPU e 512 MB de memória, com mais disponível sob pedido (até 1 GB no plano Free, e até 2 CPUs, 4 GB e 3 máquinas no Pro). Apps publicados entram em repouso quando ociosos e acordam na próxima visita, e um app em repouso não gasta nada em computação. Os detalhes estão na documentação sobre backends de API e limites de hospedagem, e o nosso guia sobre hospedagem web cobre o panorama mais amplo.

Perguntas