Développement
7 mars 2024
Le 26 octobre 2022, lors de la Next.js Conf, Vercel a dévoilé Next.js 13, introduisant un ensemble de nouvelles fonctionnalités et un tout nouveau changement de paradigme pour créer des applications Next.js.
Les composants serveur React (RSC) sont connus depuis un certain temps mais n'ont pas encore été implémentés dans un méta-framework React. Avec Next.js qui les ajoute maintenant, le monde du rendu côté serveur des applications React allait changer.
La promesse des composants serveur React
Décrits par Vercel comme un outil pour écrire des interfaces utilisateur rendues ou éventuellement mises en cache sur le serveur, les RSC promettaient une intégration directe avec des bases de données et des capacités spécifiques au serveur, une rupture avec les modèles typiques de React et de SSR.
Cette fonctionnalité est initialement apparue comme un bouleversement, promettant une collecte de données et un routage plus simples, grâce aux composants serveur asynchrones et à un support de mise en page imbriquée supplémentaire.
Après avoir expérimenté cela pendant environ six mois sur d'autres projets, je suis arrivé à la conclusion que, bien que cela ait été un peu rugueux sur les bords, c'était en effet un élément révolutionnaire et quelque chose qui devrait être adopté dans les projets Next.js à l'avenir.
Un nouveau paradigme : les actions serveur
Vercel ne s'est pas arrêté à l'ajout de composants serveur. Peu de temps après la sortie initiale de Next.js 13, ils ont introduit "les actions serveur". Les actions serveur permettent d'appeler des fonctions côté serveur sans routes API, réduisant ainsi le nombre de formalités nécessaires pour ajouter une nouvelle mutation ou un événement à votre application.
Parier sur de nouvelles technologies
Suite à la sortie à la fois des actions serveur et des composants serveur, nous, chez Documenso, avons entrepris une réécriture de l'application. Nous avions accumulé un peu de dette technique depuis le MVP initial, qu'il était préférable de réduire alors que nous améliorions également le design avec l'aide de notre nouveau designer.
Ayant eu beaucoup de succès avec les composants serveur sur d'autres projets, j'ai choisi de m'engager pleinement sur les composants serveur et les actions serveur pour la nouvelle version de l'application. J'étais impatient de voir à quel point l'application serait plus simple et plus efficace avec ces nouvelles technologies.
Après notre relancement, nous étions assez contents de nos choix d'actions serveur, qui nous ont même permis de combiner certaines logiques côté client et serveur en un seul composant sans avoir à fournir beaucoup d'efforts de notre part.
Naviguer à travers les défis des actions serveur
Bien que initialement réussies, nous avons rapidement rencontré des problèmes avec les actions serveur, notamment lors de la surveillance de l'application. Malheureusement, les actions serveur rendent beaucoup plus difficile la surveillance des requêtes réseau et l'identification des actions serveur échouées puisqu'elles utilisent la route sur laquelle elles se trouvent actuellement.
Malgré ce problème, les choses étaient gérables; cependant, un problème critique est survenu lorsque l'utilisation des actions serveur a provoqué une corruption de bundle, résultant en une insertion d'attente au niveau supérieur qui ferait échouer les build et les tests.
Ce dernier problème était un élément décisif puisqu'il mettait en évidence combien de magie nous comptions sur les actions serveur. J'aime éviter d'ajouter plus de magie lorsque cela est possible puisque, avec les bundlers et les méta-frameworks, nous confions déjà beaucoup de travail lourd et obtenons beaucoup de magie en retour.
Tout miser sur tRPC
Ma solution rapide et finale aux problèmes auxquels nous faisions face était d'adopter entièrement tRPC, que nous avions déjà utilisé dans d'autres domaines de l'application. La migration a pris moins d'un jour et a résolu tous nos problèmes tout en ajoutant beaucoup plus de visibilité aux actions échouées puisqu'elles avaient désormais une route API dédiée.
Pour ceux qui ne connaissent pas tRPC, c'est un framework pour construire des API typées de bout en bout avec TypeScript et Next.js. C'est une bibliothèque géniale qui vous permet d'appeler votre API définie en toute sécurité dans le client, provoquant des erreurs de compilation lorsque les choses dérivent inévitablement.
Je suis un grand fan de tRPC depuis un certain temps maintenant, donc la décision d'abandonner les actions serveur et d'utiliser plutôt plus de tRPC a été facile pour moi.
Leçons apprises et avenir
Bien que je pense que les actions serveur sont une excellente idée, et je suis sûr qu'elles seront améliorées à l'avenir, j'ai réappris la leçon qu'il est préférable d'éviter la magie lorsque cela est possible.
Cela ne signifie pas que nous ne considérerons pas de revenir à certaines choses avec les actions serveur à l'avenir. Mais pour l'instant, nous allons attendre et observer comment les autres les utilisent et comment elles évoluent.