Al principio, LowFlow era HTML.
Y durante un buen tiempo, eso era suficiente. Construía mi diario, añadía mis funciones, probaba mis ideas y hacía evolucionar la interfaz según mis propias necesidades.
Luego el proyecto cambió de dirección. En un momento dado, decidí que LowFlow no se quedaría solo como mi herramienta personal. Quería convertirlo en un producto. Quería poder distribuirlo. Venderlo. Hacer que se instalara correctamente en Windows.
Y ahí fue cuando la cuestión de la aplicación de escritorio se volvió seria.
La elección: Electron o una app híbrida
Ahora tenía que tomar el diario en HTML y darle una verdadera envoltura de escritorio. Electron era una opción evidente. Pero no quería convertir un diario ligero en una aplicación mucho más pesada solo para poder crear un ejecutable.
Quería mantener el espíritu del proyecto: simple, rápido, ligero, y lo más cercano posible a Windows.
Así que elegí una app híbrida. El principio me convenía mucho más: conservar mi interfaz web, pero integrarla en una aplicación nativa mucho más ligera. Esa elección se convertiría en una parte importante de la identidad de LowFlow.
Hoy, el núcleo de la App ronda los 6 MB. Pero llegar a esa simplicidad no fue tan sencillo como parecía.
El problema no era la aplicación
La aplicación en sí seguía siendo pequeña. El verdadero problema era todo lo que se iba a acumular a su alrededor. Las operaciones. Las capturas de pantalla. Los históricos. Los datos necesarios para el replay. Las copias de seguridad. Y todo lo que un trader puede acumular después de varios meses o años de uso.
Al principio, ni siquiera sabía que esta gestión se convertiría en un problema tan importante. Luego empecé a alcanzar los límites de lo que podía dejar vivir directamente alrededor de la aplicación. Y ahí fue cuando pasé casi una semana buscando una solución suficientemente simple para no volver inestable a LowFlow.
Mantener la App ligera
La solución terminó siendo separar claramente la aplicación de sus datos. LowFlow no debía convertirse en un almacén. La App debía seguir siendo el motor y la interfaz. Los datos del trader debían vivir en sus propias ubicaciones.
Así que construí una lógica de rutas dedicadas. Las operaciones tienen su ubicación. Las fotos tienen su ubicación. Los históricos tienen su ubicación. Los datos usados para el replay pueden conservarse por separado. Las copias de seguridad también.
Esto permite que la aplicación siga siendo ligera incluso cuando el trader acumula muchos datos.
Las rutas se controlan desde los ajustes
Tampoco quería encerrar al cliente en una estructura que no comprende. Las rutas pueden gestionarse directamente desde los ajustes de LowFlow. El trader sabe entonces dónde viven sus datos. Y puede organizar su almacenamiento según su propio entorno.
Eso era importante para mí. El software organiza. Pero los datos se quedan con el cliente. El trader elige.
Los datos pertenecen al trader
Esta arquitectura también le permite al cliente hacer sus propias copias de seguridad. No necesita depender de un servidor de LowFlow para conservar su historial. Puede crear sus propias copias. LowFlow también puede generar archivos ZIP fechados, lo que permite conservar varias copias de seguridad a lo largo del tiempo.
Un diario puede contener meses o años de trabajo. Quería que el cliente pudiera conservar esa historia de forma independiente a la aplicación misma.
Luego los addons aumentaron el volumen
Los addons de LowFlow no solo recuperan una línea de operación. Pueden recuperar las operaciones y sus salidas, las capturas tomadas durante el trading, y los datos históricos que después le permitirán al cliente hacer su propio replay.
Eso representa mucha más información que un simple CSV de transacciones. Y es exactamente por eso que esta arquitectura local era necesaria. La aplicación se mantiene en unos pocos megabytes. Los datos, en cambio, pueden crecer junto con el trader.
Una semana de trabajo para que no pase nada
Esta es una de las realidades curiosas del desarrollo. Pasé casi una semana resolviendo la gestión local de datos para obtener algo que, hoy, parece casi trivial.
El cliente abre LowFlow. Sus datos están ahí. Sus imágenes están ahí. Su historial está ahí. El replay puede usar sus archivos. La aplicación sigue siendo ligera. Y no se cae.
Cuando todo funciona correctamente, esta arquitectura se vuelve casi invisible. Pero sin ella, el resto del proyecto no habría podido seguir creciendo correctamente.
Y vender una aplicación crea un nuevo problema
Pasar de HTML a una App había convertido a LowFlow en una verdadera aplicación de Windows. Pero querer distribuirla y venderla trajo ahora otras preguntas.
¿Cómo gestionar a los clientes? ¿Cómo gestionar las licencias? ¿Cómo activar una instalación? ¿Cómo saber qué versión se está usando? ¿Cómo enviar las actualizaciones? ¿Y cómo evitar dejar toda esa lógica únicamente en la máquina del cliente?
En ese momento, mantener LowFlow puramente local ya no era suficiente. Había que construir una nueva capa. El servidor y la API.