Retour • 26/01/2025

Server Actions ou les API Routes ? Lequel utiliser en NextJS

Écris par Melvyn Malherbe le 26/01/2025

Depuis l'arrivée des Server Actions en NextJS, on peut légitimement se demander s'il faut les utiliser ou plutôt garder les API Routes.

La question est complexe et l'architecture des Server Actions est changeante mais en règle générale, voici mon avis.

Les Server Actions

Elles ont été créées pour simplifier les requêtes HTTP. En fait, React vient cacher tout le processus de Requêtes HTTP derrière une interface qu'ils ont appelée "Server Actions", en gros.

Au lieu de devoir :

1. Créer une route API
2. L'appeler depuis le frontend avec fetch

On vient juste :

1. Créer une fonction
2. L'appeler depuis le frontend

Et automatiquement celle-ci sera effectuée côté serveur, c'est vraiment très pratique et simple.

Voici typiquement une server action :

"use server"

export async function updatePost(id, title) {
  await prisma.post.update({
    where: { id },
    data: { title }
  })

  return "ok"
}

Puis dans le frontend :

"use client"

import { updatePost } from "./actions"

const Button = () => {
  const response = await updatePost(id, title)

  return <button onClick={response}>Update</button>
}

Maintenant qu'on sait ça, on pourrait vouloir utiliser les Server Actions pour fetch des données un peu comme ça :

"use server"

export async function fetchPosts() {
  const posts = await prisma.post.findMany()

  return posts
}

Puis dans un Client Component, on peut récupérer les données avec SWR :

"use client"

import { fetchPosts } from "./actions"

const Posts = () => {
  const { data, isLoading } = useSWR("/api/posts", fetchPosts)
}

Et ici, ça va marcher, mais attention car les Server Actions ne sont jamais cachées.

Dans ce tweet, l'auteur nous montre en quoi il ne faut pas fetch de données avec les Server Actions.

Pourquoi ? Voici ce que la doc React dit :

En Français :

Les actions du serveur sont conçues pour les mutations qui mettent à jour l'état côté serveur ; elles ne sont pas recommandées pour la récupération de données. En conséquence, les frameworks mettant en œuvre des actions du serveur traitent généralement une action à la fois et n'ont pas de moyen de mettre en cache la valeur de retour.

C'est-à-dire que la manière dont NextJS implémente les Server Actions fait que non seulement elles ne peuvent pas être appelées "en même temps" mais qu'en plus le résultat est difficilement gardé en cache, ce qui en fait un mauvais choix pour fetch des données.

Quand utiliser les Server Actions ?

En règle générale, pour toutes les mutations de données :

• mise à jour des données
• création de données
• suppression de données

Mais il faut l'éviter pour la récupération de données.

Aussi, il est intéressant d'éviter d'utiliser les Server Actions si tu souhaites que ces endpoints soient utilisés par d'autres services comme une application mobile.

API Routes

Les API Routes sont la manière basique de faire des modifications côté backend. Il faut créer un fichier route.ts :

// /api/posts/[postId]/route.ts
export const POST = async (req: Request, context: { params: { postId: string } }) => {
  const { postId } = context.params
  const { title } = await req.json()

  await prisma.post.update({
    where: { id: postId },
    data: { title }
  })

  return NextResponse.json({ message: "ok" })
}

Puis on peut l'appeler côté frontend :

export const Button = () => {
  const response = await fetch(`/api/posts/${postId}`, {
    method: "POST",
    body: JSON.stringify({ title })
  })
}

Ce qui permet de faire des actions côté backend. Ça ne change pas vraiment de ce qu'on pourrait faire avec n'importe quel framework ou librairie.

C'est la manière "standard" de faire ce genre de chose.

Pourquoi utiliser les API Routes ?

Le grand avantage des API Routes c'est que c'est normalisé, tu vas donc pouvoir les utiliser pour ton application mobile ou d'autres outils ce qui va être très pratique.

Tu n'as pas besoin d'être en NextJS avec précisément des Server Actions pour fonctionner.

Le problème principal des API Routes c'est que c'est verbeux et que les "string" qui sont les API Endpoint peuvent facilement créer des erreurs. Tu n'es pas sûr de la réponse et que tu as le bon endpoint.

Conclusion : lequel utiliser ?

Pour ma part ma règle est simple : J'utilise toujours les Server Actions pour les mutations de données et les API Routes pour les fetch des données.

Ensuite, si j'ai besoin d'une API Route pour par exemple une application mobile, je vais "copier" la logique de la Server Action pour la mettre dans l'API Route.

Comme ça mon frontend NextJS continue d'utiliser les Server Actions tout en permettant via un autre endpoint de récupérer les données.

Pourquoi faire ça ?

Parfois les besoins entre le frontend et le mobile ne sont pas les mêmes. Je sais que mes Server Actions ne sont utilisées que par mon frontend, donc quand je veux faire évoluer une feature je peux très facilement modifier ma logique de Server Actions sans impacter le mobile.

C'est une bonne pratique de ne pas tout mélanger pour permettre une plus grande flexibilité.