Avatar

troy

troy@programming.dev
Joined
0 posts • 7 comments
Direct message

I’ve always seen these self hosted S3 API compatible services as something a developer would use for testing.

Could maybe simplify the solution with https://syncthing.net/ or https://restic.net/ for self hosted backups.

permalink
report
reply

Paperless will store documents in plain text. Maybe one could write a small webserver or extend Paperless to serve an RSS feed that could be consumed by Yacy.

permalink
report
reply

For a couple reasons

  1. Store and version configs in git. I realize unRAID provides flash drive backup (using git also), but this allows me to spin up my setup on another machine that may not be running unRAID. Helped recently when I switched away from Proxmox.

  2. Allows me to group services with their dependencies. ( e.g. postgres, redis, etc ) Also can help isolate service groups from each other. Avoiding port conflicts on common db ports for example. Downside being may have more than one database, redis, etc.

Note, there is an unRAID docker compose plugin so you can still get easy access management buttons to start, stop, view logs, and edit services.

permalink
report
parent
reply

I have a very similar setup minus the iot and metric related services. I’m managing the services with Docker Compose on unRAID.

permalink
report
parent
reply

Good point, if supporting JS disabled browsing is a goal, SSR is a must.

re languages If doing SSR, language matters. If doing CSR, statically generating site, it matters less. For example, there are more hosting options for PHP than Rust. There are even more hosting options for static assets (eg CDN).

permalink
report
parent
reply

The power of Social Media is the community. Coupling the UI with Rust seems like it would prevent the larger community from contributing. I’m interested in both web and Rust, but have zero interest learning a Rust JSX variant.

Why not static site? Could have a themes folder where admins could drop their static themes. Also, would allow admins to host markup and Lemmy API on different hosts.

permalink
report
reply

Probably want to keep services with different life cycles in separate docker compose files to allow you to shutdown/restart/reconfigure then separately. If containers depend on each other, then combining into compose file makes sense.

That said, experimenting is part of the fun, nothing wrong with testing it out and seeing if you like it.

permalink
report
reply