# Why I built the wrong blog publishing workflow

## or, "Publishing static sites from mobile, via AWS Lambda"

I used to find writing for a public audience to be a taxing process. I wasn't sure why, but I thought it might be because my workflow was bad. To tackle that, I built a small project. I hoped it'd be an end to my writing troubles.

This post goes over how I built that project (it is kind of a cool project). But it also goes over why it was the wrong solution.

# Misdiagnosing the root issue

To decide what I "needed" to build, I started by comparing workflows: I looked at the way I wanted to write, and contrasted it to the way I did write.

My previous workflow had me spend a lot of time in my text editor. Which I thought was bad for writing, because when I'd start writing, I'd try live previewing my blog, and only an hour later realize I was knee deep in minor CSS changes.

So I thought it was the text editor that made it easy to get off-track. I wanted a simpler workflow. And I was actually so fed up with my previous workflow, I wanted to cut my laptop out entirely. I wanted to write and publish posts just using my phone.

What a mistaken conclusion. Looking back, _the text editor itself wasn't my problem_. I was just uncomfortable writing about something I was unsure of to a public audience. So changing how my blog looked was easy, but _writing carefully thought-out content and exposing it to public judgement_ was hard.

So, much like I'd procrastinate large projects in college, I wound up procrastinating writing by cleaning up my blog's styling.

# Over-engineering the technical solution

On my laptop, after I wrote a post in Markdown, I would:

• build my blog using Hugo
• git push changes to Github
• which then deployed the contents of the docs folder via Github Pages

I decided that to deploy from mobile, I would make a Lambda that did the same thing as my laptop. Meaning that after I wrote the post on my phone, I would:

• send it to the AWS Lambda
• which would then git clone my blog repo
• then insert the post, build the repo using Hugo, commit the changes
• and git push changes to Github
• which would then deploy the contents of the docs folder via Github Pages

This meant that the Lambda would need to run Hugo and Git. Naturally, instead of adding a small amount of vendor lock-in with AWS Lambda Layers to manage binary dependencies, I opted for a mostly-academic seeming library to run Docker in a Lambda. I'm ashamed of how long it took me to get all this working.

(Note: There's also AWS's img2lambda, to convert Docker images to Lambda layers, but it didn't work in this case)

An interesting thing I noticed in retrospect: When I build projects for work, I tend to start with the absolute minimum, look for existing solutions before building them on my own, and use well-tested dependencies. But for side projects, I do the opposite.

I don't think this is a bad behavior, actually, because it lets me try out more risky decisions in a safe environment. But it does mean that I shouldn't expect the same results.

# The architecture

So the architecture I built had three parts:

• A text editing app of my choice, to draft the post
• This app was just for me to edit posts on. Any app would work, as long as it could export plain text. I chose iA writer because it had nice markdown preview support.
• An AWS Lambda function, which published the post
• The most important part of this project. Source code is here.
• I wanted to use a serverless platform, because I felt the frequency of my posts didn't merit a full-time server.
• An iOS shortcut, which took the post from the app and sent it to the Lambda
• I think iOS shortcuts are underrated, specifically for simple ETL tasks like this. Source code is here (only viewable on iOS).

# The Results

And this is what my new workflow looked like, from start to finish. I could write a post, export it to the shortcut, which would send it to the Lambda function, which would publish it.

The full publishing workflow, with the Lambda doing a cold start

But while it looked nice, it didn't address my problems. Months went by before I felt I could publish this very post. When I finally edited it, I realized why it took so long to publish. And so I changed this post from a longer technical overview, to a shorter commentary on where I went wrong.

I still have a mobile post pipeline, but it doesn't look like this. It's just git app for iOS, and a Github action. I didn't write anything more complicated than a config file to use it.

But more importantly, I pushed myself to address the issues. I didn't like how my blog looked—-so I made it look clean and scale well on mobile. I was worried about presenting my opinion—-so I took time writing my opinions before subjecting them to judgement. I didn't have enough time to write—-so I set aside a full day for a post, instead of a couple hours.

So that's a start. Now, I'll have to keep writing to turn these behaviors into habits.