O Que Roda no Cliente e no Servidor

O problema

Arquiteturas de frontend costumam virar bagunca quando o time mistura responsabilidades de cliente e servidor sem critério claro.

Daqui a pouco, tem fetch dentro de componente que nem deveria saber disso, regra de negócio vazando para o navegador e o cliente recalculando trabalho que o servidor poderia ter enviado pronto.

O resultado e uma base mais lenta, mais fragil e mais cansativa de manter.

Modelo mental

Cliente e servidor não sao só lugares diferentes.

Eles tem papeis diferentes:

• O servidor busca dados, valida regras duras, protege segredos e prepara a verdade pesada.
• O cliente lida com interação imediata, estado local, clique, digitação e resposta rápida da interface.

Quando essa divisao fica clara, a decisão de arquitetura fica bem mais simples.

Também fica mais fácil evitar duas dores classicas ao mesmo tempo:

• navegador fazendo trabalho demais
• regra sensivel vazando para onde não devia

Quebrando o problema

Antes de decidir onde uma lógica roda, responda isto:

1. Essa lógica precisa de segredo de API, acesso direto ao banco ou checagem forte de permissao?
2. Essa lógica depende de clique, digitação ou feedback visual imediato?
3. Essa transformação pesada poderia acontecer no backend para o navegador não fazer esse trabalho?
4. Essa regra de negócio realmente precisa aparecer no bundle do cliente?

Essas perguntas evitam misturar ambientes por conveniencia.

Elas também ajudam a fugir de uma armadilha comum: decidir onde o código vai morar só porque o componente já estava aberto na tela.

Exemplo simples

Imagine um dashboard que mostra pedidos recentes e deixa o usuário filtrar por status.

Uma divisao limpa fica assim:

• O servidor busca os pedidos, formata datas e envia um payload inicial pronto.
• O cliente recebe a lista, guarda selectedFilter e atualiza a tela quando o usuário interage.

O erro comum e jogar tudo no cliente: buscar linha bruta, formatar dado, aplicar regra de negócio e ainda renderizar a interface.

Isso aumenta custo de CPU no navegador e apaga a fronteira de quem deveria fazer o que.

Outro exemplo comum e permissao.

Você pode esconder um botao no cliente para melhorar UX.

Mas a autorização real continua precisando morar no servidor. Se a regra sensivel existe só no navegador, ela não esta protegendo nada de verdade.

Erros comuns

• Empurrar para o navegador transformações de dados que o servidor resolveria melhor.
• Deixar segredo de API ou regra sensivel perto demais do cliente.
• Tratar um app React interativo como desculpa para fazer o cliente cuidar de tudo.
• Decidir onde o código mora pela conveniencia do arquivo aberto, e não pela responsabilidade arquitetural.

Outro erro recorrente e mandar dado cru demais para o cliente e esperar que cada tela reconstrua a versão útil sozinha. Isso costuma espalhar regra e duplicar trabalho.

Como um senior pensa

Quem tem mais experiência não começa perguntando “em qual arquivo eu coloco essa função?”.

Pergunta isto:

“De que lado da rede essa responsabilidade deve morar para a interface continuar rápida, segura e simples?”

Essa pergunta melhora performance, segurança e manutenção ao mesmo tempo.

Senioridade aqui aparece em pensar na fronteira como decisão de responsabilidade, não só como detalhe de framework.

O que o entrevistador quer ver

Em entrevista de system design frontend, isso mostra maturidade rápido.

• Você entender que cliente e servidor trabalham juntos, mas com papeis diferentes.
• Você justificar por que uma lógica pertence a um lado e não ao outro.
• Você priorizar segurança, simplicidade de rede e menos custo no navegador.

Uma resposta forte costuma soar assim:

“Eu tento deixar no servidor tudo que depende de segredo, permissao forte, banco ou transformação pesada. No cliente, eu deixo o que precisa responder rápido a clique, digitação e estado local. Isso reduz bundle, evita vazamento de regra e simplifica a interface.”

O cliente existe para interagir. O servidor existe para preparar e proteger a verdade.