Server Actions в Next.js 13.4 — мутации на сервере

iMac на столе

TL;DR

Server Actions позволяют выполнять мутации данных прямо на сервере из серверных компонентов Next.js без отдельного API-роута. Это снижает объём клиентского JavaScript, улучшает безопасность и упрощает формы. В Next.js 13.4 функция доступна как экспериментальная возможность — тестируйте на ранних стадиях и планируйте обновление перед продакшеном.

Введение

В релизе Next.js 13.4 появилась стабильная маршрутизация App Router и экспериментальная поддержка server actions. Server actions — это способ объявить серверную функцию рядом с серверными компонентами и вызывать её как действие формы или напрямую из компонентов. Такой подход сокращает количество клиентского кода, упрощает владение секретами и улучшает производительность за счёт перемещения логики на сервер.

Важно: в 13.4 часть возможностей ещё экспериментальна. Для продакшена рекомендуется проверять совместимость с используемыми плагинами и версиями фреймворка.

Что такое Server Actions?

Server actions — это обычные функции, которые выполняются на сервере и помечаются директивой “use server” внутри тела функции. Их можно вызывать из серверных или клиентских компонентов (через формы), и они позволяют делать мутации данных без явного API-роута.

Ключевые преимущества:

Меньше клиентского JavaScript.
Секреты и соединения с БД остаются на сервере.
Упрощённые прогресси́вно-улучшенные формы (progressive enhancement).

Краткое определение: Server action — серверная функция, вызываемая как действие из компонента или формы.

Пример использования Server Actions

Ниже — пример страницы, где форма создаёт пост, вызывая server action createPost.

Импорты:

import Link from "next/link"
import FormGroup from "@/components/FormGroup"
import { revalidateTag } from "next/cache"
import { redirect } from "next/navigation"

Определяем server action, которое выполняется на сервере. Обратите внимание на директиву “use server” — она указывает, что функция и всё внутри неё должны работать на сервере:

async function createPost(data) {
  "use server"
  const title = data.get("title")
  const body = data.get("body")

  await fetch("http://127.0.0.1/posts", {
    headers: { "Content-Type": "application/json" },
    method: "POST",
    body: JSON.stringify({ title, body })
  })

  // Обновляем кэш, помеченный тегом "posts"
  revalidateTag("posts")
  // Перенаправляем пользователя на главную
  redirect("/")
}

Форма, которая вызывает createPost через атрибут action. Форма сама по себе не содержит логики создания — она просто отправляет данные и вызывает server action:

export default function NewPostForm() {
  return (
    
      
        
          Title
          
        
      

      
        
          Body
          
        
      

      
        
      
    
  )
}

Пояснение: при нажатии на кнопку Save Next.js отправит форму как POST-запрос к server action createPost. Сервер получит formData, выполнит fetch к локальному API, принудительно ревалидирует кэш и сделает redirect.

Работа с кэшированием и revalidateTag

Чтобы список постов обновлялся после создания нового поста, используйте теги кэша. В компоненте Posts вызывается getPosts(), которая использует опцию next в fetch для установки тега и времени ревалидации:

export default async function Posts() {
  const posts = await getPosts()

  return (
    
      {posts.map(post => {
        return 
      })}
    
  )
}

Функция получения постов:

async function getPosts() {
  const res = await fetch("https://127.0.0.1/posts?sort=title", {
    next: { tags: ["posts"], revalidate: 3600 }
  })

  return res.json()
}

Объяснение: fetch внутри серверного компонента по умолчанию кэшируется «навсегда», если явно не задать revalidate. Здесь мы задаём revalidate: 3600 (секунд), то есть кэш считается актуальным в течение часа. Когда серверное действие вызывает revalidateTag(“posts”), Next.js принудительно перезапрашивает данные для всех частей, помеченных тегом “posts”, и обновляет отображаемый список.

Доказательство: код действительно выполняется на сервере

Добавьте лог в тело server action:

console.log("Running on the server")

Если сообщение появится в терминале сервера — функция выполняется на сервере. Если оно появится в консоли браузера — выполнение происходит на клиенте. Это важный способ убедиться, что секреты и подключения к базе остаются на сервере.

Когда Server Actions не подходят

Если вам нужна поддержка широкого спектра клиентов (мобайл, внешние сервисы) через единый HTTP API — удобнее API-роуты.
Для длительных фонов задач лучше использовать очереди и фоновые воркеры (например, Bull, RabbitMQ, внешние job-провайдеры).
Когда нужно тонкое управление доступом к HTTP-заголовкам или кэшированием на уровне CDN, стандартный API-роут даст больше контроля.

Альтернативные подходы

Обычные API-роуты Next.js (pages/api или app/api). Подход прост и совместим со всеми клиентами.
GraphQL (Apollo/Relay) для сложных схем и подписок.
tRPC для типобезопасных вызовов между клиентом и сервером.

Выбор зависит от требований к совместимости, масштабируемости и архитектуре команды.

Ментальные модели и эвристики

Разделяйте ответственность: UI — в компонентах, мутации — в серверных действиях.
Думайте о Server Actions как о «локальных API-эндоинтах», которые не требуют отдельного файла маршрута.
Если мутация изменяет ресурс, пометьте соответствующий тег кэша и ревалидируйте.
Минимизируйте стороны эффектов в server action: в идеале — принять данные, выполнить сохранение, ревалидировать и вернуть результат или редирект.

Мини‑методология миграции React-приложения на Next.js с использованием Server Actions

Инвенторизация: найдите все места, где формы делают POST/PUT/DELETE к API.
Приоритизация: начните с внутренних форм (админ-панель, защищённые формы).
Рефакторинг: перенесите логику мутаций в server actions; оставьте только UI в компонентах.
Тестирование: проверяйте логи сервера и клиентские сценарии.
Мониторинг: отслеживайте ошибки, время ответа и всплески трафика после релиза.

Контрольный чек-лист по ролям

Разработчик:

Server action помечено “use server”
Форма отправляет данные корректно
Нет секретов в клиентском коде

Архитектор:

Оценить влияние на CDN и кэш
Решить стратегию реалидации тегов

QA:

Проверить создание/обновление/удаление записей
Проверить редиректы и статусы ответа
Убедиться, что чувствительные данные не попадают на клиент

Критерии приёмки

Форма создаёт запись в базе и возвращает ожидаемый UI-результат.
После создания вызывается revalidateTag(“posts”) и список постов обновляется.
Серверный лог содержит сообщение о выполнении server action.
Клиентская сборка не содержит секретов и переменных окружения.

Шпаргалка и часто используемые сниппеты

Директива server action:

async function action(data) {
  "use server"
  // логика
}

Принудительная реалидация тега:

import { revalidateTag } from "next/cache"
revalidateTag("tag-name")

Перенаправление из server action:

import { redirect } from "next/navigation"
redirect("/")

Совместимость и советы по миграции

В Next.js 13.4 server actions ещё экспериментальны. Планируйте постепенную миграцию.
Тестируйте в изолированном окружении перед интеграцией в продакшен.
Если используете сторонние middleware/edge-функции, убедитесь в их совместимости с server actions.

Примеры проблем и обходные пути

Проблема: долгое выполнение server action мешает UX.
Обход: делегируйте тяжёлую работу в фоновые задачи, возвращайте промежуточный ответ.
Проблема: необходимость публичного API для внешних клиентов.
Обход: оставьте API-роуты для публичных интеграций, используйте server actions для внутриресурсных операций.

Безопасность и переменные окружения

Server actions выполняются на сервере, поэтому здесь безопасно использовать переменные окружения и подключения к базе данных. Но всё же соблюдайте общие практики безопасности:

Не логируйте чувствительные данные.
Ограничивайте входные данные и проверяйте права доступа.
Используйте более безопасные URI и HTTPS для внешних вызовов.

Итог и рекомендации

Server Actions — мощный инструмент для перемещения логики мутаций на сервер. Он уменьшает клиентский код и повышает безопасность. Начните с внутренних форм и админ-панелей, тщательно протестируйте и планируйте обновление Next.js перед широкой продакшен‑применением.