Bulk actions
A very late note this week — I was babysitting my nine-month-old niece, who is very sweet and also imparted upon me a newfound respect for folks who manage to find time and space for deep work while being an active parent.
The settings work I discussed last week is ready for launch (yay!) but I didn't want to babysit the launch while also literally babysitting (both due to lack of focus and, as I was soon to discover, lack of sleep), so I found a bit of low-priority work that would be fun to noodle on between stroller & crib sessions.
This was bulk actions, a primitive that I am fairly confident every SaaS has reimplemented. Buttondown already has a kind of bulk action, which you can see when you select a bunch of subscribers and/or emails:
This is fine, but these flows are very naive: at a high level they take the selected objects and pass them to a view called, like, BulkApplyTagView which then runs through each object in parallel. This approach has two flaws:
- For expensive operations, you can run into timeout issues (what if it takes thirty seconds to update fifty subscribers?)
- You can't do what you often really want to do, which is apply a bulk operation for all subscribers, not just the ones in the current page.
To handle either of these, you need to move the operation from being handled in the band of the HTTP request to out-of-band. This is rote work, which is what makes it perfect for groggily hacking on over the course of a weekend — it doesn't require anything clever, it doesn't require a big monitor, it's just CRUD. You build a BulkAction model; you shift the logic in the HTTP requests into a pure function; you make those HTTP requests create the model instead of actually applying the logic themselves; et cetera.
Kent Beck said something along the lines of "make the work easy and then do the easy work", and so my goal for the first chunk of code was just to port over the existing functionality — which is to say don't worry about actually handling those two flaws, just build out the infrastructure to make it easy to handle them down the line. And that shipped as of an hour ago!
Why not actually fix the flaws? Because they require a good amount of consideration; as soon as you shift to out-of-band you open yourself up to a bevy of edge cases. What happens if a bulk action fails? What happens if you create concomitant bulk actions? All of these are solved problems — there's more than enough prior art here. But I want to give those details a bit more nuance and focus, and I owe that nuance and focus to getting Settings and 2.0 work across the line this week and into this weekend.
This is a lot of words to say: not much shipped last week, and this week will be spent shipping old work instead of making new work. But I can feel a world — maybe two weeks away, maybe three — where all the scaffolding is live, and it is very close.
(One other quick hit: I started a new advertising romp on the first of the month, the details of which I will elaborate on later. It was a whopping $84/mo commitment for which I have received three $9/mo conversions (three days into the commitment). If that trend holds, there will be a lot more advertising in my future.)