Hi @richbayliss, no worries at all - I am very much interested in all types of feedback including criticisms. This is the part of open source that I enjoy the most, because it drives deeper understanding and progress.
The whole reason this project came about was because of limitations in what open-balena can do out of the box - specifically no ability to manage multiple organizations or users (all activity was single user and single organization) and no ability to manage custom device types. This functionality exists within balena-cloud, but it appears that it is maintained in separate private repositories, which is understandable. And for this same reason, I wouldn’t expect these features to be built in to open-balena-api, at least not by the balena team, as they already exist in private repos, likely with different functionality around user lifecycles etc.
But these features, along with many others that open-balena-admin was built to address (such as remote device access, cloud management, diagnostics, remote control, etc.) are important to anyone looking to actually use open-balena in a production environment. Without it you are stuck using command line tools, API calls or building a custom management interface. And that’s for the features that are available via balena-cli or open-balena-api; for others such as managing multiple users / orgs / custom device types, you are just out of luck because the functionality does not exist in any of those tools.
For many, these feature limitations and lack of management interface are a deal breaker to using open-balena, and while there is obviously balena cloud available to address them, many parts of that system are not open source (such as the device dashboard and management interface) so for the audience who is looking for an all open-source solution, there really is no option without compromising on both functionality and ease of use - which is what led to the development of open-balena-admin.
As to your question on the dangers of working directly in the database, just my personal opinion after building this tool, but I don’t think it’s all that risky. Which is a testament to the balena engineering team, because obviously what balena as a whole is doing is very complicated behind the scenes. But managing the database itself - users, organizations, API keys, SSH keys, devices, fleets, and the various levels of labels / variables are really pretty straightforward. Many of the areas in open-balena-admin are intentionally read only, because there’s no reason to modify them directly - images is one example, there are many others. We rely on balena-cli for pushing new releases, and there would be no reason to do otherwise. But for the “basic” areas that I mentioned earlier, I don’t see a lot of risk, and if we do come across some corner cases that create problems, we can always address them in the front end. But in general, the database itself does a good job of preventing bad data from being committed, I know this from the extensive development / debugging that went into creating open-balena-admin, where in many, many cases I unsuccessfully tried to commit bad data by accident.
So, while it would have been technically possible to create portions of open-balena-admin using open-balena-api for data management instead of directly managing it in postgres (via postgrest), it kind of defeats the purpose - because we will then be limited by what data / functionality is made available by open-balena-api, and as discussed earlier there are some key limitations there which to my knowledge have no timelines to be addressed. In addition, there are extensive synergies in being able to use tools like react-admin and postgrest which provide a framework to build a seamless web interface, vs developing a bespoke front end to open-balena-api as other dashboard tools have done in the past.
And lastly, regarding this not being suitable for a production environment, my understanding is that the entire open-balena suite is not geared for a production environment. And for good reasons, with only one user (superuser) and very basic security, among other reasons, it makes sense. So I kind of view open-balena-admin in a similar light. It is far from perfect (could do a lot better with security as well, needs more testing / development in key areas), but at the same time it makes open-balena more production ready in other ways, including addressing key vulnerabilities such as single superuser access. So I think that as long as people understand what it is (an open source and customizable tool to manage your open-balena instance) and what it isn’t (a front end for open-balena-api or PineJS) I think users can make their own informed decision as to whether it’s right for them. And it’s completely acceptable to me for anyone to decide it is not right for them.
So hopefully this explains my approach with open-balena-admin, obviously the intent was not to cause any issues or concern on the balena side (I am an ambassador after all!), rather this is meant to be a tool for use by the community to allow them to get the most out of their open-balena instance, and ideally get input and development participation along the way.
If anyone has suggestions, I’m open to them and will be sharing feedback with the openBalena team.