afonso jorge ramos

The Accidental Homelab

Tue, 05 May 2026 00:00:00 GMT

In 2016, as a university student, I installed Plex on my gaming desktop and started serving local media off it. The desktop was an i7-4770K with a GTX 770, the first PC I’d built myself, back in 2013 at 15. Nine years later, that same Plex install has grown into a TrueNAS server running ~30 self-hosted apps, ~40 TiB of usable storage on a raidz2 pool (with a story behind that number, see below), and serving roughly 20 people across a few countries. None of it was planned. Every step came after the previous one started to break, and was paid for whenever the budget caught up.

Before Plex (2010–2016)

I’d been torrenting since 2010. I was twelve, uTorrent was the client, and the workflow was strictly manual: pick the show or movie I wanted, search for it, find a healthy seed, download, watch. The uTorrent download folder was my entire media library. Half of it was things I’d already watched, half was things I was queuing up for the weekend, and the only “library management” was my own memory plus a TV Show Time account that kept track of which episode of which show I was up to.

This was the KickassTorrents era, and KAT was awesome - moderators, comment threads on every release, a community that would flag bad rips and call out fakes. The site got taken offline in a US-led operation in 2016, and the gap eventually got filled, for me at least, by private trackers, where ratios are enforced and quality gets policed much more directly. Tens of terabytes of seeding later, I’m still on the same ones.

Plex, when I found it in 2016, was the abstraction I’d been missing. It turned that flat folder of files into something I could actually browse - metadata, posters, subtitles, watch progress - and, more importantly, share with people who weren’t going to learn what .mkv meant.

The Gaming-Rig Era (2016–2020)

The first version was the laziest possible setup: Plex on my main Windows desktop, drives merged with Windows’ built-in Storage Spaces so 2×1TB + 1×4TB looked like a single mount point, port-forward so a couple of family members could stream from outside. The “server” was whatever happened to be on the gaming PC at the time. I held out on Plex Pass until 2018, when I caught one of their 50%-off lifetime sales - still easily the best money I’ve ever spent on this whole project.

It worked exactly as well as you’d expect. Plex transcoding is CPU-bound, gaming is GPU-bound, but they both fight for memory bandwidth and disk IO. Three people watching from outside the house on shaky connections, and my gaming session noticed. I could pause my game, kick people, or accept that nobody’s experience was going to be great. But to be honest, this did not happen that often back then.

The i7-4770K as Always-On Server (2020–2023)

In 2020, with my first salary out of university, I bought a new gaming desktop - Ryzen 9 5900X, RTX 2060 Super - and “retired” the i7-4770K. Retired meaning “moved to a corner with the drives still attached and never turned off again.” First time the home server became a separate machine from my gaming PC.

The stack matured a bit. Sonarr and Radarr came online (or maybe before, not entirely sure when I brought these on); access to a couple of decent private trackers and a few reliable public ones meant new media just showed up without me babysitting it. Parsec gave me remote access. Overseerr arrived later and took requests off my hands - friends and family could ask for content directly (I did share *arr access for a bit before this).

This is also when the user count grew past family, and transcoding got real. Three concurrent remote streams on the 4770K’s iGPU was the limit. I never wanted to disable transcoding entirely (some people had genuinely bad upstream connections), but the 4770K just didn’t have the headroom.

The whole thing was still on Windows. NTFS had a lot of data on it; a clean Linux migration was always “next year.” I knew Storage Spaces would haunt me eventually, but it kept working. Should I have just shipped the whole library to S3 and dealt with the migration cold? Probably. But moving 8 TB of Linux ISOs to a cloud bucket on a non-fiber upload is a project of its own (to be fair, we did eventually get fiber a year or two later).

In 2021 I bought my first 18 TB drive. Single drive, no redundancy, “I’ll figure out RAID later.” That made the eventual migration even more daunting with even more Linux ISOs to migrate!

The 2023 Reset

By 2023 the smell was real. I wanted out of Windows, I wanted real ZFS, and I wanted a server that wasn’t living in fear of a Windows Update at 03:00. I also didn’t want to take the existing setup down while building the new one - there were ~16 people relying on this thing by then, and “your media is broken for two weeks” wasn’t something I wanted to do to anyone.

So I bought a used PC from a local secondhand site: Ryzen 7 5800X, RTX 3080, 64 GB of RAM. The point of the deal wasn’t the 5800X - it was the GPU and the memory. I swapped both into the 5900X gaming rig (which got a meaningful upgrade for almost nothing), stripped the used box down to CPU + motherboard + chassis, and stood it up next to the running 4770K as the new server. Built the new platform fully, copied data across, swapped people over. User-facing downtime was a few hours.

Why TrueNAS (and Not Unraid or Proxmox)

Most homelab content for media servers points at Unraid: mixed disk sizes, single parity, paid license, very forgiving of “I bought one drive at a time over four years.” For someone whose drive collection grew organically - like mine had - Unraid is the obvious answer.

I went with TrueNAS Community Edition (formerly TrueNAS Scale) for three reasons.

ZFS is first-class. Unraid only added real ZFS support recently, and even then its core array layer is XFS-per-disk with parity. ZFS gives me snapshots, scrubs, send/recv, end-to-end checksums, and a pool layer I trust. After a year of running this I’ve caught zero silent bit-rot, but it’s the kind of thing you only know is working because nothing’s gone wrong.

All same-size disks anyway. My organic-growth phase ended in 2021. Going forward I knew I’d buy 18 TB drives until I died - they sit at the sweet spot for €/TB. Once you commit to one drive size, Unraid’s flexibility advantage evaporates and ZFS’s rigidity stops mattering.

The apps platform. TrueNAS’s built-in app catalog runs containers as first-class objects on the host, with iXVolumes (ZFS-backed) for app state. I don’t need a separate Proxmox + LXC + manual ZFS layer. One UI, one auth, one upgrade flow.

If you have ten differently-sized drives accumulated over a decade, get Unraid. If you’re starting fresh and willing to commit to one size, get TrueNAS. I did wipe my old non-18TB drives and sold them, by the way.

The Present: 5×18TB raidz2, ~30 Apps, 16 People

Today the pool is five 18 TB Seagate IronWolf Pros in a single raidz2 vdev: two-disk redundancy, ~40 TiB usable today (currently ~79% full), with about 7 TiB stuck behind a legacy parity layout that I only noticed while writing this post - more on that further down. Single-vdev is fine here because the IOPS-sensitive apps run on a separate pool - ZFS scales IOPS per vdev, so a 5-disk raidz2 has the random-read throughput of roughly one disk, which doesn’t matter for sequential media streaming. Most of the drives came from ServerPartDeals, a recertified-disk shop that ships enterprise drives at a meaningful discount over new. Worked out at roughly half of new-IronWolf-Pro pricing, the trade-off being that the 5-year warranty runs from manufacture date rather than purchase date.

The host is on a UPS that easily handles half an hour of operation. Nothing’s port-forwarded anymore: family-facing apps come in through a Cloudflare Tunnel at *.afonsojramos.me (no exposed home IP, TLS handled at the edge), and everything admin - the *arrs, qBittorrent, dashboards, the lot - stays behind Tailscale. Two access tiers, one running it, the other consuming it. The stack, in rough shape:

storage: 5×18TB raidz2 plus a separate apps pool for fast app state
media: Plex (1,400+ movies, 21 TB of TV, 874 GB of music), Jellyfin alongside it for redundancy (and external downloads, since the Plex Pass only allows Home User downloads), Tautulli for stats, Maintainerr for retention rules
photos: Immich
cloud: Seafile, plus Filebrowser and SMB shares for the unencrypted stuff
auth: Authentik fronts SSO across the public apps and gates the admin tools behind a homelab-admins group; Wizarr at invite.afonsojramos.me is the family onboarding door, bootstrapping both Plex and Jellyfin from a single invite
plumbing: Sonarr, Radarr, Bazarr, Overseerr, qBittorrent, Dockge, Glance, plus a handful of custom Dockge stacks for things the catalog doesn’t ship

The Drive Failure (Which Is Why raidz2)

A few weeks ago, Scrutiny - the SMART dashboard I have watching the pool - lit up with UNC errors against /dev/sdd, one of the recertified IronWolf Pros (8,682 power-on hours, roughly a year of always-on, 18 TB), and a failed extended self-test soon after. It’s still online, but the pool reports READ=1 against it. The drive is firmly dying.

This is why raidz2 exists. With raidz1 (single-disk redundancy) you can lose another disk during a 4–6 day resilver window, which is a real risk: large drives mean long resilvers, the resilver itself stresses the remaining disks, and those remaining disks are also a year old and also from the same recertified batch. With raidz2 I can lose this one and another during the resilver and still be fine. The math on a five-disk pool of 18 TB drives wants two parity disks.

The drive came from ServerPartDeals; the RMA paperwork is in flight. The vdev still has both parity disks intact while I’m waiting on it, so the cost so far is “wait and watch.” And I’ve also ordered a new drive, which I’ll add to the pool once it arrives.

What Writing This Post Turned Up

When I expanded this pool from 4-wide to 5-wide raidz2 with a zpool attach almost a year ago, I did the napkin math for the new geometry - 5×18 TB raidz2, ~49 TiB raw, ~44 TiB usable after ZFS overhead - and then never went back to check whether the running pool actually matched. The number sat in my head as fact for almost a year. Writing this section was the first time I’d looked at it again, and it turns out that that is not what I’ve been looking at at all.

I am currently getting ~40 TiB total, ~4 TiB short of the number I’d been carrying around since the expansion. Turns out that OpenZFS raidz expansion has a footnote I’d glossed over: it only changes the layout for new writes. Records already on disk keep their pre-expansion parity ratio forever. 4-wide raidz2 is 50% parity (2 of 4 disks); 5-wide is 40% (2 of 5). Everything written before the expansion still pays the 4-wide rate, and nothing in zpool or zfs will restripe existing records - not scrub, not resilver, not property changes. I had, honestly, assumed that that would be done in the expansion process, but it turns out that the only fix is to rewrite the data so ZFS reallocates it under the current geometry.

The tool for that is markusressel/zfs-inplace-rebalancing.sh: walks the dataset, copies each file to a sibling tempfile (no --reflink, so it’s a real fresh write), verifies size and checksum, atomic mv back over the original. Resumable across runs. Napkin math says I should reclaim about 7 TiB on ~36 TB of pre-expansion media - 36 × (1 − 40/50) = 7.2 - which would push the pool back past the ~44 TiB I’d always had in my head.

The catch: it’s a multi-day full-pool I/O storm, and /dev/sdd is exactly the wrong disk to be running it against. After replacing it I’ll need to resilver, scrub, and only then rebalance.

The takeaway, if you’re starting fresh: zpool attach raidz expansion is a one-shot operation you should plan around, not a casual capacity-add. Either commit to a rebalance pass after every expansion, or grow the pool by replacing all five disks one-by-one with larger ones (autoexpand=on), which keeps the geometry constant and avoids the legacy-tier problem entirely. Given /dev/sdd is going RMA anyway, the replacement could itself be the first 20 TB drive in a gradual disk-size upgrade - no parity-ratio drift, no rebalance debt, just bigger drives over time.

Edit (29 May 2026): I did all of the above, and it worked. The replacement drive turned out to be a Toshiba MG09 18 TB rather than a 20 TB - a same-size swap, but it breaks up the all-Seagate, all-same-batch monoculture, which is good in my books. It was also a drive that had a good reputation in Backblaze’s reports.

zpool replace resilvered in 39 hours at full redundancy (online replace - the failing disk stayed in the array the whole time, so parity never dropped to raidz1), a verification scrub came back clean, and then I let the rebalance run. It took 9.5 days for ~32 TB - I’d budgeted 3-5, and the estimate was about half what it should’ve been, because the cost is per-file cp/verify overhead, not throughput: a 30 GB remux and a 2 KB .nfo each pay the same fixed tax, and the TV library alone is 31,000 files. In total, it reclaimed 5.2 TiB (the pool went from 82% to 75% full), a bit under the 7.2 I’d predicted because a chunk of the library was written after the expansion and was already on the efficient layout. Two gotchas worth flagging if you try this on TrueNAS: the rebalance script’s cp -ax dies instantly on datasets with aclmode=restricted (flip it to passthrough for the run), and any snapshot predating the rebalance pins the old-layout blocks so the pool grows as you go - I had to drop five stale snapshots mid-run to avoid filling the pool before it could shrink. The honest verdict: the rebalance is the rare homelab chore that delivers exactly what the napkin math promises.

No Regrets

Looking back, I don’t really have any. Self-hosting in 2016 was a much lonelier hobby than it is in 2026. No /r/selfhosted at its current size, no Tailscale, no TrueNAS Community Edition, no recertified-drive economy you could trust at scale, and homelab content on YouTube was a tiny fraction of what it is today. Most of what looks obvious in 2026 had to be figured out from scratch back then, and a lot of the choices that look “wrong” in retrospect were the only realistic option at the time.

The hurdles were also good for me. Storage Spaces taught me what I wanted from a real filesystem. Running Plex on my gaming PC taught me why isolation matters. The Windows years taught me what I was willing to pay for in operational simplicity. None of that would have landed the same way if I’d been handed today’s tooling on day one.

A few opinions that have held up, regardless of when you start:

Storage Spaces is fine until it isn’t. Use it, then leave it before your library makes the migration scary.
Don’t run Plex on your gaming PC. The moment your library has more than a couple of viewers, it deserves its own machine.
Recertified enterprise drives are great once you trust the supplier. ServerPartDeals’ IronWolf Pros land at roughly half the price of new for the warranty trade-off.
Pay for Plex Pass when it goes on sale. The 50%-off lifetime promos come around. Best deal in self-hosting. (Edit (29 May 2026): turns out, this was an even better deal than I thought, since from July 2026, Plex Pass will be available for 750$)

The thing the homelab guides on YouTube don’t tell you is that it never actually starts as a homelab. It starts as one Plex install on whatever’s nearest, and a few years later you catch yourself reading about ECC memory on a Sunday afternoon.

blockrate

Wed, 22 Apr 2026 00:00:00 GMT

Existing “ad block detectors” tell you whether a blocker exists on the visitor’s machine. They don’t tell you which third-party tools you actually rely on are blocked. Optimizely and PostHog have very different block rates. So do GA4 and Segment. Knowing the per-provider number is the difference between “ignore it” and “we should reverse-proxy this one server-side.”

blockrate measures it. Three tiers depending on how much infrastructure you want to run:

OSS library (1.6 KB, zero deps) - drop into any web app, point at any reporter. First-party origin only, by design - third-party reporter URLs are themselves blockable, defeating the purpose. The core README explains why this is load-bearing.
Self-hosted server - bunx blockrate-server and you have an ingestion server with SQLite by default (Postgres optional via Drizzle), a built-in dashboard, and an API key. One binary, one command.
Hosted version (blockrate.app) - sign in, get a key, see per-provider rates. For people who don’t want to operate any of the above.

Built on Bun + Drizzle for the server, TanStack Start + Better Auth for the dashboard. Framework adapters for Next.js, TanStack Start, SvelteKit, Nuxt, SolidStart, and vanilla JS in the box. Source at github.com/afonsojramos/blockrate.

slidev-decks

Wed, 15 Apr 2026 00:00:00 GMT

Slidev is a beautiful slide framework, but it has a single-presentation mental model: one repo, one slides.md. If you give a few talks a year and want to keep them all in one place - with shared themes, easy diffing, GitHub Pages deploys - you end up writing the same scaffolding scripts every time. slidev-decks is that scaffolding extracted into a small CLI.

It is also, in 2026, one of the best slide tools for the AI era. The source is plain Markdown - an agent can read, edit, or generate a deck end-to-end the same way it edits any other repo, with diffs that review like code and no UI to automate against. Outline a talk in chat, hand it the file, and the slides write themselves. Try doing that with Keynote.

sd is the short alias. sd alone opens an interactive picker; sd ai fuzzy-matches against folder names and frontmatter titles to jump straight to the deck; sd new walks you through creating one (templates use {{TITLE}} / {{AUTHOR}} / {{YEAR}} placeholders); sd build --all rebuilds everything and skips decks whose source hasn’t changed since last build; sd export ai --dark produces PDFs. Any flag it doesn’t recognise gets forwarded to Slidev untouched, so nothing is taken away.

Detects your package manager from the lockfile. Reads title, date, author from each deck’s frontmatter for the picker. Includes a reusable composite GitHub Action for building and deploying every deck under a custom base path. Published on npm as slidev-decks; source at github.com/afonsojramos/slidev-decks.

qbz

Sat, 04 Apr 2026 00:00:00 GMT

qbz is a native, bit-perfect hi-fi player for Qobuz, built in Rust on top of Tauri. It started life as a Linux-only app. I brought it to macOS.

Most of the work was the kind you only notice when it is wrong. Real CoreAudio output with device probing and sample-rate switching, so playback stays bit-perfect end to end. Hunting down a track-change crackle that turned out to be a buffer handover bug. Deep links for qobuzapp://, native notifications with album artwork, x86_64 cross-compilation for Intel Macs, and ad-hoc signing so Gatekeeper stops rejecting the bundle. Each one is small on its own; together they are the difference between “compiles on macOS” and “feels native on macOS”.

Some of it pushed one layer down, into the crates qbz is built on. macOS sample-rate switching needed device-rate enumeration that coreaudio-rs did not expose, so I added it there. Album artwork in notifications needed notify-rust to accept an image path, so I added that too. For a while qbz ran on my forks of both; once the changes were released, it went back to the published crates.

Almost all of the app-level work landed upstream in vicrodh/qbz across a few dozen merged pull requests, starting with the initial macOS support PR. Working in someone else’s audio codebase, in Rust, on a platform it was never written for, was a good reminder of how much careful work sits underneath the word “port”.

The Abstraction Imperative: Why Framework-Defined Infrastructure is the Next Step in Software Evolution

Sat, 22 Nov 2025 00:00:00 GMT

Every major leap in software development has followed the same pattern: we abstract away complexity that no longer needs manual attention. Framework-defined infrastructure is not merely another deployment strategy; it is the logical continuation of a decades-long trajectory allowing developers to focus on the problem, not the plumbing. At no point in this blog post will I argue that we don’t need plumbers. Instead, I will argue that we should worry less about plumbing by trusting well-tested abstractions that others have carefully refined over time.

The History of Software is the History of Abstraction

In the 1950s, programmers wrote in machine code, toggling switches to represent binary instructions. Assembly language abstracted machine code. High-level languages like C abstracted assembly. Garbage collection abstracted memory management. Virtual machines abstracted operating systems. Cloud computing abstracted physical hardware.

Each abstraction faced resistance. “Real programmers” supposedly needed direct memory access. Garbage collection was “too slow” for serious applications. Virtual machines added “unnecessary overhead.” Cloud computing meant “losing control.”

In each case, the abstraction became dominant, though not universal. Not because it was perfect, but because it let most developers solve most problems at a higher level. Assembly still exists for embedded systems, manual memory management remains critical for certain performance-sensitive applications, and some organizations still run their own data centers. The question was never whether to abstract completely, but when the abstraction became good enough to trust for the majority of use cases.

Where We Are Now: The Infrastructure Abstraction Gap

Modern application development has reached an inflection point. We’ve abstracted nearly everything about software except how we deploy it.

The move to web applications itself represents a massive abstraction, instead of writing platform-specific native code for Windows, macOS, Linux, iOS, and Android, developers write once for the browser and let the browser handle platform differences. APIs and microservices abstracted monolithic architectures. Containerization abstracted runtime environments. The pattern is consistent: each generation removes another layer of manual platform-specific work.

Yet deployment remains stubbornly manual. We’ve moved beyond FTPing files to servers, yes, but consider a typical web application today. Developers write code using framework conventions, routes, components, server functions, middleware. But when deployment time comes, they must translate these high-level concepts into low-level infrastructure primitives: Lambda functions, API Gateways, load balancers, CDN configurations, caching layers.

This translation layer is where things break down. As the evolution of Platform as a Service (PaaS) has shown, the progression from bare metal to virtualized infrastructure represents “the evolutionary nature” of modern software. Yet even with traditional PaaS offerings, developers still face somewhat of a gap between application code and infra configuration.

With traditional Infrastructure as Code (IaC) approaches, you write a server-side rendering function in your framework, then spend hours configuring the serverless function, its memory limits, timeout settings, IAM roles, and API Gateway integration. The gap between framework concept and infrastructure primitive remains stubbornly manual. Terraform fatigue is real.

Framework-Defined Infrastructure Closes the Gap

Framework-defined infrastructure eliminates this translation layer by making the framework itself the interface for infrastructure decisions. As Vercel describes it, “the deployment environment automatically provisions infrastructure derived from the framework and the applications written in it.” The platform reads your framework code and provisions infrastructure automatically based on what it understands your code needs.

This isn’t an entirely new concept. In fact, the roots trace back to 2006 when Zimki introduced what Simon Wardley called “framework-as-a-service”, a fascinating early attempt that could have made Canon one of the first major cloud providers before the industry settled on the term Platform as a Service. Though Zimki ultimately closed, Heroku launched in 2007 and successfully commercialized this vision with their mantra that developers should “focus on what they do best: building great apps” while the platform handles infrastructure. Heroku’s architecture was designed to remove obstacles so developers can focus on building rather than managing servers.

Similarly, Netlify popularized the JAMstack architecture, a term coined by CEO Mathias Biilmann, which emphasizes prerendering content and deploying directly to the edge. As Netlify explains, their approach is fundamentally about “abstraction and simplicity”, where build automation understands framework patterns and automatically optimizes deployments.

The framework conventions themselves become infrastructure declarations:

When you export getServerSideProps in Next.js, you’re declaring that route needs server-side compute
When you set output: 'server' in Astro, you’re declaring the entire site needs SSR capabilities
When you create a +page.server.ts in SvelteKit, you’re declaring that route requires server-side data loading
When you use export const prerender = false in SolidStart, you’re opting that route into dynamic rendering

The framework has already made the infrastructure decision, it just needs a platform that understands it. This isn’t magic. It’s pattern recognition applied to infrastructure. Frameworks impose structure and conventions specifically to make code predictable and understandable. Framework-defined infrastructure leverages that predictability to automate infrastructure provisioning the same way frameworks automate application structure.

Why This Matters Beyond Any Single Platform

The power of framework-defined infrastructure isn’t tied to any particular deployment platform. Multiple platforms, Vercel, Netlify, Cloudflare Pages, AWS Amplify, Azure Static Web Apps, have independently converged on the same insight: let the framework define infrastructure needs. Though implementations vary in how much configurability they expose, the core principle remains consistent.

This convergence validates the abstraction. Just as multiple operating systems implement virtual memory and multiple languages implement garbage collection, multiple platforms implementing framework-defined infrastructure proves the concept has staying power.

As Vercel notes in their piece on avoiding vendor lock-in, “Framework conventions like the Next.js App Router, Remix loaders, SvelteKit endpoints, and Nitro storage adapters work differently. You build against the framework, not the platform. Multiple platforms can run the same framework code, keeping your application portable across any infrastructure that supports it.”

The competitive advantage shifts from proprietary primitives to better implementations of the same abstraction. Platforms compete on performance, developer experience, observability, and pricing, not on lock-in. In fact, approximately 70% of Next.js applications run outside of Vercel, with companies like Walmart, Nike, and Claude.ai self-hosting at massive scale.

There are legitimate concerns about vendor lock-in when platforms handle multiple aspects of your stack. As one developer notes, “when one provider handles your hosting, manages automated deployment, runs a few dozen micro-services and serverless APIs, provides your database through their proprietary API, and more, migrating away to somewhere else becomes very expensive.” But framework-defined infrastructure actually addresses this concern by keeping the abstraction layer in the open-source framework, not in proprietary platform APIs.

The Developer Experience Transformation

The real benefit surfaces in daily development work. With framework-defined infrastructure, your local development environment matches production behavior because both run the same framework code. There’s no simulation layer, no mocked services, no “works on my machine” debugging.

As Vercel explains, platforms built on vendor primitives need complex simulators for local development, Cloudflare provides Wrangler to simulate Workers locally, AWS developers use LocalStack or SAM CLI to mock Lambda and other services. These tools approximate production behavior but never match it exactly.

This echoes Heroku’s original insight: by abstracting away the underlying infrastructure, developers “don’t have to worry about anything except for application logic.” With framework-defined infrastructure, you test your application by running next dev or remix dev, the standard framework tooling. What you see locally is what runs in production because the framework, not the platform, defines the behavior.

This eliminates an entire class of problems. You don’t need to maintain separate local development simulators like LocalStack or Wrangler. You don’t need to keep IaC configurations in sync with application changes. You don’t need platform-specific tooling that only half-works on your operating system.

Tools like SST represent an interesting middle ground—they use framework conventions to generate IaC (CloudFormation/Terraform) rather than bypassing it entirely. This hybrid approach still requires maintaining infrastructure code, but reduces the manual translation burden by inferring infrastructure needs from your application code.

Abstraction Enables Specialization

Critics worry that abstraction means losing control. But abstraction doesn’t eliminate control, it enables specialization.

When you write a Next.js application, you’re not locked out of infrastructure. You can still deploy to EC2 and manage every detail if needed. Companies like Walmart and Nike do exactly this at massive scale. The difference is that you can also choose not to, letting platforms that specialize in infrastructure handle those concerns while you specialize in your product.

This is how every successful abstraction works. You can still write assembly if you need to, but most developers rightfully choose to write in higher-level languages and let the compiler handle optimization. You can still manage memory manually, but most developers let garbage collection handle it. You can still provision servers, but most developers let cloud platforms handle it.

As the evolution of cloud computing shows, PaaS sits between IaaS and SaaS specifically to “abstract infrastructure complexities, allowing developers to focus on building and innovating.” Framework-defined infrastructure extends this progression. You can still configure infrastructure manually if you need to, but most developers can let the framework and platform handle it automatically.

The Economics of Abstraction

Abstractions succeed when the economic value of simplification exceeds the cost of flexibility lost. Framework-defined infrastructure passes this test decisively.

Consider the engineering cost of a typical deployment:

Writing and maintaining IaC configurations
Keeping infrastructure in sync with application changes
Managing environment differences between development and production
Training new team members on platform-specific tooling
Debugging issues caused by misconfiguration

Now consider the alternative: writing framework code that automatically deploys correctly. As Vercel found when studying high-impact web teams, “when developers control their entire workflow, teams previously balancing both hardware and software can focus solely on the strategic aspects of product delivery. Conversations shift from ‘how’ and ‘if’ to ‘what’ and ‘when,’ as infrastructure is no longer an obstacle to launching products.”

The reduction in cognitive load, time spent, and error rate represents genuine economic value. A Forrester Total Economic Impact report found that teams using framework-defined infrastructure saw higher customer conversion rates generating $2.6 million in incremental profits and higher website traffic generating $7.7 million in incremental profits.

Netlify’s experience with the JAMstack architecture demonstrates similar benefits. By automating the build and deploy process, platforms ensure “code can be shipped with little to no opportunity for error,” while the architecture itself is “designed to scale only when needed” rather than requiring premature optimization.

Some applications have special requirements that framework-defined infrastructure doesn’t handle well. That’s fine. Those applications can opt out and configure infrastructure manually. But for the majority of web applications, the standard patterns that frameworks encode work perfectly, and automating their infrastructure deployment makes obvious economic sense.

What This Means for the Industry

Framework-defined infrastructure represents a maturation of the platform-as-a-service model. Early PaaS offerings like Heroku abstracted infrastructure but required you to build against their specific deployment model. Modern framework-defined infrastructure abstracts infrastructure while letting you build against open source frameworks.

This distinction matters. When the abstraction layer is proprietary, adoption requires trust in a single vendor. When the abstraction layer is an open source framework, adoption requires trust in the broader ecosystem. The latter scales better.

This is reflected in what Vercel calls their Open SDK strategy: “We want what we build to work extremely well on Vercel, but not at the cost of lock-in… We will build first on Vercel, where we can iterate fastest to ensure the best end-to-end developer and user experience. And as we become confident projects are mature, we’ll invest in ensuring our SDKs and tools are deployable to any platform.”

Similarly, Netlify and Cloudflare have come together to support open frameworks like TanStack and Astro, recognizing that “a rising tide lifts all boats.” As they note, “the strongest projects emerge when multiple organizations align behind shared goals, giving developers the broadest opportunities for success.”

We should expect framework-defined infrastructure to become the default deployment model for framework-based applications, just as cloud computing became the default infrastructure model for most applications. Some organizations will continue self-hosting and managing infrastructure directly, just as some organizations still run their own data centers. But the center of gravity will shift.

The Evolution Continues

The pattern is already extending beyond basic deployment. Vercel’s recent introduction of their Workflow Development Kit shows how framework-defined infrastructure concepts apply to durability and long-running processes: “Functions can pause for minutes or months, survive deployments and crashes, and resume exactly where they stopped.” Rather than manually configuring message queues and retry logic, developers write standard async functions with durability directives, and the platform handles persistence automatically.

Similarly, their self-driving infrastructure initiative explores how production data can inform infrastructure optimization: “Code defines infrastructure, production informs code, and infrastructure adapts automatically.” This closes the loop between application behavior and resource allocation without requiring manual intervention.

Vercel’s approach to application-aware routing demonstrates how deeply framework understanding can integrate with infrastructure: “Vercel uses your framework code to define infrastructure and how requests are handled at runtime. This tight integration gives the platform full visibility into your app’s structure: routes, layouts, rewrites, middleware, functions, static assets, and routing logic.”

Conclusion: Abstraction is Inevitable

Software development has always moved toward better abstractions. We abstract when the benefits of simplicity outweigh the costs of lost control, when patterns emerge that are stable enough to codify, when the manual work no longer creates competitive advantage.

Framework-defined infrastructure meets all these criteria. The patterns are stable, server-side rendering, static generation, API routes, and edge middleware aren’t going anywhere. The manual work, translating framework concepts to infrastructure primitives, creates no competitive advantage. The simplification, automatic infrastructure from framework code, delivers real value.

As Heroku’s evolution demonstrates, “ever-increasing complexity means developers need to build and operate more adaptable systems.” Framework-defined infrastructure represents exactly this kind of adaptability: composing infrastructure from framework patterns rather than manual configuration.

The question isn’t whether framework-defined infrastructure will become standard practice, but how quickly it will happen. Given that multiple platforms have independently adopted similar approaches, given that major companies successfully deploy framework-based applications across different infrastructure models, and given the clear economic benefits, the trajectory seems clear.

Abstractions that work become invisible. In a few years, explaining that you used to manually configure infrastructure for every framework route will sound as strange as explaining that you used to manually manage memory allocation. We’ll wonder why we ever did it differently.

How to Sync Apple Reminders with Android (When You're Hooked on the Menubar)

Tue, 23 Sep 2025 00:00:00 GMT

If you’re like me and have discovered reminders-menubar, you know exactly why leaving Apple Reminders isn’t an option. This open-source menubar app transforms Apple’s basic reminder system into something genuinely great - instant access with a keyboard shortcut, natural language input, and that satisfying feeling of capturing tasks without breaking your flow. And I’ve looked at other options, but nothing else comes close to the seamlessness of reminders-menubar on macOS, even if you’re willing to pay (and I’m not).

The problem? I also use an Android phone. And Apple Reminders doesn’t exactly play nice outside the walled garden.

So here’s my situation: I’m completely sold on the workflow that reminders-menubar provides on my Mac. It’s become part of how I think about task management - quick capture, always visible and with number that I hold myself accountable to. But when I pick up my Android phone, those reminders might as well not exist, or I might need to mimic them in another app - which was Google Keep for a while, but I kept forgetting to check it.

Fair warning, the solution I’m about to share isn’t perfect, as it does involve having a middleman, Microsoft, but after you try the reminders-menubar workflow, I’m pretty confident you’ll embrace it, like I have, as this is currently your best option when needing Android access.

Why Reminders-Menubar Changes Everything

But before we dive into the Android sync solution, let me explain why I’m going through this trouble instead of just switching to multi-platform tool such as Todoist or TickTick.

Reminders-menubar is a lightweight menubar Mac app that expands on Apple Reminders by gives you instant access to it through the menubar, or a quick keyboard shortcut. No opening apps, no clicking through menus, no friction.

The magic is that it uses Apple’s native EventKit framework, so everything syncs perfectly with iCloud. Your reminders appear instantly on your iPhone, iPad, and Apple Watch (even if in my case I only have my Mac). At the end of the day, it’s free, it’s fast, and it just works. Which is exactly why I don’t want to give it up just so I can have the same ToDos on my phone. I tend to avoid paid subscriptions when free alternatives exist, even if they aren’t quite as polished and require a bit more tinkering.

The Microsoft Bridge Solution

Here’s the workaround: it is actually quite simple, we’re going to use Microsoft’s ecosystem to bridge Apple and Android. Microsoft Outlook can sync with Apple Reminders on iOS, and Microsoft To Do can access those same reminders on Android. Plus Microsoft To Do has a pretty nice widget.

Setting It Up

The setup is surprisingly straightforward, even if the underlying architecture feels a bit convoluted.

macOS Setup

First, we need to configure your Mac to sync Apple Reminders with Microsoft:

Open macOS System Settings → Internet Accounts
Add your Microsoft account if it’s not already there
Make sure “Reminders” is checked in the account services
That’s it! Nothing else to configure here.

iOS Setup

On your iPhone or iPad:

Open iOS Settings → Apps → Reminders
Tap Reminders Accounts → Add Account
Add your Microsoft Outlook account
Ensure the “Reminders” toggle is ON
That’s it! Nothing else to configure here.

This creates the bridge so that reminders created through reminders-menubar (or the native Reminders app) sync to Microsoft’s servers.

On Your Android Device

Install Microsoft To Do from the Play Store and sign in with the same Microsoft account. That’s it. Your reminders should start appearing shortly. And since you’re using Microsoft To Do, you can actually use other platforms that integrate with it, such as Samsung’s native Reminder app.

The Only Downside Is Actually An Upside

Here’s the one quirk you should know about: when a reminder’s alarm fires, it rings on BOTH devices. And dismissing it on one device doesn’t dismiss it on the other.

Set a reminder for 3 PM, and at 3 PM both your iPhone and Android buzz. Dismiss it on Android, and your iPhone keeps nagging. This is particularly noticeable with recurring reminders (not that I have daily reminders that bug me on multiple devices simultaneously 🫣, but still).

This happens because each platform maintains its own notification state. The reminder data syncs perfectly, but the “I’ve handled this” status doesn’t.

But here’s the thing - I’ve actually started to appreciate this “bug” as a feature. It’s pretty hard to miss an important reminder when two devices are insisting you pay attention to it. Now, I hear you, notifications can be annoying. But for truly important deadlines or time-sensitive tasks, having that redundant notification system isn’t the worst thing in the world - we’re talking about reminders, after all.

The Bigger Picture

What strikes me about this whole situation is how it highlights the state of cross-platform compatibility in 2025. We’re still using workarounds and compromises to make basic productivity tools work across ecosystems.

Apple’s walled garden provides genuine benefits - the integration really is excellent when you stay inside it. But it punishes flexibility. The fact that a free, open-source Mac app (reminders-menubar) can make Apple’s basic reminder system more compelling than premium cross-platform alternatives says something about the value of deep platform integration, as well as the imense capabilities of open-source software.

Microsoft, ironically, has positioned themselves as the peace broker by building quality apps on both platforms and enabling sync between them. For now, if you need Apple Reminders on Android like me - especially if reminders-menubar is part of why you’re committed to Apple’s ecosystem - this Microsoft bridge approach is your best bet.

Is it elegant? No. Does it preserve the workflow that makes reminders-menubar so valuable? Absolutely. And honestly, once you get it set up, you’ll forget about the Microsoft middleman entirely - it just works seamlessly in the background while you focus on actually getting things done.

Elysia vs Hono: API Handlers in Astro with Cloudflare

Tue, 11 Mar 2025 00:00:00 GMT

When building a modern web application with Astro, one of the first decisions you’ll face is how to handle API routes. If you’re like me and enjoy the benefits of type safety and developer experience, you’ve probably considered using either Elysia or Hono - two popular Bun-first API frameworks that have gained significant traction in the TypeScript ecosystem.

I recently went through the process of migrating (on the same day 😅) from Elysia to Hono for my personal website, and I wanted to share my experience, particularly when deploying to Cloudflare Pages and dealing with environment variables.

The Initial Setup: Elysia

Let me be honest upfront - I didn’t strictly need a framework for my simple API routes. Astro’s built-in API functionality would have been perfectly adequate for my use case. But as developers, we often choose technologies not just for practical reasons, but also for the sake of experimentation and learning. I wanted to try something new and see what these Bun-optimized frameworks had to offer.

My journey began with Elysia, a framework that promises “sub-millisecond” performance and a delightful developer experience. Setting up API routes in Astro with Elysia is straightforward:

import { getTopTracks } from "~/api/lastfm";
import type { APIRoute } from "astro";
import { Elysia } from "elysia";

const app = new Elysia({ prefix: "/api", aot: false });

app.get("/top-tracks", getTopTracks);

const handle: APIRoute = ({ request }) => app.handle(request);

export const GET = handle;
export const POST = handle;

This worked perfectly in development. The API routes were fast, type-safe, and the developer experience was excellent. However, when I deployed to Cloudflare Pages, I encountered a significant limitation.

The Cloudflare Challenge

Cloudflare Pages uses a runtime environment that differs from your local development setup. One key difference is how environment variables are accessed. In Cloudflare, environment variables are not directly available through process.env but are instead passed through the request context, which means that it is not globally available like in your local development environment.

With Elysia, I couldn’t find a clean way to access the Cloudflare runtime context and pass it to my API handlers. My Last.fm API key was stored as a Cloudflare secret, which then is available as an environment variable, but my handlers couldn’t access it because Elysia’s handle method only accepts the request object, not the full Astro context.

const handle: APIRoute = ({ request, locals }) => {
  // No way to pass locals.runtime.env to Elysia handlers 😭
  return app.handle(request);
};

Enter Hono: The Solution

So, if Elysia was out of the question, I needed to find a new framework that could handle the Cloudflare runtime context. And who’s the second most popular framework after Elysia? Hono! And to be honest, Hono is becoming a way more exciting framework with a ton of built-in features.

Now, being aware of the problem at hand, I was quick to discover that Hono does offer a more flexible approach to handling contexts.

// [...slugs].ts
import { getNowPlaying, getTopTracks } from "~/api/lastfm";
import type { APIRoute } from "astro";
import { Hono, type Context as HonoContext } from "hono";
import type { BlankInput } from "hono/types";

type Bindings = {
  LASTFM_API_KEY: string;
};

export interface Context extends HonoContext<{ Bindings: Bindings }, string, BlankInput> {}

const app = new Hono<{ Bindings: Bindings }>().basePath("/api");

app
  .get("/now-playing", async (c) => getNowPlaying(c))
  .get("/top-tracks", async (c) => getTopTracks(c));

const handle: APIRoute = async ({ request, locals }) =>
  // To get the locals.runtime object correctly typed, we need to first follow the guide: https://docs.astro.build/en/guides/integrations-guide/cloudflare/#typing
  // Then we can pass the environment variables to the Hono app
  app.fetch(request, { ...locals.runtime.env });

export const GET = handle;
export const POST = handle;

The key difference is that Hono’s fetch method accepts a second parameter where you can pass environment variables and other context. This allowed me to pass locals.runtime.env from Astro’s context directly to my Hono app, making those environment variables available to my API handlers.

Refactoring the API Handlers

With this change, I also needed to update my API handlers to accept the Hono context:

// Before with Elysia
export const getTopTracks = async () => {
  const API_KEY = process.env.LASTFM_API_KEY;
  // Rest of the handler
};

// After with Hono
export const getTopTracks = async (c: Context) => {
  const API_KEY = c.env.LASTFM_API_KEY;
  // Rest of the handler
};

This approach has several advantages:

Improved type safety for environment variables
Access to Cloudflare-specific features
Cleaner separation of concerns
Better testability since dependencies are injected (not that I’m going to write tests for my personal website 🫣, but still)

Is my codebase heavily tied to Cloudflare Pages? A bit, but I’m okay with that. Moving from it, if I wore to move away from the amazing Cloudflare experience that I’ve been enjoying, would still be easier than the migration from NextJS (with CSS Modules) to Astro.

Performance Considerations

Both Elysia and Hono are incredibly fast frameworks, optimized for Bun and modern JavaScript runtimes. In my testing, I couldn’t notice any significant performance difference between them for my use case.

Elysia claims to be faster in benchmarks, but Hono’s flexibility with context handling made it the better choice for my Cloudflare deployment. As with most performance comparisons, your mileage may vary depending on your specific requirements.

Additionally, it’s worth noting that Cloudflare Workers uses the V8 JavaScript engine (not even Node.js), which means we’re running in a different environment than what these Bun-optimized frameworks were primarily designed for. Currently, if I wanted a true Bun runtime in production, I’d need to deploy a Docker container on a platform like fly.io, which adds complexity I’d rather avoid, or Render, a platform that I don’t really like. Cloudflare’s simplicity and performance make it worth adapting my framework choice.

Conclusion

The migration from Elysia to Hono was relatively painless and solved my specific issue with accessing environment variables in Cloudflare Pages. While both frameworks seem to be excellent choices for building API routes in Astro, Hono’s approach to context handling makes it particularly well-suited for Cloudflare deployments.

If you’re building an Astro site with API routes and planning to deploy to Cloudflare Pages, I recommend not using a framework at all, but if you want to use one, I recommend starting with Hono to avoid the limitations I encountered. The ability to pass the full runtime context to your handlers will save you time and frustration down the road.

Sometimes the best technical decisions come from experimentation rather than strict necessity. And I do like to experiment with new technologies, so I’m glad I went through this experience.

As a closing note, I’m extremely bullish on Bun as a JavaScript runtime. Its built-in HTTP server capabilities are becoming increasingly powerful with each release, potentially making it a compelling alternative to dedicated frameworks like Elysia or Hono (or even Vite for that matter) for certain use cases. As Bun continues to mature, we might find ourselves reaching for these frameworks less often, especially for simpler API routes. That said, the ecosystem around Bun is thriving precisely because of innovative frameworks like these, and I’m excited to see how they all evolve together.

Optimising prompt engineering for better AI outputs

Mon, 03 Mar 2025 00:00:00 GMT

This article was also published on the CNCF blog here and on the YLD blog here.

Remember when searching for information online involved typing in a few keywords and sifting through pages of results? Thankfully, those days are long gone.

Today’s search engines have transformed the way we find information online. From simple keyword matching to advanced technologies like semantic search and natural language processing, search engines have come a long way. But, have you ever stopped to consider the UX design choices that make these search experiences possible?

An effective UX/ search experience design involves a deep understanding of how humans interact with machines and the ability to adapt to that relationship. It’s not an innate skill, but rather something that can be developed over time, much like the act of googling is a skill that many of us have honed through years of practice. Similarly, interacting with Generative AI models requires a certain level of skill and knowledge which involves Prompt Engineering.

This article aims to provide a comprehensive guide to Prompt Engineering, helping you understand its importance, techniques, and best practices. You’ll be equipped to create effective prompts that maximise the potential of AI models and enhance user experiences.

Why is Prompt Engineering important?

Well-crafted prompts are essential for maximising the potential of AI models, particularly LLMs. They enhance AI performance by providing clear instructions and context, leading to more accurate and relevant responses.

Prompt Engineering improves user experience by making interactions more intuitive and reducing ambiguity, minimising the risk of misinterpretation. It enables AI models to handle complex tasks, adapt to different use cases, and ensure consistency in outputs, which is vital for integrated systems.

Precision in Prompt Engineering

Prompt Engineering is a discipline that involves developing and optimising prompts to efficiently use language models for a wide variety of applications and research topics. This discipline is particularly useful for developers, researchers, and anyone looking to leverage AI models for various applications and research topics. It encompasses various skills and techniques essential for interacting with and developing LLMs. Mastering this discipline enables you to optimise these interactions, achieving more accurate and relevant outcomes.

A prompt refers to a statement or question that is employed to trigger a response from a language model or other AI system. Prompts are generally crafted to offer context or instructions to the AI model, directing it to produce a specific type of output or carry out a particular task. A prompt can be provided to the language model by the user or by the system itself, serving as a means to define its default behaviour.

Creating effective prompts requires a deep understanding of both the AI model (various models respond uniquely to different types of prompts) and the user’s intent. Just as search engines use algorithms to understand the user’s query and return relevant results, Prompt Engineering involves designing prompts to communicate the user’s intent to the AI model.

Experimenting with different formats, testing various instructions and contexts, and refining the prompt based on the AI model’s responses are key to creating prompts that produce the desired response from the AI model while minimising the risk of misinterpretation or ambiguity.

The images below demonstrate how slight prompt variations can lead to very different results. However, consistency is crucial in integrated systems. A good prompt aims to produce repeatable outputs with minimal variation, ensuring reliable and predictable AI performance.

Screenshot of the first prompt: “What is spaghetti made of?”

Screenshot of the second prompt with a slight variation: ”What is spaghetti?”

When it comes to the daily interaction with an LLM, a varied yet similar result would be acceptable. But, when it comes to using an LLM as part of an integrated system, consistency is an important factor. What makes a prompt “good” is about producing a somewhat repeatable output with minimal variation.

Are all prompts equal?

No. Not all prompts are created equally because different types of prompts serve different purposes and can significantly impact the quality and relevance of the AI model’s responses. Understanding the various types of prompts and their applications is key to effective Prompt Engineering.

As a way to scientifically define methods of communication with LLMs, many have tried to create both techniques and frameworks that systematically define how to write these prompts.

Here are some common types of AI prompts that serve unique purposes:

One-Shot and Few-Shot prompts: If you want to follow a structure for a JIRA ticket, providing a well-structured template will help the AI generate similar ones. Few-shot or One-Shot prompts both help the AI adapt quickly to new tasks by providing a small set of examples, enhancing its ability to generate relevant and accurate responses. These prompting techniques involve providing the AI with examples of the desired task or output before asking it to complete a similar task. By showing the model what is expected through one or a few examples, the AI learns the context and format needed and applies it to new inputs.

Zero-Shot prompts: A practical use case is asking the AI to translate a sentence from English to French without providing any examples; the AI must rely on its pre-training to understand and perform the task. This approach is particularly useful for assessing how well the AI can handle novel or unexpected queries, demonstrating its ability to apply learned patterns to new contexts. Unlike few-shot prompts, zero-shot prompts require the AI to perform tasks without prior examples, relying solely on its pre-training. This approach is valuable for evaluating the AI’s adaptability and versatility.

Chain-of-Thought prompts: These prompts guide the AI to follow a logical progression or reasoning pathway to reach a conclusion or solve a problem. The prompt encourages the AI to detail its Each of these Prompt Engineering techniques can be adapted and combined depending on the specific requirements of the task at hand and the capabilities of the AI model being used.

Hybrid prompts: Combining multiple techniques, hybrid prompts might integrate direct instructions with creative challenges or conditional elements with exploratory questions to guide the AI more effectively according to complex needs. For example, you might provide the AI with a Few-Shot prompt to understand the structure of a report, then add a Chain-of-Thought prompt to ensure it details its reasoning, and finally include a Meta-prompt to ask the AI to reflect on its approach. Hybrid prompts are versatile and can be tailored to meet the specific requirements of various tasks, making them particularly useful for complex and multi-faceted projects.

Effective Prompt Engineering involves a deep understanding of these techniques and the ability to apply them creatively. By leveraging the right prompt type, you can significantly enhance the AI model’s performance and the overall user experience. If you want to read more about the several types of prompts, check out Prompting Guide’s techniques page.

Writing your best prompt

Crafting the perfect prompt is like giving directions to a slightly distracted, incredibly smart friend - you need to be clear, concise, and maybe even a little clever.

Start with a basic prompt and refine it iteratively based on the responses you receive, fine-tuning the AI’s outputs to your specific requirements. Incorporate relevant keywords and specific details to guide the AI more effectively towards the desired output.

Moreover, don’t use jargon or assume knowledge. Be aware of the model’s limitations to craft prompts within its capabilities, avoiding overly complex requests that lead to poor responses. Utilise feedback to continuously improve your prompts, as insights from users or the outputs themselves can guide adjustments for better results.

Mind the length of your prompts to prevent confusion and higher token consumption, which can increase costs.

Although the model may be equipped to handle specific challenges like trick questions about prime numbers, this doesn’t guarantee it can manage every query type. Even after conjuring the best prompt, the model can still confidently reply with false information. In some cases, it might only succeed because similar examples were included in its training data, as shown in the examples in the screenshot below:

Screenshot showing an interaction with Gemini, where the prompt contains trick questions, making it unlikely to provide a factual answer.

Screenshot of prompting ChatGPT to provide unbiased, factual mathematical answers about the possibility of prime numbers ending in 42.

Closing thoughts

If you find yourself facing a complex problem and need assistance in crafting effective prompts, don’t hesitate to ask AI for help. Leveraging the AI’s capabilities can provide valuable insights and suggestions to refine your prompts, ensuring you get the best possible outcomes. If you feel confident in your prompting capabilities, put yourself to the test against Gandalf.

Finally, different types of prompts complement each other, and combining them can lead to more effective and nuanced interactions with AI models. Whether you’re using One-Shot prompts for quick adaptation, Zero-Shot prompts for versatility, or hybrid prompts for complex tasks, understanding how to leverage these techniques together can significantly enhance the AI’s performance and the overall user experience.

The Future of AI Computing: WASM and GenAI

Mon, 02 Dec 2024 00:00:00 GMT

This article was also published on the YLD blog here.

While Generative AI (GenAI) has taken centre stage, Web Assembly (WASM) works in the background, complementing GenAI by shifting how we approach performance, portability, and security in web and cross-platform applications.

While these technologies may seem distinct, their combination unlocks exciting possibilities: WASM’s ability to deliver near-native performance in constrained environments perfectly complements the computation-heavy demands of GenAI models.

Together, they create a powerful partnership, improving how we deploy and experience AI-driven applications.

This article explores how GenAI and WASM work together to unlock new possibilities for businesses using AI applications. You will also learn some strategies to harness their full potential with accessibility and scalability in mind.

A perfect pair for the future of AI computing

WASM is a low-level, portable binary instruction format designed for safe, efficient execution across various environments. Initially created to enhance web application performance, it has quickly extended its reach to edge computing, serverless platforms, and embedded systems. Its appeal lies in three key strengths:

Near-native performance
Portability as a universal execution target
Security through its sandboxed environment (especially in browsers)

By decoupling code execution from specific platforms or architectures, WASM allows developers to build once and deploy anywhere, making this function an ideal approach to developing modern, distributed applications.

The rise of Vercel-like WASM-focused companies highlights the growing adoption of WASM’s unique benefits for developers. With WASM, developers gain greater autonomy and flexibility, enabling them to build and deploy high-performance applications without being tied to specific platforms. Additionally, companies using WASM can optimise performance while minimising resource usage, making the process of building and deploying applications much more efficient.

Generative AI, on the other hand, has rapidly advanced with models like o1 and Deepseek-R1 now capable of creating human-like text, generating realistic images, and even writing functional code. These models rely on vast amounts of training data and significant computational power, highlighting their potential for major innovation. At the same time, they spark important discussions about the resources required and the ethical considerations surrounding this powerful technology.

Opportunities, challenges, and key considerations

GenAI models are computationally intensive, making them difficult to deploy in resource-constrained environments. Real-time applications, which require fast responses, face challenges with traditional deployment methods, as they struggle to process data quickly enough. This leads to slower performance or, in some cases, failure to deploy. While tools like Ollama have proven that most models can run locally, the performance that you can find on basic devices, such as entry-level smartphones or laptops, is typically much lower than on more powerful systems like the one you’re reading this on.

However, despite these limitations, GenAI makes an excellent candidate for optimisation through WASM because WASM can make AI applications more accessible across a range of devices. While WASM offers a lightweight and portable execution environment, its ability to address GenAI challenges largely depend on the specific use case and optimisation strategies. Here are some key points to consider:

Portability: GenAI models compiled into WASM modules can run across platforms like browsers and edge devices. However, achieving smooth operation may require significant optimisations and adjustments for each environment.
Efficiency: WASM can improve inference performance in local setups, but the benefits may be limited for larger GenAI models or more complex workloads due to WASM’s current hardware limitations.
Scalability: Serverless platforms adopting WASM can simplify GenAI model deployment.
Privacy: WASM can help prioritise privacy by enabling GenAI models to run locally, but this approach may involve trade-offs in terms of model complexity and computational overhead.

For example, a WASM module could host a language model directly in a web browser, enabling offline chatbots without needing server connectivity. While tools like Ollama already offer similar functionality, WASM allows for browser-based deployment, which brings the flexibility that comes with the browser.

Real-world use cases

In the real world, we’re already seeing examples of WASM and GenAI working together, like Whisper running directly in the browser. This hybrid approach allows users to choose the model and adjust performance according to their needs. There are exciting possibilities on the horizon where WASM and GenAI could combine to create innovative solutions. Here are a few examples:

In-Browser AI Assistants: Deploy lightweight GenAI models directly in browsers using WASM, providing real-time assistance without network latency.
Edge Device Applications: Run WASM-optimised GenAI models on IoT devices for tasks like image recognition or anomaly detection.
Serverless AI APIs: Host GenAI models as WASM modules on serverless platforms, reducing operational costs while improving scalability.

These use cases demonstrate how WASM empowers GenAI to operate efficiently in diverse environments, from cloud servers to smaller edge devices.

Overcoming barriers to realise WASM and GenAI’s full potential

While the combination of WASM and GenAI promises a lot of great things, several challenges must be addressed:

GPU Limitations: WASM currently lacks native GPU support, making it difficult to accelerate GenAI workloads that rely on parallel processing, a critical feature for handling large-scale AI tasks.
Memory Constraints: This compute boundary is a significant hurdle for WASM when working with AI workloads requiring high levels of parallelism. Furthermore, large GenAI models often exceed WASM’s default memory limits, necessitating careful optimisation to fit these constraints.
Early-stage Ecosystem: While WASM is evolving rapidly, tools and libraries for integrating WASM with AI frameworks are still maturing, highlighting the ecosystem’s early-stage nature.

Emerging tools like WebLLM and platforms such as Turso are addressing some of these limitations in innovative ways. For example, WebLLM demonstrates the feasibility of running large language models directly in the browser by leveraging WebGPU for acceleration. It’s important to note that WebGPU is still an experimental API, and its integration with WASM for AI workloads is in its early stages, requiring further development and testing.

Similarly, Turso, a distributed database built on libSQL, has introduced features like native vector search and 1-bit quantisation for vector embeddings. These advancements make it easier to deploy AI applications that prioritise local-first processing and efficient resource usage. However, both WebLLM and Turso highlight the gaps in WASM’s ecosystem, such as the need for GPU integration and optimised toolchains for AI workloads. Addressing these challenges will be key to unlocking the full potential of this pairing.

How WASM and GenAI are redefining the future of software development

Looking ahead, advancements in both WASM and GenAI promise to deepen their integration through the following ways:

WebGPU Support: Introducing WebGPU to WASM environments will enable hardware acceleration for AI workloads. However, it’s worth noting that WebGPU is still an experimental API, and its integration with WASM for AI workloads is in the early stages, requiring further development and testing.
Model Optimisation: Techniques like quantisation and pruning will make it easier to deploy GenAI models within WASM’s constraints.
Standardised Toolchains: Improved tooling will simplify the process of compiling and deploying GenAI models as WASM modules.
Private Personal Assistants: Having the model run locally will open up the possibilities to protect the end user from endless data-sharing, one that is a given if the benefits of using AI keep increasing.

These developments are set to enable real-time, AI-driven applications that are fast, portable, and accessible to a wide range of users.

WASM and GenAI are two disruptive technologies poised to change how we build and deploy software. WASM’s portability and performance make it an ideal runtime for GenAI, enabling the creation of applications that are both powerful and accessible.

As these technologies continue to evolve, now is the time for developers to explore their synergy. Whether you’re building the next-gen AI assistant, a cutting-edge edge computing solution, or serverless applications, the pairing of WASM and GenAI offers endless possibilities to be unlocked.

critical mass portugal

Sun, 01 Sep 2024 00:00:00 GMT

Critical Mass is a worldwide movement, born in San Francisco in 1992, where cyclists meet on the last Friday of every month and ride together through city streets. Not a protest, a celebration - and an obvious-once-you-see-it argument that bicycles are real urban transportation, not toys. In Portugal it runs in Porto, Lisboa, Coimbra, and a growing list of smaller cities, organised entirely by volunteers, and until recently every chapter ran on its own scattered Instagram pages and WhatsApp groups.

massacritica.pt is the home I built for the whole movement: a single bilingual (PT/EN) site that lists every city’s monthly ride, surfaces upcoming events, hosts blog posts about cycling advocacy, and gives organisers a non-technical way to keep their content fresh. Built with Astro and TailwindCSS, internationalised via Paraglide.js for type-safe translations. Content management started on Sveltia CMS and recently migrated to emdash, Cloudflare’s new WordPress-style publishing platform, so contributors can edit through a friendly UI without ever touching git directly. Deployed to Cloudflare for fast edge rendering anywhere in the country.

The repo is open at github.com/afonsojramos/critical-mass - community pull requests for new cities and ride reports very welcome.

gitify

Fri, 12 May 2023 00:00:00 GMT

How are GitHub notifications supposed to work anyway? Do you keep the GitHub notifications inbox open in a browser tab, constantly refreshing? Or do you manage to handle the constant flurry of emails for every github notification? For me, the best way to manage something this important, is usually by keeping it in sight, and that’s why Gitify exists. A small menubar app for GitHub notifications. PR reviews, mentions, issue updates, and CI failures show up as an unread count in the menubar; clicking through takes you to the thread. Truly the best way to stay responsive at work and not miss any pings.

I joined the project as a contributor in mid-2023 and stayed on as a core maintainer alongside a small, dedicated team. A lot of the work is the load-bearing kind: improving a long-lived Electron app up to date with latest standards, aligning the UI with GitHub’s Primer design system so it feels native to the platform it surfaces, and triaging the steady stream of “this notification didn’t show up” reports that come with serving real users. Underneath that, a fairly constant cadence of new features ships with every release with the help of @setchy. Gitify today does meaningfully more than the app I first contributed to.

Over the years Gitify has accumulated over 1.75 million lifetime downloads across all releases, 5k+ GitHub stars, and a small but committed maintainer team. TypeScript end-to-end, Electron + React + Tailwind, tested with Vitest.

Feel free to give it a go at gitify.io!

Spicetify - An open-source journey

Mon, 12 Dec 2022 00:00:00 GMT

According to my message history, it all started around February 2020 when I found out about Spicetify through some random Reddit post in the illustrious r/unixporn - a subreddit where the highest tier of nerds share their Unix setups and configs - and I was immediately intrigued.

I had been using Spotify for a while, but even though the UI is not awful, they do have some very anti-user behaviours. Initially, I was simply a user, but then ideas to improve it started coming up, and I started to develop a more active role in the development. One of my first contributions was to the New Releases Custom App. This extension creates a page where we can see all the new releases for the artists we follow. Conceptually, it is a simple feature, however, Spotify’s “notifications” were practically useless, even to this day [1], which made it quickly become one of my favourite Spicetify features, which also led to my first contribution (spicetify-cli#247).

[1] They did do something on mobile, but if you follow more than 30 artists the list gets pretty polluted with singles. The only filter available is either Music or Podcasts, which is not very useful. And I mostly listen to Spotify on my PC anyway, so it doesn’t really matter.

Spicetify’s core, what we call spicetify-cli, is a Command-line Interface (CLI) tool that goes through Spotify’s binaries mutating them through regex matching to allow for the promised customisation. It is written in Go, which is a highly performant language that I learnt a couple of years prior to give a workshop on it at IEEE University of Porto Student Branch, a student branch of the IEEE that I was a member of at the time - and later was elected Vice-President for a year.

With time, I started helping out more and more in handling issues, developing small features, and keeping the latest Spotify version supported [2]. Eventually, khanhas made me a maintainer on GitHub to help with everything. In late 2021, Spicetify’s popularity truly blew up and we had to start handling a lot more issues and pull requests, which was a very exciting time for me. However, it was also the last time we saw khanhas, as he decided to leave the project and focus on other things. Thankfully, he left the project in a very good state, and I was able to take over as the new maintainer. Additionally, there were a small group of people that were already helping out with the project, which helped immensely.

[2] Spotify releases most of the times do not break the CLI itself, but when they do it is because we need to apply updates to the regexes that match the Spotify binaries. This is a very tedious process, but it is crucial to keep the CLI working.

It was September 2020 when I started working full-time, but it was in 2022 that my workload, other side-projects and overall life started pilling up a bit more, and, eventually, I noticed myself not being able to dedicate as much time to Spicetify as I would have liked. This is when I shifted to a more managerial role, where I would help out with the more complex issues, but also help out with the more mundane tasks, such as reviewing pull requests and merging them. I also created the Spicetify Documentation website, which is a very important part of the project, as it is the first place people look at when they want to customise their Spotify, unlike previously when people could only look at GitHub’s wiki, which was not very user-friendly for newcomers. And also created the Spicetify GitHub organisation, which is where all our repositories are hosted since previously they were hosted across several different contributors’ accounts.

Overall, it has been quite a ride, but seeing hundreds of thousands of downloads per GitHub release and over 200K unique visitors per month to our documentation is a very rewarding feeling. I am very grateful to all the contributors, users and maintainers that have helped out in this journey, and I hope that we can continue to make Spicetify better and better.

parrot

Sat, 01 Jan 2022 00:00:00 GMT

When Discord’s biggest music bots started shutting down one after the other in 2021 over copyright pressure, the obvious move for most servers was to find a hosted replacement. We took the opposite path and built our own: parrot, a small, fast, host-it-yourself Discord music bot designed to do one thing well - play audio from anywhere yt-dlp can reach, with as little ceremony as possible.

Written in Rust on top of Serenity and Songbird, parrot is built around the idea that a self-hosted bot should be a single binary with a .env file, not a service. A single docker run and you have a working bot. The codebase is small enough that new contributors can find their way around quickly, which is part of why it has kept growing.

It has been a long-running collaboration with @aquelemiguel and @joao-conde, focused on keeping the surface area small while staying responsive to the kinds of edge cases real Discord servers run into - flaky network conditions, large queues, abusive inputs. Source on GitHub.

album details extractor

Sun, 21 Nov 2021 00:00:00 GMT

Right-click any album, get clean JSON in your clipboard. That’s the whole product:

{
  "title": "Currents",
  "artist": "Tame Impala",
  "image": "https://image-cdn-ak.spotifycdn.com/image/...",
  "url": "https://open.spotify.com/album/79dL7FLiJFOO0EoehUHQBv"
}

My /music page is the running list of albums I have listened to and loved - partly automated, partly hand-curated. The friction of capturing the title, artist, cover, and canonical URL each time I wanted to add one was exactly the kind of annoyance that a small tool can fix. The output is the same shape no matter which store you started from, so the destination - a music page, a blog post, a music.json file - does not care.

There are five ways to trigger it, all wrapping the same extractor core:

Browser extension (Chrome and Firefox, MV3) - right-click any album link anywhere on the web, or use the toolbar button when on an album page
Bookmarklet - single-line javascript: URL, zero install, works on any browser
Standalone CLI - single-file binary, no runtime, prints JSON to stdout
Spicetify extension - adds the menu entry inside Spotify desktop’s native right-click

Supported sources: Spotify, Apple Music, Tidal, Deezer, Qobuz, and Bandcamp. Adding a new one is one file in src/shared/sources/ plus a registration line - every interface picks it up automatically.

Source at github.com/afonsojramos/album-details-extractor. The browser extension is on Mozilla Add-ons for Firefox and the Chrome Web Store for Chromium.

spicetify

Wed, 16 Jun 2021 00:00:00 GMT

Spicetify is a CLI written in Go that patches the official Spotify desktop client to allow theming, custom extensions, and entire custom apps. What started as a small modding project has grown into a full ecosystem: 20M+ lifetime downloads (~370k per release), 23k+ stars on GitHub, a marketplace for browsing community work, a creator framework for building extensions, and a thriving Discord community.

I have been a core maintainer since 2022, after @khanhas - the original author - stepped away. The handover happened just as the project was experiencing a surge in popularity, which meant inheriting a backlog of issues and pull requests alongside the very real work of keeping the CLI compatible with each new Spotify release. A lot of that work is regex-driven binary patching, which sounds fragile but is, in fact, fragile.

Beyond the maintenance work, I built and maintain the Spicetify Documentation - the canonical reference for installation, theming, and extension development. It pulls in around 300,000 visits a month! The opening remarks blog post goes into more depth on the history and how I ended up here. Source for the CLI lives at github.com/spicetify/cli.

Welcome to my blog

Mon, 14 Jun 2021 00:00:00 GMT

println!("Hello World!");

As a learning rustacean, I’ve chosen to start this blog with a classic, but rustic (has this joke been made before?), Hello World!

Bad programming jokes aside, I will use this blog to write posts about tech, music, states of mind, opinions, etc. Maybe I’ll even do one about beer 🍺! In reality, I don’t quite have any idea what I will write about, maybe about everything and maybe about nothing. But I’ll certainly try to write about something, even if it is an excuse to fuel my creative side!

As an engineer, I often consider myself too analytic in the creative process. Not that it is a bad thing, it’s just something that is part of me and that I am aware of. It is not for no reason that I’ve decided to focus on backend development, as problem-solving is my jam! However, if it involves designing, I’ll probably rely a lot on the “inspiration” phase, which roughly translates to “look at other designs and rip off all the good ideas”. Again, this is also not a bad thing - I think - but it means that my creative work will never be truly original and be based on building on what’s good ✨ out there ✨.

In the end, my admiration for the creative process of artists, designers and writers is immeasurable. It’s something that can be easily noticed by looking at the amount of music I listen to and concerts that I go to, but it goes way beyond that! We all have some sort of creativity within us, but some people are so much better at using it and that makes them amazing. And I hope that by creating this blog I can practice that, expand my creative side and that you enjoy this journey I am embarking on.

See you in the next post! ✌

discrakt

Wed, 01 Jan 2020 00:00:00 GMT

Discord Rich Presence has long been a fun way to broadcast what you are doing - playing a game, listening to Spotify - without saying a word. The same did not exist for what you were watching, especially across the messy reality of streaming today: a movie on the TV, an episode on the iPad in bed, something half-watched on a laptop. Discrakt fills that gap by polling Trakt for your “currently watching” status and surfacing it on Discord, regardless of where the content is actually playing.

I built it back when I was gaming a lot more and living in Discord most evenings. I do neither as much these days, but Discrakt has kept ticking along.

The trick is that anything that scrobbles to Trakt works. Stremio, Plex, Kodi, Infuse, VLC - any app with a Trakt integration reports playback in real time, and Discrakt picks it up. As long as you have one machine running Discord and Discrakt, your status follows you everywhere else: streaming on the TV from across the room, watching on your phone on the couch, even on a different device entirely.

Built in Rust for low overhead, the app runs quietly from the system tray with separate Rich Presence apps for movies and TV shows, localized titles via TMDB, deep links to IMDB and Trakt, and a browser-based OAuth setup wizard so the first run is “enter your Trakt username and you’re done.”

Available via Homebrew, Winget, and direct downloads on the releases page. Source on GitHub.