Ma stack pour des produits qui durent : Next.js + Go

Pourquoi séparer le front et le back

Je sépare le front et le back parce que ces deux mondes n'ont ni les mêmes contraintes ni le même rythme d'évolution. Le front change souvent : design, parcours utilisateur, nouvelles pages. Le back doit rester stable, prévisible et rapide sous charge. Mélanger les deux dans un seul bloc finit toujours par freiner l'un au profit de l'autre.

Next.js gère l'expérience et le rendu, Go gère les services métier qui doivent tenir. Cette frontière claire me permet de déployer une refonte visuelle sans toucher à la logique critique, et inversement de durcir un service sans risquer de casser l'interface. Chaque partie évolue à son tempo, ce qui est exactement ce qu'on veut sur un produit destiné à durer.

Next.js pour l'expérience et le SEO

Next.js porte tout ce que voit l'utilisateur et tout ce que lit Google. Avec l'App Router et les React Server Components, je rends le HTML côté serveur, j'envoie un minimum de JavaScript au navigateur et je garde une interactivité fine là où elle compte vraiment. Le résultat est une page rapide à l'affichage et déjà complète pour les robots d'indexation.

Pour le SEO local, ce rendu serveur fait une vraie différence. Les balises, les données structurées et le contenu sont présents dès la première réponse, sans attendre l'exécution d'un script côté client. Une fiche de service pour un artisan rouennais arrive indexable et lisible immédiatement, ce qui pèse sur le positionnement local.

Les Server Components réduisent aussi le poids envoyé au visiteur. La donnée est récupérée sur le serveur, au plus près de la base, et seul le HTML final descend. Moins de JavaScript signifie un INP plus stable et une page qui répond vite aux interactions, y compris sur un mobile modeste.

Go pour les services qui doivent tenir la charge

Je choisis Go pour les services qui doivent rester debout quand le trafic monte. C'est un langage compilé, typé, avec un modèle de concurrence par goroutines qui gère naturellement des milliers de requêtes simultanées sans s'effondrer. La consommation mémoire reste basse et prévisible, ce qui simplifie l'hébergement et réduit la facture.

Go brille sur les tâches où la latence compte : API exposée à beaucoup de clients, traitement de fichiers, synchronisation avec des systèmes externes, jobs en arrière-plan. Là où un back-end interprété commence à transpirer, un service Go reste calme. Les démarrages sont quasi instantanés, ce qui aide aussi en cas de redéploiement fréquent.

La robustesse vient aussi de la simplicité du langage. Peu de magie, peu d'abstractions cachées, un code que je relis sans surprise des mois plus tard. Sur un service critique, cette lisibilité vaut de l'or quand il faut diagnostiquer un incident vite et bien.

Comment les deux communiquent concrètement

Next.js et Go dialoguent via une API HTTP claire, le plus souvent en JSON, avec un contrat bien défini entre les deux. Côté Next.js, j'appelle les services Go depuis les Server Components ou les Route Handlers, jamais directement depuis le navigateur quand il s'agit de logique sensible. Les secrets et les accès base restent côté serveur.

Je verrouille le contrat d'API avec des types partagés et une validation stricte des entrées côté Go. Le front sait exactement ce qu'il reçoit, le back refuse ce qui n'est pas conforme. Cette discipline évite la classe de bugs la plus pénible : celle où une donnée mal formée se propage en silence d'un bout à l'autre du système.

Pour les données qui changent peu, je mets en cache côté Next.js afin d'épargner le service Go et d'accélérer la réponse. Pour les données fraîches, j'appelle Go à la demande. Ce réglage fin entre cache et appel direct est ce qui rend l'ensemble à la fois rapide et toujours juste.

Déploiement et coût de possession

Le déploiement reste simple parce que chaque brique vit là où elle est la plus efficace. Je déploie le front Next.js sur Vercel, qui gère le rendu, le cache et la distribution mondiale sans configuration lourde. Le service Go tourne sur un hébergement adapté à un binaire léger, souvent un simple conteneur, avec une empreinte mémoire faible.

Cette séparation maîtrise le coût de possession sur la durée. Le front se met à jour en continu sans risque pour le back. Le service Go monte en charge sans exploser la facture, et reste assez frugal pour des projets de PME. Au final, le client obtient un produit qui encaisse la croissance sans réécriture, ce qui est tout l'intérêt d'une stack pensée pour durer.