Au départ, LowFlow était en HTML.
Et pendant un bon moment, ça suffisait. Je construisais mon journal, j'ajoutais mes fonctions, je testais mes idées et je faisais évoluer l'interface autour de mes propres besoins.
Puis le projet a changé de direction. À un moment, j'ai décidé que LowFlow ne resterait pas seulement mon outil personnel. Je voulais en faire un produit. Je voulais pouvoir le distribuer. Le vendre. Le faire installer proprement sur Windows.
Et c'est là que la question de l'application desktop est devenue sérieuse.
Le choix : Electron ou une app hybride
Il fallait maintenant prendre le journal HTML et lui donner une vraie enveloppe desktop. Electron était une option évidente. Mais je ne voulais pas transformer un journal léger en une application beaucoup plus lourde simplement pour pouvoir créer un exécutable.
Je voulais garder l'esprit du projet : simple, rapide, léger, et le plus proche possible de Windows.
J'ai donc choisi une app hybride. Le principe me convenait beaucoup mieux : conserver mon interface web, mais l'intégrer dans une application native beaucoup plus légère. Ce choix allait devenir une partie importante de l'identité de LowFlow.
Aujourd'hui, le cœur de l'App tourne autour de 6 Mo. Mais arriver à cette simplicité n'a pas été aussi simple que prévu.
Le problème n'était pas l'application
L'application elle-même restait petite. Le vrai problème était tout ce qui allait s'accumuler autour. Les trades. Les captures d'écran. Les historiques. Les données nécessaires au replay. Les sauvegardes. Et tout ce qu'un trader peut accumuler après plusieurs mois ou plusieurs années d'utilisation.
Au début, je ne savais même pas que cette gestion allait devenir un problème aussi important. Puis j'ai commencé à atteindre les limites de ce que je pouvais laisser vivre directement autour de l'application. Et là, j'ai passé presque une semaine à chercher une solution suffisamment simple pour ne pas rendre LowFlow instable.
Garder l'App légère
La solution a finalement été de séparer clairement l'application de ses données. LowFlow ne devait pas devenir un entrepôt. L'app hybride devait rester le moteur et l'interface. Les données du trader devaient vivre dans leurs propres emplacements.
J'ai donc construit une logique de chemins dédiés. Les trades ont leur emplacement. Les photos ont leur emplacement. Les historiques ont leur emplacement. Les données utilisées pour le replay peuvent être conservées séparément. Les sauvegardes aussi.
Ça permet à l'application de rester légère même lorsque le trader accumule beaucoup de données.
Les chemins sont contrôlés depuis les paramètres
Je ne voulais pas non plus enfermer le client dans une structure qu'il ne comprend pas. Les chemins peuvent être gérés directement depuis les paramètres de LowFlow. Le trader sait donc où ses données vivent. Et il peut organiser son stockage en fonction de son propre environnement.
C'était important pour moi. Le logiciel organise. Mais les données restent chez le client. Trader choisit.
Les données appartiennent au trader
Cette architecture permet aussi au client de faire ses propres sauvegardes. Il n'a pas besoin de dépendre d'un serveur LowFlow pour conserver son historique. Il peut créer ses propres copies. LowFlow peut aussi générer des archives ZIP datées, ce qui permet de conserver plusieurs sauvegardes dans le temps.
Un journal peut contenir des mois ou des années de travail. Je voulais que le client puisse garder cette histoire indépendamment de l'application elle-même.
Puis les addons ont augmenté le volume
Les addons de LowFlow ne récupèrent pas seulement une ligne de trade. Ils peuvent récupérer les trades et leurs sorties, les captures prises pendant le trading, et les données historiques qui permettront ensuite au client de faire son propre replay.
Ça représente beaucoup plus d'information qu'un simple CSV de transactions. Et c'est exactement pour ça que cette architecture locale était nécessaire. L'application reste autour de quelques mégaoctets. Les données, elles, peuvent évoluer avec le trader.
Une semaine de travail pour que rien ne se passe
C'est une des réalités amusantes du développement. J'ai passé presque une semaine à résoudre la gestion locale pour obtenir quelque chose qui, aujourd'hui, paraît presque banal.
Le client ouvre LowFlow. Ses données sont là. Ses images sont là. Son historique est là. Le replay peut utiliser ses fichiers. L'application reste légère. Et elle ne plante pas.
Quand tout fonctionne correctement, cette architecture devient presque invisible. Mais sans elle, le reste du projet n'aurait pas pu continuer à grandir proprement.
Et vendre une application crée un nouveau problème
Passer de HTML à une App avait transformé LowFlow en véritable application Windows. Mais le fait de vouloir la distribuer et la vendre amenait maintenant d'autres questions.
Comment gérer les clients ? Comment gérer les licences ? Comment activer une installation ? Comment savoir quelle version est utilisée ? Comment envoyer les mises à jour ? Et comment éviter de laisser toute cette logique uniquement sur la machine du client ?
À ce moment-là, garder LowFlow uniquement local ne suffisait plus. Il fallait construire une nouvelle couche. Le serveur et l'API.