O que é um backend? O lado do servidor de uma aplicação, explicado

Um backend é um sistema do lado do servidor: o código, o banco de dados e a infraestrutura que atendem às requisições de um app e guardam seus dados. Todo software com usuários tem duas metades. A metade que eles veem e tocam — telas, botões, formulários — é o frontend.

A metade que eles nunca veem, a que decide o que os botões podem fazer e lembra o que aconteceu depois que o app foi fechado, é o backend. A velha analogia do mecânico continua valendo: o motorista opera o painel, o mecânico opera o motor.

Este verbete é sobre o motor.

Principais pontos

Uma requisição, de ponta a ponta

A forma mais clara de ver um backend é acompanhar uma requisição atravessando-o. Um usuário toca em “mostrar minhas tarefas abertas”; isto é o que acontece do outro lado da API:

GET /classes/Todo?where={"done":false} HTTP/1.1    ← o frontend pede
Authorization: Bearer eyJhbGci…                     ← quem está pedindo

  backend ─┬─ camada de API       interpreta a requisição, confere o token
           ├─ autorização         este usuário pode ler estas linhas?
           ├─ lógica de negócio   aplica as regras (só as tarefas de quem chamou)
           ├─ camada de dados     consulta o banco de dados, molda o resultado
           └─ resposta            200 OK + JSON, em menos de 100 ms

{ "results": [ { "objectId": "xKd91m", "title": "Ship the release", "done": false } ] }

A mesma conversa vista do lado do frontend, por um SDK que a transforma em uma linha por plataforma:

// JavaScript / Node.js — Back4app JS SDK
// The frontend asks the backend a question; the backend answers from the database
const query = new Parse.Query('Todo');
query.equalTo('done', false);
const open = await query.find();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
console.log(`${open.length} open todos`);

// Flutter / Dart — Back4app Flutter SDK
// The frontend asks the backend a question; the backend answers from the database
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false);
final response = await query.query();
// Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
print('${response.results?.length ?? 0} open todos');

// iOS / Swift — Back4app Swift SDK
// The frontend asks the backend a question; the backend answers from the database
let query = Todo.query("done" == false)
query.find { result in
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if case .success(let open) = result { print("\(open.count) open todos") }
}

// Android / Kotlin — Back4app Android SDK
// The frontend asks the backend a question; the backend answers from the database
val query = ParseQuery.getQuery<ParseObject>("Todo")
query.whereEqualTo("done", false)
query.findInBackground { open, e ->
    // Under the hood: GET /classes/Todo?where={"done":false} → 200 OK + JSON
    if (e == null) println("${open.size} open todos")
}

Frontend vs. backend

A distinção que mais gente pesquisa, em uma tabela:

Essa última linha é a que importa para a segurança: qualquer coisa no frontend pode ser lida e modificada pelo usuário. É por isso que validação, permissões e segredos pertencem ao backend, e por isso toda chamada de API é tratada como não confiável até que o servidor a tenha verificado.

Lado do cliente e lado do servidor

Os dois termos não são dois tipos de backend; são as duas pontas de toda requisição. O lado do cliente é qualquer código que roda no dispositivo do usuário — renderizando a interface, guardando estado temporário, enviando requisições.

O lado do servidor é qualquer código que roda em máquinas que o usuário não alcança — recebendo essas requisições, executando a lógica de verdade, lendo e escrevendo no banco de dados e respondendo. “Backend” e “lado do servidor” são usados como sinônimos para essa segunda metade, e este verbete faz o mesmo.

Do que um backend é feito

O enquadramento clássico chama o frontend de camada de apresentação e o backend de camada de acesso a dados, e descreve o backend como três coisas trabalhando juntas: os recursos de hardware, o software que roda neles e a infraestrutura de rede entre eles e o usuário.

Isso continua verdadeiro, mas é mais útil ler um backend como uma pilha de responsabilidades, a maioria das quais existe em todo produto, independentemente do tamanho:

• Camada de API — o contrato público: endpoints REST ou GraphQL que o frontend e outros sistemas chamam.
• Lógica de negócio — as regras que fazem o produto ser o produto: o que é um pedido válido, quem pode aprovar o quê, como uma pontuação é calculada.
• Camada de dados — o banco de dados e o código que o modela, consulta e migra.
• Autenticação e autorização — quem está chamando e o que pode fazer, aplicado em toda requisição.
• Trabalho em segundo plano — jobs e agendamentos para tudo que não deveria bloquear uma requisição: e-mails, relatórios, sincronizações, limpezas.
• Infraestrutura — os servidores, containers ou funções em que tudo roda, mais deploy, logging, monitoramento, backups e escalabilidade.

As cinco primeiras são trabalho de produto. A sexta é operação, e é a parte que os modelos modernos de hospedagem existem para eliminar.

Arquiteturas de backend

A versão original deste tema descrevia três famílias — serverless, orientada a servidores e descentralizada — e a taxonomia continua de pé. O que mudou foi o padrão: em 2026 a família serverless é onde a maioria dos produtos novos começa, e “orientada a servidores” significa cada vez mais containers em vez de máquinas.

Backends com servidores. Seu time provisiona máquinas, máquinas virtuais ou containers, instala um runtime e um banco de dados e os opera. Máximo controle, máxima responsabilidade: capacidade, patches, disponibilidade e a escala de plantão são seus.

Os argumentos clássicos a favor continuam valendo — um único lugar que compartilha dados entre várias aplicações, integrações diretas, um único ponto de acesso para proteger — e o formato por dentro pode ser um monolito ou microsserviços; o modelo de operação é o mesmo.

Backends serverless. Um provedor executa a infraestrutura e cobra por uso. Dois sabores: Function as a Service, em que você implanta código próprio como funções que escalam a partir do zero, e Backend as a Service, em que banco de dados, auth, APIs, storage e funções chegam como uma plataforma gerenciada.

O ganho é velocidade — nenhum servidor para montar antes da primeira funcionalidade — e a troca é o controle sobre as camadas mais baixas. A escada completa de modelos de hospedagem é comparada em IaaS vs. PaaS vs. BaaS vs. FaaS.

Backends descentralizados. Nenhum operador único; o estado vive em uma rede peer-to-peer, geralmente open-source, como em blockchains e armazenamento endereçado por conteúdo. Bitcoin e Ethereum são os exemplos canônicos, e o frontend de um app assim costuma ser hospedado do mesmo jeito, em redes como IPFS ou Swarm em vez de em um servidor.

Resistência à censura e nenhum ponto central de controle, ao custo de latência, throughput e um modelo de programação muito diferente. Um nicho com usos reais, não um substituto de uso geral para os outros dois.

Com servidores vs. serverless vs. BaaS vs. descentralizado

Casos de uso comuns

• Apps mobile e web — contas, dados que sobrevivem à sessão e sincronização entre dispositivos precisam de um lado do servidor.
• Produtos multiusuário — qualquer coisa em que a ação de um usuário precisa ser vista por outro: colaboração, marketplaces, chat.
• Pagamentos e operações sensíveis — segredos e dinheiro nunca pertencem ao dispositivo; o backend guarda as chaves e fala com os provedores.
• Integrações e automação — webhooks, jobs agendados e pipelines que rodam com ou sem usuário online.
• Recursos de IA — chamadas de modelo, retrieval e execução de ferramentas rodam no servidor, onde as chaves ficam privadas e os resultados podem ser cacheados e auditados.

Qual abordagem de backend você deveria escolher? Matriz de decisão

Limitações e trade-offs

• O backend é onde os erros viram problema de todo mundo. Um bug no frontend quebra uma tela; um bug no backend corrompe dados ou os expõe. Validação, permissões e testes pesam mais aqui do que em qualquer outro lugar da base de código.
• A operação nunca desaparece — ela se move. Plataformas gerenciadas absorvem servidores, escala e backups, mas alguém continua dono do modelo de dados, das regras de acesso e do orçamento. Escolha um modelo pelas responsabilidades que você quer manter, não pelas que quer esquecer.
• Controle e velocidade puxam em direções opostas. Quanto mais da stack você mesmo roda, mais pode customizar e mais tempo tudo leva; quanto menos roda, mais rápido entrega e mais depende do roadmap e do preço de um provedor.
• A rede faz parte do contrato. Toda chamada do frontend ao backend pode ser lenta, falhar no meio ou chegar duas vezes; orçamentos de latência, retries e idempotência são preocupações de backend desde o primeiro endpoint.
• “Serverless” ainda tem servidores. Cold starts, limites de execução e cobrança por uso são restrições reais; são apenas máquinas de outra pessoa com uma curva de custo diferente.

O backend no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code.

Mapeado nas camadas acima: a camada de dados e a camada de API são geradas a partir do seu modelo de dados, a autenticação e as permissões por classe fazem valer quem pode fazer o quê em toda requisição, o Cloud Code guarda a lógica de negócio e os jobs em segundo plano que são específicos do seu produto, e a camada de infraestrutura — hospedagem, escala, backups, monitoramento — é trabalho da plataforma.

A requisição dissecada no topo desta página é o formato real do fio no Back4app, e os SDKs que a enviaram são como o frontend fala com esse backend em todas as principais plataformas.