Opencloud is the was to go from the established systems in my opinion. https://github.com/opencloud-eu
File sharing and -management for me has a higher level of trust and stability requirements. Syncin with four developers and “doing everything” while based on typescript makes me suspicious - but I haven’t tried it hands-on.
Traefik and caddy were mentioned, the third in the game is usually nginxproxymanager.
I’m using both traefik and nginx in two different setups. The nginxproxymanager can be configured via UI natively which makes checking configurations a bit easier.
Traefik on the other hand is configured easily within the compose itself and you have everything in one place.
This turned out to be tiresome though if you don’t have a monolithic compose file - that’s actually even hr history why I switched to npm in the first place.
I don’t have any experience with caddy so can’t provide anecdotal insights there.
I really like it already so take this as an alternative, not as improvement:l. I don’t have a good eye for aesthetics anyway don’t his is more about structure.
Personally I switched from a single dashboard to purpose driven hubs - I can’t imagine a situation where I need my infrastructure and my calendar at the same time regularly for example.
Another point is context typing: your release checker is quite far away from your appointments and calendar. It looks to me to be sorted by content rather then function (i.e. it’s entertainment so it’s next to YouTube). The same is true for your interaction patterns. There is a lot of visual information which I’m sure you’ll rarely interact with but instead consume. And then there are clearly external links, both bottom left (opencloud, tooling) and top right (external media) in addition to your own self hosted content.
My suggestion is therefore a process instead of a change: Note down when you consume which features of this awesome dashboard together for a few days. Then restructure the content of the whole dashboard based on your usage patterns - either as a new Monolith or even experimenting with splitting it.
I even suggest using a different medium then your usage device (if it’s a desktop PC mainly use pen and paper, if it’s your laptop use your phone, if it’s your phone you use this dashboard on then you might have different problems :D)
Hey,
Person here who despises electron apps in part because of the memory footprint and in part because I don’t like neither chromium nor node.js - personal preference mainly.
From your description I have the feeling that it’s unclear to your user base if electron is set or up to debate. There is only a thin line between “explaining” and “defending”.
In terms of communication: “We’re using electron as foundation because it allows us to focus on development. We’ve considered alternatives like Tauri and XYZ and opted in favor of electron.”
If there are situations that might make you rethink state those as well (“if someone provides a proof of concept via XYZ that an alternative is faster by y% while enabling us to still use (your core libraries and languages) we might consider a refactor.”
If you’d engage with me after an electron rant on your codebase you’d just raise my hope that I might change your mind! Don’t give people hope, don’t feed the trolls and do your thing!
Just please be honest with yourself: your app doesn’t use “50 to 60 MB”, it uses 500MBish on idle because of your choice. And that’s okay as long as you as developer say that it is.