in search of elegant web architecture
from the salt mines
In my work as a professional software developer, I've had to get my hands dirty with some of the most janky software. The jankiest of it is probably the web software. Even if it looks weird on the surface, I bet if you got a look at the source code, you would throw up.
React interfaces with way too many moving parts and no type safety? Angular interfaces with type safety but even more moving parts and an architecture you can't even wrap your head around even after working on it for a month? Legacy Visual Basic ASP.NET site making SQL calls willy-nilly and with no architectural discipline whatsoever? Check; check; and check.
In a work situation, especially working with a larger product where you can only make small incremental changes, you do your best to bring proper design and executional attitude to the table and make working with a system you otherwise wouldn't touch with a 10-foot pole somewhat bearable (sometimes you can even make some neat additions!).
from my own back yard
Then, sometimes, the most terrible design decisions are made in your own backyard. The first iterations of my website, like those of many a web-design enthusiast, were written from scratch, line-by-line, in literal HTML and CSS. My next phase was a static site generator written in
bash and it was not pretty. Sure, it was decently powerful, but for as many lines of code as it was, it made me sick after a couple years and I moved on to something more elegant.
That more elegant system is eureka, which is based on the 100r.co SSG and inspired by the UNIX philosophy and the works of many fine software artists. Now that it's been fine-tuned and the necessary functionality has been set over the past year or so, I really enjoy it and don't think I'll be changing to any other system to run my personal website anytime soon (I do have to give another go at getting compound pages [ie, those with transcluded content] to have proper edit dates though).
Still, if I was going to build a website that was any more than a blog, wiki, and some media storage, I'd go with something a bit more... dynamic. For a freelance project where I had total architectural control (a pity I had to leave the project and scrap all that work), I used Django, and while I probably wouldn't use it again due to my perspective on Python (it's for prototyping or making GUI wrappers on top of native code; it's not for web development, don't kid yourself [then there's
numpy but that's another story...]), it was very pleasant to work with. And there's a lot to be said for how easy it is to build APIs with Express.
quartzgun, locked and loaded
Enter quartzgun - my attempts at making a web framework that I would want to use. It's written in Go, and it takes what I enjoyed about Django and Express and combines it with the elegance and performance of Go while being just opinionated enough to enforce good habits from the start.
What good habits, you may ask?
Well I was aiming for stuff like these:
- Separation of concerns (business logic vs UI)
- Functional design - pass data along instead of touching it in-place
- Modularity (Go's type system is really nice for this)
- Succinct, readable code with minimal bloat
- Agnosticism - it can be used to build APIs and frontends
The Go language does some heavy lifting with regards to much of this, but it takes deliberate and careful design in any case to come to something that makes the cut in all these areas. I believe quartzgun meets these criteria, and it's thanks to my experience with systems that are less than ideal as well as those which inspire me with their beauty and usefulness.
Now that I've got the base laid and taken care of the common middleware, I'm excited to see where I can go from here. As a proof-of-concept I want to start with a web frontend to eureka, and from there, the sky's the limit.