On Infrastructure

Here are the infrastructure assumptions going forward:

1. We’re going to build Aldus@SFU on the Reclaim Hosting platform (which I have used for everything for a decade or more; for Pop! journal, my blog, various course websites, etc.).

   When the time comes, we can retire our old library-hosted 2015 prototype site, and then make that URL (aldine.lib.sfu.ca) point to the new site instead. But that’s when the time comes; we don’t have to worry about this in the meantime. The old site will remain until we decide otherwise.

2. We’ll build the public-facing website using eleventy (or 11ty), which is a current, best-of-breed static-site generator. It’s the same system that runs my blog currently, so I’m already familiar with it.

   In a static-site model, the development is all done locally (on our laptops): content is (mostly) in markdown; page templates are developed using a templating language (11ty supports a number of them). When you make changes to the site, you re-build the site locally (this is automated, so we don’t have fuss with it much), and then we upload the newly rebuilt website (or, more accurately, just the pieces that are new or changed) to the webserver itself.

   So what lives on the server is just the HTML, images, CSS files, etc. There’s no database, no content-management system, none of those things. The advantages here are: (a) it’s very fast; (b) it’s very secure, there’s nothing to hack; and (c), it’s solid, because there’s nothing to break. Also easily archived, and easy to fix if anything goes wrong.

   All the magic happens at home, on our laptops. Which means we’ll be able to build, and play with, a complete live version of the site on our laptops: vastly easier and less fragile than the Drupal way we built the 2015 prototype.

3. The content is all going to be markdown. Partly because Eleventy speaks markdown natively, but more importantly because there is simply no other sane way of managing digital textual content. After twenty years of fiddling with HTML “visual” editors and content management databases, I am done with that whole way of thinking.^[1]

4. We deploy the site – that is, move changes and updates from our laptops to the live site via Git. So the whole website will also live, ephemerally at least, on GitHub or some such repository, which we can think of as a backup, or as a secondary way of sharing the site with others.

5. We will begin with setting up a blog for the project (as promised to SSHRC),^[2] and doing the first iteration of the site design (fun stuff).

   When SFU Library’s Islandora 2 repository is ready – or actually before that, because we can play with prototyping it – we’ll build an IIIF book viewer into pages on the site (I am thinking that for each digitized volume, there can be a host page, but we may decide there’s a better way to do that). It’s just a matter of creating a new kind of templated page for showing off the books: it’ll expose metadata from the TEI, and embed the javascript for the IIIF book viewer app. No reason we can’t develop all this locally, as it just talks to the repository via an open API.

   I’m not yet sure whether the TEI metadata about the books will live in Islandora or locally as part of the website; I can see advantages to both.