Pourquoi nous construisons tout sur Next.js et l'edge

Nous avons essayé beaucoup de stacks. Après avoir construit plus de 40 sites et applications en production, nous avons convergé vers Next.js déployé sur l’edge comme stack par défaut. Voici le raisonnement, y compris les compromis.

Pourquoi Next.js

Next.js vous donne la possibilité de choisir la bonne stratégie de rendu par route — génération statique, rendu serveur ou rendu client — sans changer de framework.

Pour un site marketing, la plupart des pages sont statiques. Le blog est généré statiquement. L’endpoint du formulaire de contact est rendu côté serveur. La démo interactive est rendue côté client. Un seul framework gère tout cela.

L’App Router (introduit en v13, mature depuis la v15) apporte les React Server Components, ce qui signifie que vous pouvez récupérer des données côté serveur et livrer zéro JavaScript au client pour les composants qui n’ont pas besoin d’interactivité. Une page riche en contenu qui livrait auparavant 200 Ko de JS en livre désormais 15 Ko.

Pourquoi l’edge

Les serveurs traditionnels tournent dans une seule région. Un utilisateur à Singapour qui interroge un serveur dans us-east-1 ajoute 200 à 300 ms de latence réseau à chaque requête avant même que le serveur n’ait commencé à traiter quoi que ce soit.

Les runtimes edge — Vercel Edge Functions, Cloudflare Workers — exécutent votre code dans plus de 30 emplacements à travers le monde. Le serveur est toujours proche de l’utilisateur. TTFB systématiquement sous 50 ms à l’échelle mondiale.

Le compromis : les runtimes edge sont contraints. Pas d’accès au système de fichiers, des API Node.js limitées, des limites de mémoire plus serrées. Cela impose une discipline architecturale — fonctions sans état, données récupérées depuis des API ou des bases en cache edge.

La stack complète

• Framework : Next.js (App Router)
• Styles : Tailwind CSS v4
• Base de données : Postgres sur Neon (serverless, compatible edge) ou Supabase
• Auth : Clerk ou next-auth selon la complexité
• E-mail : Resend
• Paiements : Stripe
• CMS : fichiers MDX dans le dépôt pour les sites riches en contenu ; Sanity pour le contenu éditable par le client
• Déploiement : Vercel

Ce que nous n’utilisons pas

Nous n’utilisons pas le rendu client pour les pages qui n’en ont pas besoin. Nous n’utilisons pas d’API REST là où une server action ou une récupération de données RSC est plus simple. Nous n’ajoutons pas de framework backend quand les route handlers de Next.js suffisent.

La complexité compose. Chaque service supplémentaire est une chose de plus qui peut tomber en panne, une couche d’authentification de plus, un pipeline de déploiement de plus. La bonne stack est la plus simple qui gère les exigences.

Construisez pour les exigences que vous avez. N’ajoutez de la complexité que lorsque vous avez dépassé la solution la plus simple.