Por que existem o frontend e o backend como coisas separadas
Publicado em 2026-09-12 por frfrand
No es una moda ni una forma de dividir tareas: son dos entornos con reglas incompatibles. Qué corre en cada lado, por qué nunca hay que confiar en el navegador y dónde va cada validación.
Muitas pessoas ouvem "frontend e backend" e entendem como uma divisão do trabalho: alguns fazem o visual e outros a lógica. É verdade como descrição de papéis, mas fica aquém e leva a decisões equivocadas.
A separação real é mais profunda: são dois ambientes com propriedades incompatíveis.
A diferença que explica tudo
O frontend roda na máquina de outra pessoa.
É só isso. Dali vem o resto.
O código que você envia ao navegador está nas mãos do usuário: ele pode lê-lo, modificá-lo, executá-lo manualmente ou simplesmente ignorá-lo e enviar requisições com outra ferramenta. Não há como impedir isso, pois, para funcionar, o navegador precisa entender o que você enviou.
O backend roda no seu servidor, onde você controla quem entra e o que é executado.
Por isso, qualquer coisa que precise ser verdadeira tem que ser decidida no backend.
A consequência prática
Um exemplo que se repete: um formulário que valida que a idade seja maior que 18. Ele é validado no frontend para que o usuário receba o aviso imediatamente, sem esperar pelo servidor. Perfeito.
E também precisa ser validado no backend. Não por desconfiança nesse usuário: porque a requisição pode chegar sem passar pelo seu formulário.
A regra curta: validar no frontend é uma cortesia, validar no backend é a regra.
O mesmo vale para preços, permissões, estoque e descontos. Se o navegador enviar "preço: 0", o servidor tem que ignorar esse dado e buscar o preço real.
Qué vive en cada lado
Frontend: estructura visual, estilos, interacciones, validaciones inmediatas, estado de la interfaz, animaciones.
Backend: reglas de negocio, permisos, acceso a la base de datos, integraciones con servicios externos, secretos.
Esa última palabra merece énfasis. Las claves de API, las credenciales de la base y los tokens de servicios pagos no pueden estar en el frontend. Ni siquiera "ofuscados": todo lo que llega al navegador es visible.
El límite entre los dos: la API
La conversación pasa por una interfaz explícita, normalmente HTTP con JSON.
Esa frontera clara es lo que permite que el mismo backend atienda a una web, a una aplicación móvil y a un proceso automático. Y que el equipo de frontend rediseñe todo sin tocar la lógica de negocio.
También es donde conviene ser estricto: la API debería aceptar exactamente lo que necesita y rechazar el resto, con mensajes de error claros. Una API permisiva es cómoda el primer mes y una fuente de bugs para siempre.
Cuándo la separación estorba
Vale decirlo, porque la industria a veces exagera. Para un sitio de contenido, separar en un frontend que consume una API puede ser trabajo extra sin beneficio: el servidor devuelve HTML ya armado y listo.
La separación se paga sola cuando hay varias interfaces contra el mismo backend, cuando los equipos son distintos, o cuando la interfaz es muy interactiva. Para un blog, no.
Dónde vive cada cosa en un servidor
Na prática, os dois terminam na mesma máquina com mais frequência do que se imagina: o nginx serve os arquivos estáticos do frontend e, quando o caminho começa com /api, ele encaminha a requisição para o backend que está escutando em uma porta local.
No ArduMaker, essa divisão é configurada a partir do painel: um repositório pode ser implantado como site estático e outro como serviço, cada um com seu domínio ou caminho, no mesmo VPS ou em VPSs diferentes.