Perspectives for Vigilant Crypto Snatch
I have been working on the Vigilant Crypto Snatch program for a while now. It has started as a command line utility and eventually got extended with a Streamlit web interface for simulation. Recently I added a GUI with the Qt framework. The user experience is now scattered over three different interfaces. After talking to product managers at my company about our company's product, I learned to view programs in a new angle. So far I would see it from a programming perspective, and with technical boundary conditions. But they view it completely differently. One of their view angles are jobs to be done. And this made me reflect over my hobby project.
Initially, there was just one user, Chris. Eventually I started to use it myself, but not as enthusiastic. Features were driven by his ideas, and I would implement them in a way that made sense. He uses it on a Raspberry Pi miniature computer that runs 24/7, and just with a command line. This made certain choices pretty clear: There was no point in making a graphical user interface, and it would be an expert system where editing a configuration file was just fine.
Over time, a flock of a few users has formed. They were all technically skilled, and therefore the command line was fine. A few more ideas came up, eventually a simulator was requested. But the NumPy library that I used doesn't work on 32 bit ARM, because the NumPy team doesn't supply packages for that particular architecture. So I deployed that to the Streamlit cloud. But people started to like the web user interface, and asked to have it for the main program as well.
Eventually users came who wanted to use it on Windows and Mac, and also wanted to have a graphical user interface. I started to make one. But again due to architecture restrictions, it would not run on the Raspberry Pi. The user base is now split, and the most vocal users don't use the GUI, which feels demotivating after putting in all that work. They said that if one could control a remote insurance with that, they would be really interested in that. But running 24/7 is more important than the GUI.
So there are now three interfaces. One runs on a Raspberry Pi, all three run on a laptop, and one can run in the cloud without installation. Neither interface contains all the features, some simulation things are only on the Streamlit Interface.
Taking a step back, I can picture of a way to unify all these use cases and platforms: A web service. This way the users could run a service on any platform they like, either a Raspberry Pi, a cloud service or their local laptop. Then they use a web browser to access it. The service would keep running, even if the GUI wasn't attached. The problem is that I'm really out of touch with the web stack. I could create something in Django, HTML and Bootstrap CSS, and that would likely be enough. But a modern and interactive feel would need JavaScript, which I have been reluctant to learn until now. Another issue is that all simulation would have to run on the Raspberry Pi, which is much slower than the laptop. However, people could start a server on their desktop, if that was really bothering them.
Another way of decoupling the service and the user interface would be via an API. I could for instance use gRPC to have a service running and control it via a GUI written in Qt. People would configure and monitor the service via another computer running the Qt GUI. Installation would be more cumbersome, because there has to be Python available on both sides. Having just the Raspberry Pi isn't enough. Conflicting versions of service and GUI would mean trouble with the protocol, if not versioned correctly. And it wouldn't run on mobile devices.
So it seems that a web solution would be the best approach to get everything. However, I am not skilled with the technology stack, such that it would be massive investment of my time. Also it would basically make the Qt GUI obsolete, and this feels like a sunken cost.
The architecture of the program is such that the core logic can be kept, and a web service could be built as one component which uses the core. I might at some point try that, but at the moment I don't see myself investing so much more time into the project.