← All writing nextjs · react · fullstack
An honest take on Next.js server actions, two years in
Where server actions are great, where they hurt, and what I reach for instead.
Mar 22, 2026 1 min read
Server actions changed how I write Next.js apps. They also created a few specific footguns I now plan around.
Where they shine
Form mutations. Simple CRUD. Anywhere the request lifecycle is “user clicks → write to DB → revalidate UI”. The colocated mental model is genuinely worth the ergonomic tax.
Where they hurt
- Concurrent mutations: there’s no obvious queueing primitive, so you write debounce + version checks per action.
- Complex inputs: you end up serializing rich payloads through FormData or shipping a thin JSON wrapper anyway.
- Background work: server actions are not jobs. Treating them like one will bite you.
What I reach for
For anything more than form-style mutations I still write API routes (or Hono on the edge). For long-running work I use a worker queue with Postgres + BullMQ. Server actions stay focused on what they’re good at.
Tools don’t replace each other. They expand the menu.