- L’équipe de Hardcover a migré vers Ruby on Rails + Inertia.js en raison de la dégradation des performances de l’architecture basée sur Next.js, de coûts élevés et d’un ralentissement de la vitesse de développement
- Inertia.js a été choisi pour répondre aux exigences suivantes : SSR compatible avec le SEO, connexion directe à la base de données et conservation de React
- L’explosion inattendue des coûts sur Vercel et Cloud Run, ainsi que l’incertitude autour du caching de Next.js, ont été les éléments déclencheurs du changement
- Inertia.js s’est révélé être le moyen idéal de relier un backend Rails à un frontend React, en facilitant le SSR et la gestion du cache
- Après la transition, les scores Google Pagespeed et SEO se sont améliorés, et le temps passé sur le site ainsi que la visibilité dans la recherche ont augmenté
Contexte de la transition
- Au départ, l’équipe avait choisi Next.js, capable de gérer le SEO et le SSR, et avait construit une architecture reposant sur une API GraphQL
- La plupart des données étaient demandées côté client depuis le navigateur, tandis que les données statiques étaient mises en cache côté serveur
- Avec le temps, l’absence de cache a entraîné une hausse des requêtes API, une baisse des performances et un ralentissement de l’environnement de développement
Problèmes rencontrés avec Next.js
- Même après le passage à l’App Router, le gain de vitesse est resté minime ; les requêtes POST Apollo n’étaient pas mises en cache, ce qui a annulé l’effet attendu
- Le changement de politique tarifaire de Vercel a fait passer la facture mensuelle de 30 $ à 354 $
- Cloud Run était également bon marché au départ, mais est ensuite monté jusqu’à 524 $
- La structure de cache de Next.js était difficile à comprendre, rendant une gestion efficace impossible
- La vitesse de développement a nettement chuté, compliquant l’onboarding des nouvelles recrues
Pourquoi Rails + Inertia.js
- L’équipe voulait conserver le SSR tout en récupérant les données directement depuis la base de données
- Elle souhaitait continuer à utiliser React ; Remix, react-rails et react_on_rails ont aussi été évalués, mais inertia-rails a finalement été retenu
- Inertia.js permet d’utiliser le routage Rails sans routage frontend, tout en facilitant le SSR
- Le rendu est géré dans le contrôleur avec
inertia: 'nom_de_page', et le cache est implémenté avec Rails.cache.fetch
- Les props sont reçues dans les composants React via
usePage()
Structure SSR et build
- Pour le SSR,
application.tsx gère la bifurcation entre hydrateRoot et createRoot
- Vite fonctionne comme serveur indépendant et prend en charge le hot reload en développement
- Automatisation du déploiement Rails + Vite via Docker et Kamal, avec séparation entre staging et production
- Au déploiement, l’exécution se fait avec la commande
make deploy, et l’asset host utilise CloudFlare pour optimiser le cache
Effets de la transition
- Après le déploiement de la migration le 18 mars 2025, la visibilité dans Google a augmenté et la vitesse des pages s’est améliorée
- Le Total Blocking Time s’est fortement amélioré, entraînant une hausse du score Pagespeed
- Le temps moyen passé par visiteur est passé de 3 minutes à 6 minutes, avec une tendance à la hausse
- Le trafic est resté stable, tandis que le nombre d’inscriptions s’est maintenu de façon régulière
Défis restants et pistes d’amélioration
- La réutilisation du layout commun reste difficile, et chaque page est entièrement rerendue
- Le débogage du SSR est difficile, avec une configuration complexe
- La combinaison Inertia.js + Rails souffre d’un manque de documentation, résolu en partie via la communauté Discord
- Il faut s’adapter à l’approche d’Inertia plutôt qu’à Suspense
- Hasura est toujours utilisé pour le moment, donc certaines fonctionnalités d’Inertia comme form et flash ne sont pas encore exploitées
Conclusion et perspectives
- Une structure intégrant naturellement React + Rails a permis d’améliorer la productivité de développement et la maintenabilité
- Le choix d’Inertia.js a permis de sécuriser en même temps la vitesse, le SSR et la sûreté de typage
- L’équipe prévoit désormais d’ouvrir le projet en open source et d’attirer des contributeurs
2 commentaires
L’utilisation de
Linkdans Next.js fait polémique, car pour prendre en charge React Server Components, des URL du type?_rsc=1ip3isont générées et traitées. On entend aussi dire que les coûts liés au CDN ont explosé, et l’équipe de développement de Next.js serait au courant du problème, mais on ne sait pas encore de quelle manière ni quand il sera résolu.Avis Hacker News
Le rendu côté serveur (SSR) n’a jamais disparu, et le web se rappelle seulement maintenant pourquoi c’était la valeur par défaut. Le premier rendu et le SEO restent meilleurs quand le serveur envoie le balisage. Divers frameworks comme Rails + Turbo, HTMX, Phoenix LiveView et React Server Components prennent toujours le SSR comme base. La plupart des tableaux de bord et applications CRUD n’ont pas besoin d’un routeur client, d’un état global ni d’un bundle d’hydratation de 200 kB, seulement de remplacements partiels de HTML
Le vrai moteur, c’est le coût de la complexité. Chaque ligne de JS côté client apporte des outils de build, du bruit dans les audits npm et des risques liés à la supply chain. Réduire cette charge utile améliore à la fois les performances et la sécurité. Bien sûr, des applications comme Figma ou Gmail tirent encore profit d’une logique client lourde. D’où un modèle qui émerge : « HTML par défaut, JS seulement là où c’est nécessaire ». Il faut penser en îlots, pas en SPA complète
Donc oui, il y a un retour vers le serveur, mais ce n’est pas une nostalgie du PHP de 2004. Il s’agit d’ajuster JavaScript à sa juste place et de laisser HTML faire les 90 % de tâches ennuyeuses qu’il a toujours bien su faire
Nous avons utilisé NextJS sur quelques projets, mais nous sommes déjà en train de l’abandonner progressivement. Il y a plusieurs raisons, dont quelques facteurs majeurs
L’histoire de l’authentification est difficile. next-auth avait certaines limitations, ce qui nous a poussés à utiliser iron-session. Par exemple, il n’était pas possible d’utiliser des domaines de fournisseurs d’identité dynamiques, donc nous avons dû prendre en charge tout le flux openid. C’était faisable, mais une perte de temps inattendue pour un framework réputé mature
Comme le serveur NextJS n’était pas notre principale passerelle API, nous avons dû tout faire passer par un proxy. La documentation n’était pas claire et cela a ajouté des problèmes aléatoires, comme les délais d’expiration des requêtes ou la taille maximale des en-têtes
Le framework pousse très agressivement vers le cloud, ce qui allait à l’encontre de nos objectifs
Les mainteneurs n’étaient pas particulièrement utiles. Nous utilisons d’autres outils/frameworks malgré leurs défauts parce que leurs mainteneurs sont très accessibles et serviables (merci à Chillicream/HotChocolate)
Je me souviens avoir lu l’an dernier un billet de blog affirmant que passer du pages router au app router de Next.js avait amélioré le SEO. Cette fois, nous quittons Next pour React+Inertia.js à cause de la hausse des coûts chez Vercel. Déployer la même application sur notre propre VPS au lieu d’un fournisseur cloud résoudra probablement le problème. Mais je ne comprends pas cette volonté de complexité. Une application de suivi de livres a-t-elle vraiment besoin de GraphQL, d’un framework frontend séparé et d’un processus de build complexe, ou tout cela aurait-il pu être évité en déployant dès le départ une application RoR unique avec des templates HTML sur un VPS ?
Chaque fois que je vois un article ou une discussion sur le web et les stacks, je finis par poser la question : « quel problème essaie-t-on réellement de résoudre ? » La réponse est toujours : « afficher du texte à l’écran »
Je me demande ce que font les gens quand ils veulent du full stack JS, surtout quand une base de données entre en jeu. La situation des ORM est très fragmentée, sinon il faut écrire du SQL brut. Et il faut quand même décider du backend. Utiliser express ? Next.js est bien connu, mais semble porter un agenda discutable. Remix, Astro, TanStack, etc. C’est déroutant de devoir sans cesse se recalibrer et réévaluer quoi utiliser
Pour les projets personnels, je reviens souvent à Ruby on Rails. C’est toujours un plaisir. En revanche, il y a trop peu de développeurs Rails disponibles (comparé à JS), donc ce n’est pas vraiment adapté aux projets professionnels. Choisir JS, et souvent Java, pour le backend n’est pas irresponsable
Je me demande si d’autres ressentent la même chose
Les développeurs frontend et backend ont longtemps eu du mal à bien se parler
Historiquement, en tant que développeur backend, je détestais Html/JS/CSS. C’est un paradigme significativement différent de Swing/Awt, WinForms, Android UX, etc. Rien que cela me frustrait et me poussait à rester côté backend. Pour apprendre le frontend, il fallait apprendre ces trois éléments. Ce n’est que maintenant que je commence à m’y sentir à l’aise
Mais les développeurs frontend, eux, devaient apprendre « encore un autre langage ». Beaucoup de langages ont des systèmes de build différents ou pénibles par rapport à nvm. Et comme le sait quiconque a déjà changé de langage, cela implique aussi d’apprendre de nouveaux frameworks, de nouveaux paradigmes, etc.
Certains ont donc réalisé qu’ils pouvaient pousser JavaScript jusqu’au backend. Cela avait beaucoup d’inconvénients, mais pour les gens qui veulent « juste faire le travail », surtout dans un monde de « ajoutez plus de serveurs » et de « l’argent du capital-risque est gratuit ! brûlez-le en infrastructure ! », ces inconvénients n’étaient pas vraiment préoccupants
Mais les développeurs frontend, désormais des « développeurs full stack », mais en pratique plutôt des développeurs « tout en JavaScript », continuent à produire de manière très visible. Cela se reflète aujourd’hui dans les offres d’emploi sur LinkedIn, qui demandent des rôles Next.JS/Node.JS/autres. Une seule langue pour tout dominer
Quelques réflexions en vrac, mais je pense qu’elles sont fortement liées aux raisons pour lesquelles les gens choisissent Next.JS
Je ne peux pas me prononcer sur les aspects techniques (je ne connais que Next.js et pas Rails, donc je ne sais pas si ce billet reflète simplement le confort de l’auteur avec Rails ou une architecture réellement plus adaptée sur le plan technique). En revanche, je trouve étrange qu’une entreprise avec plusieurs ingénieurs logiciels se préoccupe de coûts d’infrastructure inférieurs à 1 000 dollars par mois. Se focaliser sur les coûts d’hébergement ne me semble pas judicieux
Si Rails s’était concentré sur un vrai support de premier ordre pour l’interopérabilité avec les frameworks frontend, il serait probablement bien plus important aujourd’hui. Beaucoup d’efforts ont été investis dans Hotwire, mais moi je veux utiliser React, et d’autres voudront utiliser ce qu’ils connaissent
Je me demande pourquoi il existe un débat entre Next.js et SSR. Next.js est hybride et s’en sort plutôt bien. Contrairement à d’autres frameworks SPA, Next.js génère une sortie HTML pré-rendue pour un chargement initial rapide, fournit des chunks JS efficaces, des options de configuration comme le préchargement au survol des liens ou de tous les liens n+1 après le rendu de la page, ainsi qu’un chargement d’images (pré)optimisé selon les breakpoints, ce qui est souvent le talon d’Achille des solutions purement SSR
J’ai un peu écrit en Rails, mais je ne comprends pas vraiment l’enthousiasme qu’il suscite. C’était tout à fait correct, mais je n’y ai rien trouvé de spécial