Sur cette page
Une migration de framework est une drôle de façon d’occuper son temps quand on développe seul. On peut accomplir beaucoup de travail et laisser au client exactement le même bouton.
Cela peut valoir la peine. Il faut une meilleure raison que l’envie d’essayer la dernière stack.
Le code de Bisonflow 2.0 passe de Next.js à TanStack Start. Dans l’espace de travail, les utilisateurs modifient des filtres, examinent des tâches, éditent des documents, comparent des timelines et naviguent entre projets. Je voulais mieux suivre le comportement du routage et des données pendant la reconstruction de cette expérience.
Voici pourquoi ce choix convient à Bisonflow. Je n’ai pas réalisé de benchmark contrôlé entre frameworks et je ne présenterai pas une préférence comme une mesure.
L’application était déjà interactive
L’essentiel du comportement d’un outil de projet intervient après le premier chargement. Un filtre change, un panneau s’ouvre, une tâche est modifiée et la vue doit suivre. L’URL doit conserver assez d’état pour qu’un rechargement ou un lien partagé ne produise pas une autre expérience.
TanStack Router apporte un arbre de routes explicite, des paramètres de recherche validés, des loaders et la configuration des métadonnées par route. TanStack Start fournit la partie serveur. Convex reste le backend ; le changement de framework ne lui ajoute pas une deuxième copie des données du projet à gérer.
J’aime pouvoir suivre ces responsabilités dans le code. C’est un choix de maintenabilité pour cette application. Next.js peut aussi servir des produits interactifs, et déplacer un petit site de contenu pour cette raison serait beaucoup moins convaincant.
Le contexte extérieur m’a aidé. La vitrine TanStack présente T3 Chat comme une application Start, et le guide de migration Next.js détaille le traitement du routage, des appels serveur, des métadonnées et du cache. Le choix d’un autre produit justifie une investigation, pas la réussite de ma migration.
Convertir les routes était la partie visible
Renommer les fichiers est satisfaisant : le progrès se compte facilement. Le travail difficile se situe autour.
Une requête arrivant directement sur une page privée exige les mêmes protections qu’un parcours dans l’application. Une fonction serveur doit valider son appelant. Un cache doit cesser d’être réutilisable au bon moment, notamment quand le compte ou l’espace actif change.
Dans Bisonflow, Clerk porte l’identité, Convex les données persistantes, et le cache client doit suivre cette identité. Les pages publiques ne montent ni les composants d’accès aux données authentifiées ni les raccourcis clavier de l’espace. Un lecteur doit pouvoir ouvrir un article sans démarrer l’application privée.
La migration remplace aussi les gestionnaires de requêtes propres au framework par des routes et fonctions serveur Start. Cela inclut ce qu’aucune capture de lancement ne montre : statuts de réponse, redirections, en-têtes de cache privé et métadonnées présentes dans le HTML initial.
Conserver les données, c’est garder les anciennes hypothèses visibles
Une refonte peut donner envie de nettoyer aussi le modèle de données. Certains ajouts étaient nécessaires au produit, mais changer de framework n’était pas une raison de jeter les enregistrements existants.
La migration préserve les identifiants, références de fichiers et données de facturation. Les anciens instantanés documentaires restent disponibles pendant que le nouveau fonctionnement utilise une version de référence enregistrée et un verrou d’édition temporaire. Des changements compatibles et des tâches de migration bornées rendent la transition vérifiable.
Ces décisions font peu d’effet dans une annonce. Elles comptent bien plus que le confort du serveur de développement.
Même logique pour l’argent. Un framework, une identité visuelle et une offre future envisagée sont trois changements distincts. Les deux premiers n’autorisent pas à modifier le prix des abonnements.
Le SEO demandait sa propre migration
Un titre ajouté après l’hydratation ne couvre pas tout le référencement. Titres d’articles, URL canoniques, images de partage, réponses pour les pages absentes et sitemap doivent être pris en charge explicitement.
Start peut rendre les pages publiques côté serveur et produire les métadonnées de chaque route. Il ne recrée pas les conventions Next.js parce que les anciens fichiers se trouvent encore dans le dépôt. Il faut préparer les tailles d’images, définir la livraison des polices et vérifier les redirections comme des requêtes, pas uniquement comme de la navigation cliente.
Les choix par défaut d’un framework peuvent devenir des exigences produit non documentées. Le framework parti, les exigences restent à votre charge.
Qu’est-ce qui ferait de cette migration une erreur ?
Si elle rendait les changements ordinaires plus difficiles à comprendre, perturbait l’accès au travail existant ou retardait des améliorations utiles sans réduire la maintenance, j’aurais payé pour de la nouveauté.
La raison de la garder est pratique : routage, frontières serveur et état de l’espace correspondent mieux à ma façon de construire Bisonflow. Les utilisateurs devraient en ressentir le bénéfice dans la refonte. Le framework devrait surtout disparaître derrière elle.
L’aptitude à la production vient des tests sur les contrats de l’application et le déploiement, pas de l’article qui raconte la migration.
