reclaim

Hacking the JAMstack

Tim Owens

• 3 min read
Hacking the JAMstack

Do you follow the Reclaim Hosting Blog? If not, now is a great time to subscribe as the whole team has been doing intentional learning topics each month and as Jim reminds everyone, The blogosphere is hot! I caught some of this late since my life is practically consumed by the arcade these days, but I wanted to participate so I joined the most recent meeting where the group reflected on files and folder structures on a hosting server. This next month is all about WordPress and the topic is timely as ever as Lauren notes that we're thinking through things like documentation and presentation in the Domain of One's Own interfaces we provide schools.

But this post is not only about WordPress, it goes a bit deeper down a rabbit hole that I've only just this past week entered in which I'm learning more about something called the JAMstack. Now, the idea is not wholly unfamiliar to me. It's very much built on the idea of the headless CMS and Jim and I got a great introduction to that via Tom, Matt, and Jeff at VCU when they showed us how they were using a blog on RamPages to drive a public VCU site on a server they had no control over as a static site pulling content from the blog via API. Jim wrote about that at https://bavatuesdays.com/headless-at-vcus-alt-lab/. So what's JAMstack? Well the term refers not to a particular CMS headless or not, but rather the idea of running static sites where the content is pregenerated. So in other words instead of pulling content on the fly via API (which might be fast for a small site, but perhaps not so when the API gives you thousands of results with a lot of stuff you don't need), a JAMstack setup would have the entire site generated as HTML and any new publish action would trigger a rebuild of that site. The files can then be stored in a git repository and hosted via CDN for performance. No PHP, Node, Go, or any other language necessary to run the site making it screaming fast and easy as hell to host.

Going back to some of the ideas driving this, it feels to me like a long running goal since even when I was at UMW was this idea of how we could share documentation across institutions via some type of centralized repository. Could we have a Github repo with tons of DoOO documentation written in Markdown and allow folks to contribute there or fork it for their own needs but also allow folks who want to use it in WP to do so but also offer static site variants for other needs? Seems a lofty goal, but I have to believe some of this technology is staring us in the face. I mean if Hugo is good enough for D'Arcy who am I to question it?! ;) I'm also taking a deeper look at the work Alan did with CC on their certifications as I think there could be some interesting stuff there.

Back to the JAMstack because this post really is an initial brain dump of where I am and not a tutorial or fully fleshed out post at all. A couple core tools that many are using for this stuff:

It's worth noting that a static site doesn't necessarily have to give up dynamic content in this scenario. The key to pulling in dynamic content (say allowing someone to search a term on your site) is using APIs to poll that specific content and inject the results into your static site using Javascript. Another huge benefit to this is security. When the end user is only interfacing with your content via a static intermediary it makes it much harder for a potential hacker to decipher how they might get access to that content.

This is super early stages but what better use of blogging than putting it all out there as a starting point to bounce off of? I've got a lot of reading and writing to do this coming month but my goal is to have some type of use case with DoOO Documentation living in Github and being served up via a static site with authoring happening in WordPress and perhaps other places as well. Let's see how this goes!