GitHub

Existe um tipo de código que todo time acaba escrevendo sem questionar: a camada de cola entre o formulário e o banco. Um endpoint que recebe o POST, valida o corpo, chama o serviço, devolve um JSON. Do outro lado, um fetch no cliente que monta esse corpo, trata o erro, atualiza o estado. Multiplique por cada ação de gravação do produto e você tem centenas de linhas que existem só para mover dados de um lado para o outro.

Server Actions, no Next.js, atacam exatamente essa cola. A proposta é direta: executar mutações (gravar, atualizar, deletar) a partir de uma função que roda no servidor, chamada diretamente do componente, sem que você precise desenhar, versionar e manter uma API REST dedicada para isso. O endpoint continua existindo, mas o framework o gera e o conecta por você.

O que muda na prática

Uma Server Action é uma função assíncrona marcada para rodar no servidor. Você a associa a um formulário ou a um evento, e o Next.js cuida do transporte: serializa os argumentos, faz a chamada de rede, devolve o resultado. Do ponto de vista de quem escreve a tela, parece que você está apenas chamando uma função local.

A diferença em relação ao modelo anterior é menos código e menos pontos de sincronização. Não há mais um contrato de API para manter alinhado entre dois lados, nem um schema de request que precisa casar com o que o cliente envia. A função que grava o pedido e a tela que dispara essa gravação vivem perto uma da outra, e o tipo de retorno é o mesmo nas duas pontas.

Isso importa porque a maior parte do atrito em times de produto não está na lógica de negócio, está na cola. Cada mutação que antes exigia um arquivo de rota, um handler, um cliente de fetch e um tipo compartilhado agora cabe em uma função. Menos superfície para errar, menos arquivos para abrir quando algo quebra.

O ganho de produtividade é real, mas não é o ponto central

É tentador vender Server Actions como atalho de produtividade, e elas são. Mas reduzir o discurso a "menos boilerplate" subestima o que está acontecendo. O ganho mais importante é arquitetural: a lógica sensível deixa de transitar pelo cliente.

Quando a mutação roda no servidor, a chave de API, a credencial do banco, a regra de preço, o cálculo de comissão, nada disso precisa ser enviado ao navegador. O cliente dispara a intenção ("criar este pedido") e o servidor decide o que isso significa. O código que importa nunca sai do ambiente que você controla.

Isso resolve uma classe inteira de vazamentos que o modelo de SPA tradicional tornou comum. Times espalham lógica de negócio no front porque era ali que ficava mais conveniente, e depois descobrem que regras de desconto ou validações de limite estavam expostas no bundle. Com a mutação no servidor por padrão, a tentação some: não há onde colocar essa lógica no cliente, porque o cliente só conhece a chamada.

Para entender por que o servidor virou o lugar natural dessa lógica, vale revisitar a ideia mais ampla de arquitetura server-first na web, da qual as Server Actions são uma peça.

O cuidado que ninguém pode pular: tratar a entrada como hostil

Aqui está a parte que separa quem usa Server Actions bem de quem cria um buraco de segurança elegante. Uma Server Action é um endpoint público. O fato de você só a chamar a partir de um formulário bonito da sua própria aplicação não muda isso.

Quando o Next.js gera a action, ele expõe uma rota que aceita chamadas. Qualquer um com a ferramenta certa pode forjar uma requisição para ela, com os argumentos que quiser, na ordem que quiser. A interface que você desenhou não é uma barreira: é só uma das formas de chamar aquela função. Pensar "mas o meu front nunca enviaria esse valor" é o erro clássico, porque o atacante não está usando o seu front.

Disso decorrem duas obrigações inegociáveis. A primeira é validação. Todo argumento que chega precisa ser checado no servidor, com um schema explícito, antes de tocar qualquer regra de negócio. Tipo, formato, faixa de valores, presença de campos. A tipagem do TypeScript ajuda durante o desenvolvimento, mas ela desaparece em tempo de execução; ela não valida nada de quem chama a rota por fora.

A segunda é autorização, e ela é distinta da validação. Validar responde "este dado faz sentido?". Autorizar responde "esta pessoa pode fazer isto?". Toda Server Action que muda estado precisa, dentro de si mesma, verificar quem é o usuário e se ele tem permissão para aquela operação sobre aquele recurso. Não confie em ter escondido o botão na interface. O botão escondido não protege a função; só a checagem dentro dela protege.

Por que essas checagens precisam morar dentro da action

Há uma tentação de centralizar autorização em um middleware e considerar o assunto resolvido. Middleware ajuda, mas costuma operar no nível da rota, não no nível do recurso. Ele consegue dizer "este usuário está logado", e raramente consegue dizer "este usuário é dono justamente deste pedido que ele está tentando cancelar".

Essa diferença é onde moram as falhas mais caras. Um usuário autenticado e legítimo pode tentar agir sobre um recurso que não é dele apenas trocando um identificador no argumento da chamada. A autenticação passou; a autorização sobre o objeto específico é que falhou. Por isso a checagem de permissão pertence ao corpo da action, perto da regra de negócio, onde você tem o contexto completo do que está sendo alterado e para quem.

O princípio é antigo e vale a leitura mais ampla sobre fundamentos de segurança em aplicações web: toda fronteira entre o que o usuário pede e o que o sistema faz é um ponto de verificação. Server Actions não criam essa fronteira, elas a tornam mais discreta, e o discreto é justamente o que se esquece de proteger.

Como pensar a adoção sem virar bagunça

Server Actions não eliminam a necessidade de uma camada de serviço. Se você jogar toda a lógica de negócio dentro das actions, vai recriar o problema do controller gordo, só que com outro nome. A action deve ser fina: ela recebe a chamada, valida, autoriza e delega para uma função de domínio que não sabe nada sobre HTTP nem sobre Next.js.

Essa separação mantém a lógica testável e reaproveitável. A mesma regra de criar pedido pode ser chamada por uma action, por um job de fila e por um script de importação, desde que ela viva fora da action. Trate a Server Action como porta de entrada, não como o cômodo inteiro.

Vale também ser honesto sobre quando ainda faz sentido uma API tradicional. Se você tem clientes externos, um aplicativo mobile nativo ou integrações de terceiros, uma API versionada e documentada continua sendo a resposta certa. Server Actions brilham no acoplamento entre o seu front e o seu back; elas não foram pensadas para ser o contrato público que um parceiro vai consumir. Como isso se encaixa no resto do framework fica mais claro no guia do App Router do Next.js.

O que levar para a decisão

Server Actions reduzem código de cola e empurram a lógica sensível para o servidor por padrão, o que é um ganho de produtividade e de postura de segurança ao mesmo tempo. Esse é o argumento a favor, e ele é forte para a maioria das aplicações que são, no fim, o seu front conversando com o seu back.

O preço é disciplina. Cada action é uma porta pública e precisa ser tratada como tal: validação explícita, autorização no nível do recurso, lógica de domínio fora dela. Quem trata isso como detalhe troca boilerplate visível por risco invisível, e risco invisível é o tipo que aparece em produção no pior momento.

Se você está desenhando a arquitetura de uma aplicação Next.js nova, vale modelar desde o início onde ficam as fronteiras de confiança antes de sair distribuindo actions pelo código. Se quiser trocar ideia sobre esse desenho, me chame nos comentários ou nas redes.