May 4, 2021
(Fool that I am, I wrote this on Sunday and checked it off of my todo list without actually scheduling the dang thing. Apologies!)
All of that is to say, I think the DNS work is a worthy goal for the week ahead. Once that lands, I think I’ll be in a good spot to spend May on dessert work: JavaScript exfiltration, support for attachments, that sort of thing.
My streak of (somewhat successfully) calling my shot continues! Here is the "after" of the DNS onboarding pane:
The latter has a lot of advantages:
- It’s built into the design system and low on bespoke styling. I don’t know what exactly possessed me in 2019 to decorate every single subpane in sky blue, but I’m slowly making amends.
- It tackles the two most pernicious edge cases I mentioned last week — conflicting MX records and “double suffixing” of the DNS key. (You can of course make the argument that I could handle both of these in the old style, too.)
- Behind the scenes, the state space governing these modals is built into Vuex, meaning that testing different scenarios and handling issues with HTTP is much easier.
I had to cut myself off from going too refurbish-mode with this part of the codebase — particularly the backend. The database entries governing all of this stuff is still ultimately newsletter.email_domain (set to a value like newsletter.jmduke.com) and newsletter.delivery_provider (set to a value like ses or mailgun). This is...not awful, but messy — it means every time I want to check of a domain is correctly set up I have to query a third-party API, and every time I want to write invariants around custom domains I have to... query a third-party API a lot.
I’ve written before how one of the main architectural and stylistic changes of Buttondown’s backend over the past year or so has been promoting fields to first-party objects, and the same thing could be easily done here. Really, what I want is a SendingDomain object that a given newsletter (or newsletters!) ties to that we can persist a lot of this data on.
...But I didn’t have the time. One of the advantages of week-long sprints, I think, is that it does force me to cut scope on things pretty aggressively and focus less on the Perfect Solution and more on how to triage my time.
That being said, it’s important to carve out time for the perfect solution. One of the architectural things that I haven’t been a huge fan of lately is how I handle Stripe Connect (which governs paid newsletters), and my goal for this week is to improve that situation. “Improve that situation” is a little wishy-washy of a deliverable — do I just ship a new set of models and call it a day? — but I don’t think there is a central thing to deliver so much as a melange of a smaller improvements to make paid newsletter onboarding less of a tightwire act of manual shell scripts and more something that I can write checkers and documentation around.
(On the documentation front: I am starting to sniff around what it takes to hire an operations support person or virtual assistant. This is of course a terrifying proposition in of itself, but every essay I read on the subject prefixes things with “make sure you have documentation & runbooks beforehand!” which...I am deficient in, so I’ll be starting to divert more energy towards that as well.)