June 20, 2022
A bit more about the new marketing site
I mentioned last week that I am tooling around with a new marketing site. The reasons for this, in no particular order:
- getting to extricate the marketing site from the core application codebase
- better SEO (and outright performance)
- I am awful at forcing myself to do "marketing" and the only way I can incentivize myself to do it is to cloak it in layers of vaguely interesting technical work
- I'd like a bit of a design refresh, and the code churn of doing so is almost equivalent to an entirely new stack
This isn't going to be super high priority work — the goal for the month is still to get done to 200 issues on the roadmap. (More than halfway there!)
I wanted to talk a bit about my harebrained scheme to actually deploy this new site, because it's trickier than one might assume.
Most applications have a very sensible approach:
1. computer.com points to the marketing site
2. app.computer.com points to the actual application
I get no such luxury, since computer.com/username (or, in this case, buttondown.email/username) needs to point to the actual application since its where subscription forms & online archives live. (Also, everything's on Heroku at the moment — creating its own little wrinkle.)
I am not going to pretend to be clever or knowledgeable about routing, deployment, or DNS things, and I had no immediately obvious way to solve this.
A terrible idea slowly started to form in my mind that might work: deploy a Docker container running HAProxy to flip between the marketing site and the application site depending on the path. This assumes a lot of things — most notably, that it's trivial to figure out if something belongs on the marketing site or not depending on the route — but I found a very old article purporting to do something similar so I had some hope.
An afternoon of madcap tinkering later, I got a proof of concept working! (The proof of concept will be open-sourced, of course — as will the marketing site itself.)
This entire enterprise gave me a bit more confidence that Heroku's the part of my technical dependency stack that feels the weakest. Buttondown's approaching a pretty non-trivial number of "services":
1. marketing site
2. API
3. webhook consumption frontend
4. load balancer
5. core application
6. admin interface
With one or two (demo site, potential serverless email-sending lambda) along the way in a few months as well.
Thankfully, a lot of this buildout is pretty transferable to EC2 or whatever newfangled deployment option I go with — Docker is just Docker.
Better filtering
Right after I finish up writing this, I get to spend my afternoon reviewing a PR with some great new filtering functionality:
I am thrilled about being able to land some of this work, though it requires a lot of thinking about how to handle complex search filters on the backend (and the PR thus far is just frontend implementation.) I've been spending some time looking at some of the tools with filters which I like most — er, maybe like most is less accurate than find most utile.