Statically Generating the new SULS Website.
I’m the IT Officer for the Sydney University Law Society (SULS) and I’ve spent the last couple of weeks updating our website from a Drupal based system to a statically generated Nanoc based system.
I built the old website by heavily customizing Drupal. The main shortcomings of this approach were:
difficult to develop and test new features: most new development had to occur on the live site itself since duplicating the site for configuration changes was non-trivial.
difficult to update: I ended up having to update everything due to the complexity of the administration interface - something that wasn’t easy to customize or make significantly simpler.
content was not opaque: all the content was trapped in a database with a strange schema which meant any introspection of batch processing was basically not possible.
constant maintenance required: Drupal requires regular patching to prevent security issues.
The main goals for the new website are:
- reduce maintenence as much as possible (I only have a few hours a week to work on SULS related projects)
- make it easy for the rest of the executive to update
- make it secure and faster
- make it easy to test out new features and restyle the site.
Going Static
The new website is statically generated with Nanoc. The main reasons for switching to static generation are:
The content on the SULS website doesn’t actually change frequently - there are no user comments and there are only a couple of new posts made per week. This means that the cost of regenerating the entire website (about 8s of compilation) is trivial.
The entire website can be versioned using Git - this means that if something breaks (i.e. someone updating it incorrectly) it is trivial to revert to a working verison.
Simple tools can now be used to update the website: Most of the content is now markdown (which can be edited using tools like Macchiato) and all of the supporting assets can simply be dragged and dropped. The most difficult part of the update process is obviously invoking the compilation via the command line or doing a git commit/push - this I intend to automate with Apple Scripts (we’re a Mac-only society).
There are no security vulnerabilities and no maintenance! The website has no running code and is statically served by nginx. Therefore - the only way to break it would be to use an nginx exploit (automatically updated by VPS provider) or to break in using SSH (good luck - we use public key only authentication). Furthermore, this means that I don’t have to apply any weekly security patches.
I can now experiment with the website on my local computer - changing the layout or adding new features without worrying about affecting users.
The website should also be faster since it can be cached entirely and there are no DB accesses or content generation running on each request.
Additional benefit: the entire website is backed up on multiple computers by cloning and regularly pulling the Git repository.
What’s Next?
Over the next couple of weeks, hopefully I’ll get a change to write a couple of blog posts outlining why I chose Nanoc, the structure of the website and how it is generated using Nanoc. I’m also looking at open sourcing the code as an example of a relatively complex site built using Nanoc.
