Pendant des années, la forme par défaut d'une application web, c'était deux bases de code qui faisaient semblant de n'en faire qu'une. Un frontend, une API backend distincte, et au milieu une couche de colle dont le seul rôle était de faire passer les données d'un côté à l'autre et de garder deux jeux de types synchronisés. La majeure partie de cette colle existait pour résoudre un problème que le framework sait désormais résoudre à votre place.

Nous construisons la plupart de nos produits comme une seule application Next.js, où la logique serveur vit dans des server actions. Pas de service d'API séparé, pas de client qui passe la moitié de son code à récupérer et remodeler des données. Cette approche tient bien plus longtemps que ce que les gens imaginent, à condition de rester rigoureux sur la structure. Voici cette rigueur.

Par défaut, une seule base de code

Une couche d'API séparée est le bon choix quand quelque chose en a réellement besoin. Une API publique pour des tiers. Plusieurs clients qui partagent un même backend. Un service avec son propre profil de montée en charge. Sans l'une de ces raisons, une seconde base de code n'est qu'une taxe que vous payez en colle, en types dupliqués et en un déploiement supplémentaire à garder synchronisé.

Avec les server actions, un bouton appelle une fonction qui s'exécute sur le serveur, et le type de ce qu'elle retourne est connu automatiquement des deux côtés. La frontière réseau cesse d'être une couche de traduction que vous entretenez à la main. Cette suppression représente l'essentiel du gain.

Deux bases de code qui doivent s'accorder sur tout sont en général une seule base de code qu'on a séparée trop tôt.

C'est la structure qui vous sauve

Le danger des server actions, c'est qu'elles sont faciles. Et ce qui est facile prolifère. Glissez des appels à la base de données directement dans les composants, et en un mois la logique sera éparpillée partout, introuvable et impossible à tester.

Nous gardons donc une forme claire. Les actions vivent dans leur propre couche et portent la logique métier. Les helpers, les schémas et les types d'une fonctionnalité vivent ensemble, si bien qu'une fonctionnalité est un endroit, pas un éparpillement. Les composants appellent les actions, ils ne passent jamais par-dessus. La règle est ennuyeuse, et c'est précisément l'intérêt. Un nouvel ingénieur peut deviner où se trouve une chose, parce que tout ce qui est du même genre vit au même endroit.

Protégez la frontière, à chaque fois

La seule erreur qui fait vraiment mal avec les server actions, c'est d'oublier que ce sont des points d'entrée publics. Une server action est une porte vers votre backend. Si elle ne vérifie pas qui frappe, elle est grande ouverte.

Nous imposons les contrôles d'authentification et de rôle au début de chaque action qui touche à quoi que ce soit de sensible, et non dans le composant qui se trouve l'appeler. Le composant est une suggestion. L'action est le portail. Chaque action retourne un résultat typé et prévisible, de sorte que l'appelant gère le succès et l'échec de la même façon à chaque fois, sans que rien ne fuie par une branche oubliée.

Validez l'entrée comme si elle était hostile

Parce qu'une action peut être appelée directement, vous traitez son entrée comme non fiable, toujours. Nous validons chaque payload contre un schéma dès la porte, avant que la moindre logique ne s'exécute. C'est le même schéma que celui utilisé par le formulaire, donc le client et le serveur s'accordent sur ce que « valide » signifie sans que personne n'ait à maintenir deux copies. Une mauvaise entrée est rejetée à la frontière au lieu de devenir une ligne corrompue trois fonctions plus loin.

Quand ajouter la couche

Cette approche a un plafond, et vous devez savoir où il se situe. Quand vous avez réellement besoin de servir d'autres clients, d'exposer un contrat public stable ou de faire monter en charge une partie de façon indépendante, ajoutez le service. Faites-le parce qu'un vrai besoin est arrivé, pas parce qu'un schéma dans un article de blog affirme que les vraies applications ont un dossier backend.

La plupart des produits n'atteignent jamais ce plafond. Ils livrent plus vite, avec moins à maintenir et moins de risques de dérive, sur une seule base de code bien structurée. Commencez là. Ajoutez de la complexité le jour où le produit la mérite, et pas un jour avant.