About 2 years ago, I revamped my hub site using Django. This was the first step (I had hoped) toward a unified architecture for all my websites. It didn’t turn out that way, but this project is still simmering on the back burner.
Most content management systems are designed as monoliths with turnkey features. This is a wonderful boon for authors who want to, for example, throw up a blog, as they have a low-overhead solution they can deploy and quickly start publishing with. But it presents problems if you want to customize them (anything outside of the turnkey modules and settings available) because you have to work around the existing features before you can implement your customizations. And it presents problems when managing multiple websites because now you have to manage multiple independent monoliths and often can’t even benefit from automation.
I was hoping that my play with Django would be the beginning of a new relationship that would allow me to address these problems. Unfortunately, I was unhappy with where Django left me (and my hub site has been growing stale since then). In the meantime, I got a new job, which completely dominated my life for the better part of two years. (That is the explanation for my extended absence.) Then I got laid off in a downturn of pandemic proportions—literally.
But my dream of a unified website architecture never died. And I’d like to lay out the business case (as it were) for this solution and the requirements it will need to meet. I’ll go further down the road in a later post and talk about architecture options.
