NestJS vs Next.js : deux rôles différents, souvent dans le même projet
NestJS vs Next.js : framework backend ou framework React ? | We.Inc
NestJS crée des API serveur Node.js ; Next.js crée des sites React avec un peu de code serveur. Découvrez le même endpoint dans les deux, comment ils fonctionnent ensemble et quand vous avez besoin de chacun.
NestJS et Next.js ne sont pas concurrents. NestJS est un framework pour les applications Node.js côté serveur : contrôleurs, modules et injection de dépendances pour les API. Next.js est un framework React pour créer des pages web, avec des Route Handlers pour le travail backend léger. Les petites apps peuvent vivre entièrement dans Next.js ; les systèmes plus grands placent souvent une API NestJS derrière un front-end Next.js.
À quoi sert chaque framework
Question
NestJS
Rôle principal
Applications côté serveur et API
Sites et applications web React
Rend des pages ?
Non, il renvoie des données
Oui, Server et Client Components
Langage
Écrit en TypeScript, JavaScript accepté
JavaScript ou TypeScript
Couche HTTP
Express par défaut, Fastify en option
Son propre serveur via next start
Style d'endpoint
Classe @Controller avec des méthodes @Get
route.ts qui exporte GET, POST, etc.
Démarrer un projet
nest new project-name
npx create-next-app@latest
Port local par défaut
Voici un même endpoint, une liste de chats sur GET /cats, écrit comme contrôleur NestJS et comme Route Handler Next.js. Changez d'exemple pour voir une route POST et la configuration qui permet à une page Next.js d'appeler une API NestJS.
Choisissez un exemple : une liste en GET, une création en POST ou la liaison entre les deux apps.
Lisez le code NestJS à gauche et le code Next.js à droite.
Consultez la note pour voir ce que chaque framework vous offre d'emblée.
Copiez la version qui convient à votre projet.
Les deux serveurs de développement utilisent le port 3000 par défaut. Quand vous les lancez côte à côte, démarrez NestJS sur un autre port, par exemple 3001.
Si le navigateur appelle directement l'API NestJS, activez CORS dans NestJS pour l'origine de votre site. Si seul le code serveur Next.js l'appelle, CORS n'entre pas en jeu.
Gardez l'adresse de l'API dans une variable d'environnement réservée au serveur quand seuls des Server Components ou des Route Handlers l'appellent.
Partagez les types de requête et de réponse via un petit paquet importé par les deux apps : un champ renommé cassera alors le build plutôt que la production.
Questions fréquentes
Next.js peut-il remplacer NestJS ?
Pour une petite app, souvent oui. Les Route Handlers couvrent GET, POST, PUT, PATCH, DELETE, HEAD et OPTIONS avec les API Web Request et Response. NestJS se justifie quand le backend grandit : de nombreux modules, des tâches en arrière-plan, plusieurs clients comme des apps mobiles, et une équipe qui veut une structure imposée.
NestJS peut-il rendre des pages React ?
Il n'est pas conçu pour cela. NestJS renvoie des données, avec des objets sérialisés en JSON par défaut. Utilisez Next.js, ou un autre framework front-end, pour les pages.
Ai-je besoin de TypeScript pour NestJS ?
NestJS est écrit en TypeScript et le prend entièrement en charge, et la documentation indique que vous pouvez quand même écrire du JavaScript simple. Presque tous les exemples et guides utilisent TypeScript, attendez-vous donc à l'utiliser.
Les deux doivent-ils vivre dans un même dépôt ?
Un monorepo avec deux apps et un paquet de types partagé fonctionne bien pour une seule équipe. Des dépôts séparés conviennent à des équipes distinctes avec leurs propres calendriers de livraison.
Lequel apprendre en premier ?
Si vous voulez mettre un site en ligne, commencez par Next.js. Apprenez NestJS quand vous créez une API dont dépendent plusieurs front-ends ou services.
Ce que NestJS apporte à un backend
NestJS se présente comme un framework pour créer des applications Node.js côté serveur efficaces et évolutives. Il organise le code en modules, contrôleurs et providers, et les relie par injection de dépendances, ce qui garde une grande API cohérente entre de nombreux développeurs.
Sous le capot, il tourne sur Express par défaut. Brancher l'adaptateur @nestjs/platform-fastify change la couche HTTP sans réécrire vos contrôleurs, même si les middlewares propres à Express doivent alors trouver un équivalent Fastify.
Ce que Next.js apporte à un site
Next.js rend React sur le serveur, route selon les noms de dossiers et de fichiers, et n'envoie au navigateur que les parties interactives. Ses Route Handlers suffisent pour les envois de formulaires, les webhooks et les petits endpoints JSON qui appartiennent au même site.
Ce qu'il ne cherche pas à être, c'est un backend structuré pour d'autres clients. Il n'a ni système de modules ni injection de dépendances, donc une grosse API construite uniquement avec des fichiers de route a tendance à se désorganiser.
Comment ils s'articulent
La répartition courante est Next.js pour toutes les pages et NestJS pour la logique métier et les données. Les Server Components Next.js interrogent l'API NestJS côté serveur, si bien que les secrets et les URL internes n'atteignent jamais le navigateur, et les Client Components ne l'appellent que lorsque c'est indispensable.
Créer les deux projets
Initialiser une API NestJS et un site Next.js
Installe l'outil en ligne de commande Nest, crée l'API, puis crée le site dans un dossier voisin.
GET /cats
Dans NestJS, le préfixe @Controller('cats') et @Get() construisent le chemin, et le contrôleur est enregistré dans un module. Dans Next.js, le chemin du dossier est l'URL et le nom de la fonction exportée est la méthode.
POST /cats
NestJS analyse le corps JSON pour vous avec @Body() et répond à un POST avec le statut 201 par défaut. Un Route Handler Next.js lit le corps avec request.json() et définit lui-même le statut.
Utiliser les deux
NestJS passe sur le port 3001 et autorise l'origine du site. La page Next.js est un Server Component : le fetch s'exécute sur le serveur et API_URL reste privée.