Making the Clearleft podcast is a lot of fun. Making the website for the Clearleft podcast was also fun.
Design wise, it’s a riff on the main Clearleft site in terms of typography and general layout. On the development side, it was an opportunity to try out an exciting tech stack. The workflow goes something like this:
- Open a text editor and type out HTML and CSS.
Comparing this to other workflows I’ve used in the past, this is definitely the most productive way of working. Some stats:
- Time spent setting up build tools: 00:00
- Time spent wrangling the pipeline to do exactly what you want: 00:00
- Time spent trying to get the damn build tools to work again when you return to the project after leaving it alone for more than a few months: 00:00:00
I have some files. Some images, three font files, a few pages of HTML, one RSS feed, one style sheet, and one minimal service worker script. I don’t need a web server to do anything more than serve up those files. No need for any dynamic server-side processing.
I guess this is JAMstack. Though, given that the J stands for JavaScript, the A stands for APIs, and I’m not using either, technically it’s Mstack.
Netlify suits my hosting needs nicely. It also provides the added benefit that, should I need to update my CSS, I don’t need to add a query string or anything to the link
elements in the HTML that point to the style sheet: Netlify does cache invalidation for you!
The mp3 files of the actual podcast episodes are stored on S3. I link to those mp3 files from enclosure
elements in the RSS feed, which is what makes it a podcast. I also point to the mp3 files from audio
elements on the individual episode pages—just above the transcript of each episode. Here’s the page for the most recent episode.
I also want people to be able to download the mp3 file directly if they want (or if they want to huffduff an episode). So I provide a link to the mp3 file with a good ol’-fashioned a
element with an href
attribute.
I throw in one more attribute on that link. The download
attribute tells the browser that the URL in the href
attribute should be downloaded instead of visited. If you give a value for the download
attribute, it will over-ride the file name:
<a href="/files/ugly-file-name.xyz" download="nice-file-name.xyz">download</a>
Or you can use it as a Boolean attribute without any value if you’re happy with the file name:
<a href="/files/nice-file-name.xyz" download>download</a>
There’s one catch though. The download
attribute only works for files on the same origin. That’s an issue for me. My site is podcast.clearleft.com
but my audio files are hosted on clearleft-audio.s3.amazonaws.com
—the download
attribute will be ignored and the mp3 files will play in the browser instead of downloading.
Trys pointed me to the solution. It turns out that Netlify can do some server-side processing. It can do redirects.
I added a file called _redirects
to the root of my project. It contains one line:
/download/* https://clearleft-audio.s3.amazonaws.com/podcast/:splat 200
That says that any URLs beginning with /download/
should redirect to clearleft-audio.s3.amazonaws.com/podcast/
. Everything after the closing slash is captured with that wild card asterisk. That’s then passed along to the redirect URL as :splat
. That’s a new one on me. I hadn’t come across that terminology, but as someone who can never remember the syntax of regular expressions, it works for me.
Oh, and the 200
at the end is the status code: okay.
Now I can use this /download/
path in my link:
<a href="/download/season01episode06.mp3" download>Download mp3</a>
Because this URL on the same origin, the download
attribute works just fine.