Moving my reading list out of JSON

I blogged about hosting a reading list on this blog a little while ago. At the time, I decided that storing the books as JSON would make sense - and it did, at the time. But as the list has grown, albeit not exponentially, it started to get a bit messy.

So I decided to move the reading list into a SQLite database, which seemed like a sensible choice.

Why SQLite?

I had two requirements for the list: it should be easy to update, and I should be able to update the blog from the Git repository. That meant an externally-hosted database was a no-go.

SQLite fit both of those criteria. It’s a small file format, it’s only taking up 16kb on the repo right now. And it’s a fully-featured SQL database, which means not only can I easily update and store the records, I could also use it to draw out some statistics about my reading habits. I might do that in a future blog post, once I’ve got a few more books on the list.

Integrating into Eleventy

This was exactly as painless as creating the original list was. Eleventy doesn’t really care what data format I use, I just swapped the part of my data file that used the JSON data source, with a function that opened and read the SQLite database. And that was it. Everything else stayed exactly the same.

I’ve not seen any noticable hit to build times, largely because reading the data locally isn’t the bottleneck - getting data from the OpenLibrary API is.

Limits

For my use, this is absolutely fine. If this were a site where multiple people were creating pull requests and merging code in, I might reconsider it - SQLite files are binaries so there’s no meaningful way for Git to diff them, making merge conflicts very common. But this is my site, and I’ll merge whatever I want.