I've recently been inspired by The AHA Stack and wanted to look into building something with it. Astro in particular reminds me of building with 11ty, it's just not (necessarily) building a static site. But I also want to look into more offline-capable web development, which is pretty much impossible with server-side rendering like Astro. If only I could get Astro to run on the client side in a service worker...
I did look into that possibility and found one attempt, which, if I'm honest, went mostly over my head. My takeaway is that it wasn't yet feasible back in 2022 and while things may have changed now, no one else has pursued the idea. I don't think I have the expertise to pull something like that off, but I was inspired to look into perhaps doing something similar, but more simply.
So, I've taken a crack at something... I don't know how useful it is to everyone else, but I think it might have some legs. I've got a server set up with some Mustache templates, then I have a web page with HTMX set up to request those templates alongside data from a JSON endpoint. For this example I'm using the omg.lol API to get statuses (I'm toying with the idea of rebuilding neighbourhood.omg.lol with this stack, but that's another story). So on my HTMX-enabled HTML page, I have included this:
<section id="statuses" hx-trigger="load" hx-swap="innerHTML" hx-get="/templates/statuses.mustache" hx-vals='{"@url":"https://api.omg.lol/statuslog/latest"}'></section>
This triggers a request to /templates/statuses.mustache, with @url=https://api.omg.lol/statuslog/latest encoded into the query parameters (if I'd used hx-post, it would be passed through the body). This request will be picked up and intercepted by my service worker like this:
self.addEventListener('fetch', async event => {
if(new URL(event.request.url).pathname.startsWith('/templates')){
event.respondWith(templates(event.request))
}
else {
//TODO: serve other stuff from cache
event.respondWith(fetch(event.request));
}
});
(I could and perhaps should change this to check for a pathname ending in .mustache rather than starting with /templates, but I'm still just playing around here).
The important thing here is obviously the call to templates, which I will break down into pieces. The first thing it does is ditch any parameters and get the template file itself:
async function templates(request) {
const url = new URL(request.url)
const templateUrl = new URL(url.pathname, url.origin)
// first try and get the template
const templateres = await getTemplate(templateUrl)
if(!templateres.ok) return templateres // return the result on failure
let template = await templateres.text()
...
The getTemplate function call there is just a basic "check if it's in the cache, if not go fetch it" kind of function:
async function getTemplate(url) {
// first check the cache
const cache = await caches.open(TEMPLATE_CACHE)
let response = await cache.match(url)
// if not in cache, fetch it and put it in the cache
if(!response){
response = await fetch(url)
if(response.ok) cache.put(url, response.clone())
}
return response
}
Once I have the mustache template in hand, I need the data to populate the template. I've built it so that you can either pass data through the request, or fetch the data from elsewhere using @url and other @-prefixed parameters to build up a request. At the moment I'm assuming such a request will return JSON, but this should probably be made more explicit in the future.
...
let data = {}
let requrl = null
let reqinit = {}
let params = {}
// check if anything was passed through search params
if(url.searchParams.size > 0) params = parseSearchParams(url.search)
// check if anything was passed through the body
const body = await request.text().trim()
if(body) params = {...params, ...parseSearchParams(body)}
// @url is a url to fetch data from
// @<other> is a request init param
// everything else is data for the template
Object.entries(params).forEach(([key, value]) => {
if(key == '@url') requrl = value
else if(key.startsWith('@')) reqinit[key.slice(1)] = value
else data[key] = value
})
// if we have a request url, go fetch data from the request
// TODO: caching?
if(requrl) {
const responsedata = await fetch(requrl, reqinit).then(r => r.json())
data = {...data, ...responsedata}
}
...
finally, once we have the data (either from the request or passed through), we can use that to render the template and return the rendered HTML as a response for HTMX to swap in
...
// render the template with any data we have
const output = Mustache.render(template, data)
// finally, create and return the response
return new Response(output, {
status:200,
headers:{ "Content-Type": "text/html" }
})
}
Et voilà, service-worker-side rendering from templates stored on the server and cached locally. Obviously there's a lot of room for improvement here, especially to do with the caching strategies. But I can imagine building a PWA like this, with locally cached templates and the ability to fetch data from an external API.
I am very tempted to continue working on this, but I would also like to know how useful this is. Is this just something fun, or are there practical applications? Is there a future for service workers beyond caching strategies? Please, let me know. These are discussions I want to be having.
So, I've re-jiggered my website again, and moved away from Ghost, back to 11ty. As I mused in a previous blog post, I wanted a simpler ActivityPub id, and more control over the handle (i.e. the ability to use death.au as the preferred username). I already had that in a self-hosted Friendica instance, but if I moved that to my main domain, that would prevent my website from showing up at the main domain. Well, with a little help from Cloudflare, I've managed to work around that.
I wanted to write about what I've set up here. I'll start with the basic part:
I've used 11ty in the past, and I really like the flexibility it gives me in the output. I can keep my pages and articles as simple markdown, or go for an all out html bonanza and 11ty will assemble the pieces and spit out html files (or other kinds of files) for me, so I end up with a collection of files that can just be served on the web in the most basic of manners.
Also, it allows me to set up page metadata for routing. I've got a URL scheme of my own I'm using, very loosely inspired by Johnny Decimal, whereby all my blog posts are at /b4.xxxx (where xxxx is just an incremental id). I've also got some small portfolio pages (that I still want to expand on) under cv.yy and short-form microblog-style posts under /n.zzzzzzzz(where zzzzzzzz is actually a base 36 encoded timestamp). Alongside some other things like a summary and featured images (if applicable) I have a lot of control, with very little markup.
Setting up hosting for the pages is simple on Cloudflare. I set up a pages project pointing at my 11ty repo, tell it what command to use to build and what folder the resulting files will be in to upload and now every time I commit and push, my website is automatically built and published. I'm already using Cloudflare's DNS, so it's trivial to point https://www.death.id.au to this pages project and my website is good to go.
As stated above, I was already hosting a Friendica instance as my primary window into the Fediverse. I have it set up in a docker container (via docker compose) on a webserver I'm paying for, behind a reverse proxy. With that all set up it was surprisingly easy to add a route for the reverse proxy to serve up Friendica on https://death.id.au. To reconfigure Friendica itself for the new domain, there's just a command that needs to be run in a console to update the database and send information out about the new domain. And because I'm still hosting it on the old domain as well, I shouldn't be losing anything coming in, even if my followers' details don't get updated right away.
Friendica is an amazing piece of software. Not only does it federate with other ActivityPub services like Mastodon, it also supports "Groups" to follow Lemmy boards, there's a plugin for BlueSky, it supports OStatus and diaspora (not that I follow anyone on those protocols at the moment), it even supports following basic RSS feeds; all in the same interface. On top of all that, it even has Mastodon-compatible API endpoints, meaning I can use most Mastodon apps/clients to interface with it, including my favourite app, Fedilab.
I have my instance set up as a single-user instance, which basically just means that the home page redirects to my Friendica profile page, rather than login/sign up. But that's not really want I wanted for my root domain name. I wanted it to point to my website. So how can I get Friendica to work with my static website? I don't think I can. But I can work around it...
So, as outlined above, I have my static website set up at https://www.death.id.au, and my Friendica instance set up at https://death.id.au. Cloudflare is already hosting my static website for free, and I can also set up "workers" for free as well. Workers is, in Cloudflare's own words, "A serverless platform for building, deploying, and scaling apps across Cloudflare's global network...".
The upshot is, I have set up a worker that intercepts all requests to https://death.id.au. I've got some basic javascript code to check against a list of regular expressions for the paths I've used in my static website and if it matches one of them, return the data from https://www.death.id.au instead. This has potential to lead to conflicts; if a URL on my static website matches one on Friendica, it's going to prioritise my static site instead. But my site's pretty basic, I think it should be fine.
And now, like magic, https://death.id.au/ will serve up my static website, https://death.id.au/now/ should serve my now page, etc. etc. Meanwhile, https://death.id.au/profile/death.au will serve up my profile page on Friendica and, most importantly, any and all ActivityPub, webfinger, API calls, etc will be served on Friendica and my social handle of @death.au@death.id.au is all working fine. The best of both worlds!
A previous version of my website was built on the omg.lol platform. That place is great, and I plan to use it well into the future. But for me to have the control I wanted over this setup, I had to abandon weblog.lol, the blogging service provided by omg.lol. However, I am still heavily utilizing other aspects of the service. I've decided that most, if not all, of the images I'm using on my website are hosted at some.pics. I have plans and ideas to perhaps integrate the omg.lol provided profile and now pages into my website. They are, after all, managed by markdown. I just have to figure out how to trigger the data to be dumped into my github repository when the data changes.
But the biggest part I'm using at the moment is status.lol for microblogging. It's just simple and fun. You write a message (less than 500 characters), choose an emoji to display alongside it, and send it out. There's no likes or anything on the platform, but there is a checkbox to also post the status to Mastodon. As Friendica has Mastodon-compatible APIs, this works on Friendica, too. Status.lol also supports webhooks, meaning whenever I post a status, I can get this sent to an arbitrary URL.
So, I set up another Cloudflare Worker to accept the data from status.lol, format an appropriate markdown file and push that into my repository. That triggers a new build of the website and within seconds, that status is also visible on my website!
I am very happy with how all this turned out. There's nothing I love more than tinkering, and the nature of this setup allows me endless possibilities for tinkering. I have Fediverse "integration" via some javascript I wrote which fetches interaction data on articles and posts from Friendica, and allows someone to "log in" with their ActivityPub handle, and if the script can obtain a valid sharing URL, provides the ability to link directly to posts and statuses on your own instance for replying, liking, boosting, etc. As mentioned earlier, I also want to integrate omg.lol's profile and now page functionality to make it easy to modify those pages through either omg.lol or my neighbourhood.omg.lol app without having to manually check out and push a git repository.
I probably want to look into a headless CMS in the future, but I can also manage my blog posts and pages through Obsidian, as they're all basically in Markdown anyway. I set up a synced vault in my content folder, so I can edit blog posts and pages in Obsidian, on my mobile or anywhere, and then when I'm back at my computer I can review, update some metadata and then push the markdown into my git repository to be published on my website.
Most importantly, I think this setup is pretty stable, and most importantly, fun to tinker with. My biggest hurdle is actually just thinking up things to write about in the first place 😅
I think my next hyperfocus is going to be building a multiplatform status.log equivalent.
I have a desire to try and build a #MAUI #Blazor hybrid app, and working with the #omg.lol API seems pretty fun. Plus, I'm a bit jealous that the current app is apple-only
I couldn't see any docs on the #some.pics API, and I'll have to figure out the OAuth flow, but surely it shouldn't be hard?