MichaIng
Add WhoDB to software list (database management tool)
Creating a software request
Formal software information
- Software title | WhoDB
- Short description | Database management tool with AI integrations
- Official URL (if available) | https://whodb.com
- GitHub URL (if available) | https://github.com/clidey/whodb
- (Official) install documentation | https://docs.whodb.com/installation
Are there similar/alternative software titles available with DietPi-Software?
- phpMyAdmin
What makes your requested software better than the above solutions, if available?
- Supports NoSQL databases alongside SQL
- Has AI integration with OpenAI, Anthropic, and Ollama (user has to install it first)
- Small image size
- Built to be ran in the browser, so good for self-hosting operations and people with home servers
How can DietPi make the installation easier or compatible, than following the install instructions or do APT installation, if available?
- The easiest way to install is via Docker, as it comes with an ARM64 image. This does require Docker to be installed beforehand. There's also an AppImage version but I'm not sure how those perform on Raspberry Pi/etc devices. Happy to discuss alternatives, it's built with Go and React, perhaps a more native executable can be created.
Can you provide the installation steps that you would suggest DietPi-Software to do?
- Install docker
docker run -d --name whodb -p 8080:8080 clidey/whodb:latest- Open browser to 8080 and it's available.
Are you willing to help maintaining the software installation, e.g. in case of needed setup changes due to updates etc.? This is not needed, but could speed up our decision to implement it, as man power is always a topic :wink:.
- Yes of course. I am one of the owners/maintainers of WhoDB, so happy to help/maintain it.
Usually we don't go to add Docker app to our software catalogue
I had seen this: https://github.com/MichaIng/DietPi/blob/ccdda4fd3071d8a4d0ce514d86763b8cf39ab3de/dietpi/dietpi-software#L11934..L11946 using Docker so seemed fine.
Is there an alternative format that would work better?
This is for Portainer as an exception because Portainer can enable user to manage their container. Best would be a native executable. But seems WhoDB is not providing any, even is stated at their online docs
Hmm, the docs actually contain a pre-compiled binary section: https://docs.whodb.com/installation#binary-installation This also makes pretty much sense, because Go is easy to build for various platforms with its own build tools. But those instructions do not work, since the binaries do not exist since several releases/tags. They do exist for v0.47.0 and v0.48.0, then a number of tags without any release assets, and now only Snap and AppImages. This is so totally unnecessary, since the AppImage essentially contains the binary only 🙄. I mean we could download the AppImage and extract the binary from it, and wrap a systemd unit around it. Or we just provide own APT packages 🤔.
Generally, I like the idea of a common web UI for all common database systems. Also for people not used to SQL, the AI-powered natural language query sounds interesting. It guess this is indeed something an LLM can do quite reliably.
Yeah we're still ironing out the docs and everything, the release pipeline on Actions is new to us so still figuring out some things.
I'm happy to add a step to do an arm64 compiled binary for this, which then could be downloaded from the release assets. Would that suffice?
yes, if we could wish for, ARM, ARM64 and AMD. I guess RISC-V would be to much to wish for. A native executable would make it easy to implement
Did not recognised before, but you are one of the contributors to WhoDB? right?
All for Linux? Or do you support others? (https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63)
And yes I am one of the contributors.
Alright! Sounds good :) I'll work on it sometime this week/next, will come back here to let you know and if all looks well, we can take it from there.
sounds good. thanks for all the work you guys do, I'm a big fan of DietPi
Ah you are one of the maintainers, that is handy 👍. Yeah, for standalone Go software, single binaries would work best for us. As I mentioned above, we'd wrap a systemd unit around it with most sandboxing active.
In addition to amd64 and arm64, we support riscv64, and ARMv6+ARMv7 which is both covered with Go linux/arm arch. If you consider adding those as simple binaries, should be nothing more than GOARCH=riscv64 go build/GOARCH=arm go build to have those cross-compiled on any Linux host.
I figured the project seems to still experiment how to best distribute the software, with the changing assets. Out of interest, what was the reason behind providing the AppImage? Docker makes sense given its popularity, and that it is cross-platform, but AppImage is Linux only, and the typical reason to ship software bundled with its dependencies does not apply here.
I wanted another way to have WhoDB on Linux systems that wasn't via Docker or Snapcraft. On Windows and Mac the stores are fine because they're installed on every Windows/Mac system out there.
On Linux, I was familiar with Snapcraft because of Ubuntu but I remember it got a lot of dislike and I'm not sure how widespread it is among the other distros. So it seemed like having an AppImage would be a nice addition in case someone didn't want to mess with Snap.
I wanted another way to have WhoDB on Linux systems that wasn't via Docker or Snapcraft.
But why then not just with the binaries that were provided in earlier releases? Generally, IMO any container'ish distribution in case of a standalone binary is sort of unnecessary overhead on Linux. Docker, as said, is just so popular even for cases that do not make sense IMO, but this alone + cross-platform capability is an argument from maintainer side, and stricter sandboxing from admin side. But why would someone choose the AppImage over the plain single binary?
That’s a fair point!
Back in the early days when we did have a standalone binary, launching it meant running it in a terminal and then manually opening the browser and navigating to the port. My cofounder and I never really liked that flow. We experimented with having the app auto-open the browser, but it still felt a janky.
Using a container-ish distribution ended up being a nice middle ground: it opens in its own separate window without requiring the user to open the browser and navigate to the URL, and the experience feels more like a proper app. The trade-off is a larger file size, but I think it should be a smoother experience.
Time will tell, we released the mac/windows/snapcraft builds like a week or two ago.
One question: Does WhoDB require a desktop environment, or can it be started via a systemd service and accessed via a browser? Most users use DietPi in headless mode.
And which port does it use? For DietPi, we need a port that is preferably not 80/443 and is not already occupied by another application. Otherwise, we need the option to configure the port ourselves.
WhoDB does not require a desktop environment, it can be accessed by a browser. The desktop environment is only for the store distributions - docker images are headless and users access it in the browser normally via port 8080 (default). The binary will behave this way too.
Port can be set by an environmental variable PORT. Is that okay?
I guess I need to test it: So when the AppImage is "started" from a desktop, it opens the browser automatically?
Usually I would set it up as network system service, running on a server, hence naturally accessed from other GUI hosts in browser. But if a desktop environment is installed, we could create some desktop icon to open basically 127.0.0.1:<port> in browser, preserving the app'ish feeling.
@MichaIng the native binary did not contain a frontend, access would be via web browser. I don't thing we need to deal with AppImage at this point
The AppImage would open its own window (not within a browser).
I'm genuinely happy to keep it a headless binary and let DietPi users access via the web browser.
Hey guys, I added the Linux executables in the last release - https://github.com/clidey/whodb/releases/tag/0.77.0. I have a RPI 5 and tried out the arm64 executable which did launch and then was accessible through my browser.