I have succeeded in my attempt to connect my home server to the wider world.
I am in the process of getting the finishing touches in place for most of my current services, but one that I really wanted to have in place was a self-hosted wiki. I have been using Notion.so forever, so I have a lot of data over there, but part of the DIY spirit is to have control over all of our own stuff; while I enjoy trying to get this server up and running, it’s what I actually do with it and why I do what I do that matters.
The Struggle is Real
I am not a great tech. I tend to set a goal, and then research the best way to get to that goal. Once I have a map, I follow that map and upon arrival at my destination, I call the journey successful and archive the info. This means that I don’t spend a lot of time on side-trips to figure out why the map wants me to take a certain route, so while the end result is a win, looking back on the road I took, I am horrified by the complete lack of understanding on how I arrived.
Exhibit A: Traefik. Traefik, as I think I’ve mentioned, is an “edge proxy” which accepts connections to a server (in my case, on public ports 80 and 443) and then routes the requests to specific Docker containers. The cool thing about Traefik is that once you set it up it’s pretty much done; it knows about new Docker containers because the Docker containers self-register with Traefik, meaning that I can bring a new container online at any time and — assuming the config is correct — Traefik will route traffic accordingly.
It’s been this “correct config” that’s been causing me headaches. Now that I have a domain pointing to the server, and some CNAME records to divvy up the base domain into targeted sub-domains, Traefik can determine which containers should receive which requests. But the Traefik documentation isn’t super clear, especially to someone of my advanced age. I’ve flung a lot of spaghetti at the wall to see what would stick, and eventually I managed to get two competing wiki packages up and running: WikiJS and BookStack.
I had spun up an instance of WikiJS at work, and had attempted to use it as a kind of knowledgebase for my own use, at least. Because I couldn’t be guaranteed that my install would be respected (i.e. the server wouldn’t be sacrificed) I never really ran with it.
As the name implies, WikiJS is, well, a wiki of sorts. It supports Markdown, or can use a WYSIWYG editor, which I personally prefer. The layout is a bit busy as you can see above, and that’s without having comments turned on. Navigation and setting up pages are also a bit of a pain — not terrible once I get into the groove but starting out it can be hard to understand how organization works.
I like that the content spans the width of the page, though, as a lot of the time I’ll be putting in code which can sometimes run wide.
Bookstack uses a “shelves, books, chapters, and pages” metaphor for its organization. I can create shelves (development, TTRPG, writing, etc), and then books (React, Node, C#, or D&D, Starfinder, etc) which can be added to those shelves. I like this metaphor, especially since I can assign images to shelves, books, and chapters, so the UI will end up looking really cool, because that’s something that does matter.
However, I don’t think these four levels of organization are enough for my note taking style. For example, if I do make a TTRPG shelf and a D&D book, I’d have to make a chapter per campaign? I usually break campaigns down into modules, and modules into scenes, so the BookStack metaphor is coming up a bit short; I’d have to make a campaign book, which sits on a D&D shelf which has no further parent organization. I guess that could work. Also, I don’t really like that BookStack has its content in the center third of the screen, but overall I like the look and feel of BookStack a lot more than I do WikiJS.
Originally, I thought I’d roll with WikiJS, but after looking at these images and writing these words, I might choose BookStack mainly because it’s cleaner to look at, the WYSIWYG editor is a tad bit nicer, and I like the organizational paradigm. Hell, I could totally run both, as each has its own container (and its own database container, which is kind of annoying), but I don’t really want to split the difference.