--- term: 'Backend (lado do servidor)' seoTitle: 'O que é Backend? Significado, Frontend vs. Backend, Arquitetura' headline: 'O que é um backend? O lado do servidor de uma aplicação, explicado' slug: backend category: backend-compute shortDefinition: '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.' relatedTerms: - baas-vs-custom-backend - api - serverless-architecture - backend-sdk - decoupled-architecture - scaling-application-backends contrastsWith: - decoupled-architecture faq: - question: 'O que significa backend?' answer: 'A parte de uma aplicação que os usuários nunca veem: o código do lado do servidor, o banco de dados e a infraestrutura que recebem as requisições da interface, aplicam as regras de negócio, leem e escrevem dados e devolvem uma resposta. Se o frontend é o painel de um carro, o backend é o motor e o sistema de combustível — invisível do banco do motorista, responsável por tudo que se move.' - question: 'O que é um frontend?' answer: 'A parte de uma aplicação que os usuários veem e com a qual interagem: as telas, os botões, os formulários e a navegação renderizados no dispositivo deles por um navegador ou por um app mobile. É a camada de apresentação. Ela captura a entrada e mostra os resultados, mas as decisões e os dados por trás desses resultados vivem no backend, que o frontend alcança por meio de uma API.' - question: 'Qual é a diferença entre frontend e backend?' answer: 'Onde o código roda e com quem ele fala. O frontend roda no dispositivo do usuário — navegador ou app — e renderiza telas, captura entrada e chama APIs. O backend roda em servidores que você (ou uma plataforma) controla e é dono dos dados, das regras e da segurança. Os dois se encontram em uma API: o frontend pergunta, o backend decide e responde.' - question: 'Backend é a mesma coisa que servidor?' answer: 'Não exatamente. Um servidor é uma máquina ou um processo que responde a requisições de rede; o backend é o sistema inteiro por trás da interface — código da aplicação, banco de dados, autenticação, jobs em segundo plano e os servidores em que tudo isso roda. Um backend pode se espalhar por muitos servidores, e em arquiteturas serverless o "servidor" é alugado por milissegundo e nunca gerenciado diretamente.' - question: 'Quais são os tipos de backend?' answer: 'Agrupados por quem executa os servidores: backends com servidores, em que seu time provisiona e opera máquinas ou containers; backends serverless, em que um provedor executa a infraestrutura e cobra por uso — Function as a Service para código próprio e Backend as a Service para a stack inteira; e backends descentralizados, em que nenhuma parte única opera o sistema e os pares compartilham estado por uma rede. A maioria dos produtos hoje combina os dois primeiros.' - question: 'Banco de dados é backend?' answer: 'Não — é um componente de um backend, geralmente o mais importante. Um banco de dados armazena e recupera dados; o backend o envolve com uma API, validação, permissões e lógica para que os clientes nunca o toquem diretamente. Uma plataforma que expõe um banco de dados por APIs geradas, com auth e regras de acesso, é um backend; um banco de dados sozinho não é.' - question: 'O que é Backend as a Service (BaaS)?' answer: 'Um backend gerenciado que você configura em vez de construir: banco de dados hospedado, APIs REST e GraphQL geradas automaticamente, autenticação de usuários, armazenamento de arquivos, push notifications e funções serverless para a lógica própria. Você continua escrevendo o frontend e as regras que importam para o seu produto; a plataforma executa o resto. É o caminho mais rápido para ter um backend de produção para um app mobile ou web.' - question: 'O que faz um desenvolvedor backend?' answer: 'Projeta o modelo de dados, constrói e documenta as APIs, implementa a lógica de negócio e os jobs em segundo plano, protege autenticação e permissões e mantém o sistema rápido e disponível conforme o tráfego cresce. Na prática, uma parcela grande do trabalho é operação — deploys, monitoramento, escala, backups — que é exatamente a parcela que as plataformas gerenciadas absorvem.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Introduction to the server side — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction' - name: 'Client-Server overview — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview' - name: 'RFC 9110 — HTTP Semantics' url: 'https://www.rfc-editor.org/rfc/rfc9110' - name: 'The Twelve-Factor App' url: 'https://12factor.net/' - name: 'Frontend and backend — Wikipedia' url: 'https://en.wikipedia.org/wiki/Frontend_and_backend' cta: title: 'Um backend de produção, sem construir um' text: 'O Back4app dá ao seu app banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções de Cloud Code desde o primeiro dia — o lado do servidor inteiro, configurado em vez de construído.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-19' translationKey: backend-meaning --- **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 | Pergunta | Resposta | | --- | --- | | A definição | Tudo por trás da interface: código de servidor, banco de dados, auth, jobs, infraestrutura | | A fronteira | Uma API — o frontend pede, o backend valida, decide e responde | | As camadas | API · lógica de negócio · dados · autenticação · trabalho em segundo plano · infraestrutura | | Os modelos de hospedagem | Com servidores · serverless (FaaS e BaaS) · descentralizado | | O padrão de 2026 | Alugue as partes genéricas (banco de dados, auth, APIs); escreva só a lógica que é sua | ## 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: ```text 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:** ```javascript // 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 // Flutter / Dart — Back4app Flutter SDK // The frontend asks the backend a question; the backend answers from the database final query = QueryBuilder(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'); ``` **Swift:** ```swift // 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") } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The frontend asks the backend a question; the backend answers from the database val query = ParseQuery.getQuery("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: | | Frontend | Backend | | --- | --- | --- | | Onde roda | O dispositivo do usuário: navegador, app mobile, desktop | Servidores que você ou um provedor controla | | Do que é dono | Layout, interação, estado local, acessibilidade | Dados, regras de negócio, identidade, segurança | | Como falha | Uma tela quebrada para um usuário | Dados errados ou indisponibilidade para todos os usuários | | Linguagens típicas | JavaScript/TypeScript, Swift, Kotlin, Dart | JavaScript/TypeScript, Python, Java, Go, C#, Ruby, PHP, Rust | | O que "pronto" significa | Parece e funciona bem | Está correto, seguro e continua rápido sob carga | | Quem vê o código | Qualquer um — ele é enviado ao dispositivo | Só o seu time — ele nunca sai do servidor | 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](/glossary/pt/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. ```mermaid flowchart LR accTitle: Frontend, backend e a API entre eles accDescr: Um frontend no dispositivo do usuário envia requisições por uma API ao backend, que contém lógica de negócio, autenticação e jobs em segundo plano, e fala com um banco de dados e serviços externos antes de devolver uma resposta. F["Frontend
(navegador, app mobile)"] -->|"requisição pela API"| B["Backend
lógica · auth · jobs"] B --> D[("Banco de dados")] B --> S["Serviços externos
(pagamentos, e-mail, IA)"] B -->|"resposta"| F ``` ## 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](/glossary/pt/api-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](/glossary/pt/nosql-vs-sql/) e o código que o modela, consulta e migra. - **Autenticação e autorização** — [quem está chamando e o que pode fazer](/glossary/pt/autenticacao-vs-autorizacao/), aplicado em toda requisição. - **Trabalho em segundo plano** — [jobs e agendamentos](/glossary/pt/jobs-em-segundo-plano/) 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](/glossary/pt/escalabilidade-de-backend/). 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](/glossary/pt/microsservicos-vs-monolito/); o modelo de operação é o mesmo. **Backends serverless.** Um provedor executa a infraestrutura e cobra por uso. Dois sabores: [Function as a Service](/glossary/pt/arquitetura-serverless/), 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](/glossary/pt/modelos-de-servico-em-nuvem/). **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 | Modelo | Quem executa os servidores | Você escreve | Escala por | Melhor para | | --- | --- | --- | --- | --- | | Com servidores | Seu time | Tudo: app, camada de dados, operação | Capacidade adicional que você gerencia | Requisitos incomuns, controle total, times de operação existentes | | Serverless (FaaS) | O provedor | Funções e a camada de dados | Invocação, a partir do zero | Lógica orientada a eventos, tráfego com picos, times pequenos | | BaaS | O provedor | Só frontend + lógica própria | Uso, gerenciada pela plataforma | Apps mobile e web que precisam de auth, dados e APIs rápido | | Descentralizado | Uma rede de pares | Smart contracts, clientes | Crescimento da rede | Sistemas de confiança minimizada, estado público compartilhado | ## 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 | Sua situação | Use | | --- | --- | | Um produto mobile ou web novo que precisa de auth, dados e APIs esta semana | BaaS — configure os 80% genéricos, escreva os 20% que são seus | | Lógica orientada a eventos com tráfego em rajadas e sem base estável | Funções serverless | | Requisitos estritos que as plataformas gerenciadas não conseguem expressar | Com servidores, usando containers e um plano de operação de verdade | | Um sistema cujo sentido inteiro é que ninguém o opere | Descentralizado | | Um backend com servidores já existente e lento para mudar | Mova primeiro as partes genéricas para um [backend gerenciado](/glossary/pt/baas-vs-backend-proprio/), mantenha o núcleo próprio | ## 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](/glossary/pt/vendor-lock-in-na-nuvem/) 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](/glossary/pt/permissoes-de-classe-clp/) fazem valer quem pode fazer o quê em toda requisição, o [Cloud Code](/glossary/pt/cloud-code-funcoes-serverless/) 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](/glossary/pt/sdk-de-backend/) que a enviaram são como o frontend fala com esse backend em todas as principais plataformas.