Erreurs techniques liées à la gestion de 16 produits sur Lovable et Supabase
Nous gérons 16 produits chez Inithouse. Nous utilisons Lovable et Supabase pour chacun d'entre eux. Une seule équipe s'occupe de tout. Cela semble idéal, jusqu'à ce que vous deviez faire face à 16 domaines personnalisés, 16 projets Supabase et 16 ensembles de fonctions edge.
Nous avons commis des erreurs qui nous ont coûté du temps. Voici les cinq plus grandes erreurs techniques et nos solutions.
- Schémas de base de données incohérents
Nos trois premiers produits utilisaient des noms de tables différents pour les mêmes données. Un projet utilisait page_views pour l'analyse. Un autre utilisait analytics_events. Cela rendait impossible l'écriture de code partagé. Une tâche qui aurait dû prendre un après-midi nous a pris deux semaines.
La solution : Nous avons créé un modèle de migration partagé. Chaque nouveau produit bénéficie des mêmes tables de base pour l'analyse, les articles de blog et l'authentification. Nous avons mis à jour les anciens projets lors des semaines plus calmes. Désormais, l'ajout d'un point de terminaison (endpoint) de surveillance prend 20 minutes au lieu d'une journée.
- Domaines personnalisés défectueux
Lovable vous permet de connecter des domaines personnalisés. Parfois, le déploiement réussit mais la vérification DNS échoue. L'URL de prévisualisation fonctionne, mais le domaine en direct affiche une page blanche. Nous avons perdu trois jours de trafic parce que nous n'avions pas vérifié l'URL en direct.
La solution : Nous utilisons une checklist post-publication. Nous ouvrons chaque domaine en direct dans une fenêtre de navigation privée pour le vérifier. Nous avons également ajouté un contrôle de disponibilité (uptime check) qui envoie une notification Slack si un domaine échoue.
- Visibilité fragmentée des données
Nous ne pouvions pas voir les performances de l'ensemble de notre portefeuille sans ouvrir des tableaux de bord distincts pour chaque produit. Nous naviguions à vue.
La solution : Nous avons déployé un endpoint d'API de statistiques sur chaque projet Supabase. Chaque produit envoie des indicateurs clés, tels que le nombre d'utilisateurs et d'inscriptions, dans un format standardisé. Un script unique récupère ces données pour les centraliser dans un seul tableau de bord.
- Copier-coller de composants
Nous avions l'habitude de copier des composants React d'un projet à un autre. Ces composants transportaient d'anciennes hypothèses. Une carte de tarification d'un produit ne fonctionnait pas sur un autre parce qu'elle attendait un flux de paiement différent. Nous avons passé des jours à déboguer ces bugs fantômes.
La solution : Nous avons arrêté le copier-coller. Nous maintenons un document de modèles de composants (component patterns). Nous demandons à Lovable de construire un nouveau composant basé sur ces modèles. C'est plus long à mettre en place, mais beaucoup plus facile à maintenir.
- Utiliser l'historique du chat comme documentation
Nous nous appuyions sur l'historique du chat de Lovable pour nous souvenir des décisions techniques. Les journaux de chat sont désordonnés. Ils mélangent les changements réussis et les tentatives infructueuses. Il est difficile de trouver la raison spécifique d'un changement dans un long fil de discussion.
La solution : Nous avons déplacé la journalisation des décisions vers Linear. Nous écrivons une ligne dans Linear expliquant ce qui a changé et pourquoi. Le chat de Lovable sert à l'exécution. Linear sert aux décisions.
La leçon est simple. Ne traitez pas 16 produits comme 16 projets distincts. Traitez-les comme un seul portefeuille. Standardisez vos modèles et surveillez tout depuis un seul endroit.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Communauté d'apprentissage optionnelle: https://t.me/GyaanSetuAi