Módulo 1 · 1 de 7
Front-end, back-end e banco de dados
Leitura: ~3 min
Imagine a cena: reunião de kickoff de projeto. O tech lead abre a tela e começa a falar. "A gente vai precisar de uma API REST pra consumir os dados do back-end, o banco relacional já tá modelado, mas o servidor precisa escalar pra aguentar o volume de requisições." Você, designer, confirma com a cabeça. Anota algo no caderno. Talvez desenhe um quadrado com uma seta. Por dentro, o pensamento é um só: do que essa pessoa está falando?
Se você já viveu algo parecido, respira. Você não está sozinho(a), e esse módulo existe exatamente para isso. Não vou te transformar em programador(a), mas ao final dessa leitura, você vai entender o suficiente para participar dessa conversa de verdade. E mais: vai saber por que essas decisões técnicas afetam diretamente o design que você cria. E sempre que um termo escapar em qualquer página, o Glossário rápido tem a definição curta, sem julgamento.
O mundo por trás da tela
Vamos começar pelo básico. Quando você usa qualquer aplicativo ou site para pedir comida, checar o saldo no banco ou rolar o feed, existe uma estrutura inteira funcionando nos bastidores que você não vê. Essa estrutura tem três peças fundamentais: o front-end, o back-end e o banco de dados. E para essas peças conversarem entre si, elas usam um mensageiro chamado API.
Pense comigo: você conhece bem o front-end, mesmo que não saiba programar. O front-end é tudo aquilo que o usuário vê e toca. Os botões, as cores, a tipografia, as animações. É o seu território como designer. Mas o que acontece quando o usuário clica no botão "Buscar"? Para onde vai essa informação? De onde vem o resultado?
Um detalhe que muda tudo: o front-end roda no seu aparelho, dentro do navegador ou do app. O back-end roda em um computador da empresa, longe de você. Guarde essa separação: ela explica boa parte do que vem pela frente.
O back-end: a cozinha do produto digital
O back-end é onde a lógica do sistema vive. É ele que recebe o pedido do usuário, processa, consulta o banco de dados e devolve uma resposta. Você não vê o back-end, assim como não vê a cozinha de um restaurante quando está sentado(a) na mesa. Mas a qualidade do que chega no seu prato depende diretamente do que acontece lá dentro.
O back-end roda em um servidor, que nada mais é do que um computador potente, conectado à internet 24 horas, pronto para receber e responder pedidos. Quando alguém fala "o servidor caiu", significa que essa máquina parou de responder. E quando isso acontece, não importa o quão bonito seu layout seja: o usuário só vai ver uma tela de erro.
O banco de dados: o estoque do restaurante
Se o back-end é a cozinha, o banco de dados é o estoque. É lá que ficam guardados todos os dados: nomes de usuários, produtos, histórico de compras, senhas, tudo. As senhas, aliás, nunca ficam legíveis: entram no banco depois de passar por um hash, uma transformação irreversível. É como bater uma fruta no liquidificador: dá para fazer a vitamina, mas não dá para transformar a vitamina de volta em fruta. É por isso que "esqueci minha senha" te faz criar uma senha nova em vez de te mandar a antiga: nem o sistema consegue ler a original. Quando o sistema precisa de uma informação, o back-end consulta o banco de dados, pega o que precisa e monta a resposta.
Bancos de dados podem ser enormes. Pense em um e-commerce com milhões de produtos, cada um com nome, descrição, preço, fotos, avaliações. Tudo isso está no banco. E a velocidade com que o banco responde afeta diretamente a experiência, afeta o design. Se uma busca demora 8 segundos, não é o seu layout que está ruim. É o banco (ou a forma como ele está sendo consultado) que precisa de atenção.
Checagem rápida
Sem nota, sem pressão. Responda de cabeça e depois abra para conferir.
Um colega diz que o problema está "no back-end". O que isso provavelmente não é?
Não é o que o usuário vê e toca na tela, isso é o front-end. O back-end é a lógica e o processamento que rodam nos bastidores, fora da vista do usuário.
Por que a lentidão de um servidor (back-end) também é problema de design?
Porque ela vira experiência: uma resposta lenta pede estados de carregamento, feedback e bom tratamento de erro. O usuário não separa "servidor lento" de "app ruim", ele só sente a fricção.