Server Actions mudaram a forma como escrevemos mutações no Next.js: em vez de criar uma rota de API separada, você define uma função assíncrona marcada com 'use server' e chama ela direto do formulário ou do client component.
Criando sua primeira action
'use server'
export async function criarArtigo(formData: FormData) {
const titulo = formData.get('titulo')
await db.article.create({ data: { titulo } })
revalidatePath('/admin/artigos')
}O `revalidatePath` invalida o cache da rota indicada depois da mutação, então a próxima navegação já busca dados atualizados sem precisar de um refresh manual.
Validando dados com Zod
Sempre valide os dados recebidos antes de persistir. Server Actions são endpoints públicos, mesmo sem uma rota HTTP visível — qualquer pessoa pode chamar a função diretamente, então a validação não pode depender só do que o formulário do frontend permite digitar.
Nunca confie em validação feita só no client. Trate toda Server Action como se fosse uma rota de API pública, porque tecnicamente é uma.
Tratamento de erros
Server Actions não devem lançar exceções não tratadas para o cliente. O padrão mais comum é retornar um objeto com o resultado (sucesso ou lista de erros) em vez de usar throw, para o componente decidir como exibir a mensagem.
Perguntas frequentes
Não necessariamente. Para integrações externas ou webhooks, uma rota de API dedicada ainda costuma ser mais adequada. Server Actions brilham mais em mutações internas do próprio app.