I had a look this morning and managed to push to the device for testing. Hopefully I will not be so far into the UI to make it worth going through the VM process, but thanks for the offer.
Here are my two-cents:
NGINX branch:
It always seemed a little cumbersome to have to build another backend for a frontend to communicate with just to then be passed to a second backend (the supervisor). So here I used an NGINX reverse proxy to bring the Supervisor on to an open port, then used the same NGINX instance to host a UI which communicated with the supervisor on the reverse proxy port. Pros: great image size, around 15mb, Cons: security having opened the supervisor on a port, and not much room to grow. If the goal was to pursue other features like CPU usage that isn’t on the Supervisor API it would be problematic. Moreover, no means of adding a useful authentication at a later date.
Main branch:
This is probably a little more logical. It has an ExpressJS backend but a super simple one. The idea is it acts as a proxy for Axios to the main UI and then all the work is done on the UI itself. It means less code base to maintain and problems to debug (hopefully). Downside is the container with Node in it is 100+mb, but because the express js backend is so simple it should be relatively easy for someone to create the same link in Flask (Python) or other languages, then reuse the same interface out of the box. Would mean more contributes to the frontend. And then by having different languages, image size isn’t so much of a problem as people can align it with whatever image they already have on the device and benefit from Docker/balena-engine image sharing. It also has the potential to add in future features like authentication, and reading local CPU stats etc (while at its core is still very portable to other languages and the UI interchangeable).
I put all the Supervisor paths in one file for easier maintenance. Then built the UI example in Quasar because it has a whole bunch of easy to drop in components for the UI development. If hoping to get more open source contributions then thinking the code really needs to be as easy to access and manipulate as possible (take wifi-connect for example that is in Rust, is popular but has had no contribution as it’s a rarer language). Quasar setup allows for some other drop-in features, so added i18n for future proofing, I’m sure there are lots of language speakers in the community.
Not sure how I landed in the UI thing, but was a bit of fun tinkering for a while. Also not sure if drifting off of @keenanjohnson question. Is any of this helpful? If you are putting something together could it be towards a generic base for the community?