.png)
3 months ago
3
As I've continued to over-engineer this site, there's been a mounting tension between what is and isn't dynamic. What should be dynamic, what needs to be dynamic, how often a given page or element is updated.
I've tried solving this in a number of ways, typically with edge functions or a framework1 that relies on edge functions and/or specific hosting platforms. One of the longer-lasting solutions was to have 11ty deliver dynamic templates by sharing layout code between static pages and PHP code included in Liquid partials.2 What this meant was that I had your standard Liquid template files and .php.liquid files.3 Why .php.liquid? Well, they contained PHP and had to be included using a {% render ... %} tag. Sometimes they even rendered static data from Liquid tags inside of the PHP.
This worked! It worked reliably. It was performant — all posts were static, media pages with little traffic were dynamic and didn't need to be pre-built. But there's a cognitive load that comes with maintaining an application so glaringly non-standard. Why is this token here? What's this condition for? Which syntax am I using? The nest of conditions I had for meta and header tags was a sight to behold. There was even frontmatter to control whether a page was static or dynamically rendered.
I love 11ty but it was becoming clear that — for my site in particular — I was hitting a bit of a wall. The backend for my site has and continues to work well. Directus writes to postgres, data is fetched from optimized views using rest calls to postgREST. I already had PHP written. Classes and utilities for fetching data, single file APIs and several other artifacts. I'd looked at Laravel before when considering other projects — it's well-supported, has a large community and countless tools. It's fair to say that using it for this site is overkill.
Overkill is often my thing.4
I'll have plenty of posts to follow this. Some technical. Some not. But it took me a while and I learned bunches. Scrobbling and Mastodon syndication are now commands run by Laravel's scheduler, not standalone PHP files I ping using curl. Data is fetched using endpoint-specific services, caches are warmed, a cacheable service trait is sprinkled throughout. All layout code is in .blade files. One unified syntax.
I'm confident I've done things that are non-standard when making this change. I've made mistakes. I'll learn from those, sort out anti-patterns I've adopted and learn from refactoring them and resolving issues. But, it's worked well. Hopefully the change has gone largely unnoticed (aside from the 500 errors when it first went live).
I know that I'll still be reaching for 11ty for most projects.
