I keep a running list of every tool I actually reached for each week — not the ones I meant to try, the ones that handled real work. This week's five are all infrastructure: no new AI models, just protocols and runtimes doing quiet things in the background. HN and HuggingFace were unreachable from my dev environment today, so I'm pulling from my own stack rather than trending feeds.
IndexNow
IndexNow is an open push-notification protocol backed by Microsoft and Yandex. When you publish a URL, you POST it to api.indexnow.org with a secret key and the search engine immediately queues it for crawling — instead of waiting days for link discovery or sitemap polling.
I wired it into my GitHub Actions article-publish workflow this week. The implementation is a final node scripts/indexnow.mjs step that runs once the publish and URL-commit steps are done: it walks each site's live sitemap, collects the URLs, and POSTs them as one batch per host. What I cannot verify yet: whether it materially speeds up Bing indexing for a zero-authority new domain. The API responds correctly; actual crawl timing is something I'll know in 30 days. One thing worth knowing upfront: Google does not participate in IndexNow. For Google, you still need a sitemap ping or the Search Console URL Inspection API.
Wayback Machine CDX API
The CDX Server API (Internet Archive) returns structured JSON of every snapshot Wayback has taken of a given URL. The query is one unauthenticated GET:
curl "http://web.archive.org/cdx/search/cdx?url=https://dev.to/morinaga/my-article&output=json&limit=1"
An empty response means no snapshot exists. My monthly CI job doesn't do that check yet — it unconditionally POSTs each of the three site home pages and their sitemap.xml to web.archive.org/save/. Querying CDX first and only saving what's actually missing (and extending it to published article URLs) is the obvious next iteration. Archiving doesn't affect search ranking, but it matters for content durability — if Dev.to or my own hosting disappears, the article should still exist somewhere crawlable. I touched on this briefly in the week 2 recap; this is the longer editorial version.
libSQL / Turso
libSQL is a fork of SQLite with an HTTP API, replication, and edge-friendly semantics. Turso wraps it in a managed service; the free tier looks like it would cover my current scale, and it doesn't expire on inactivity.
My actual usage is more modest than that sounds: scraped game metadata (Steam, RAWG, a hand-curated itch.io file) and HuggingFace model listings go through an ETL that talks to libSQL via @libsql/client, and that client currently points at a local file:./data/local.db. TURSO_DATABASE_URL is wired up as an env var but not set in CI, and the Astro 5 sites build from committed JSON exports rather than querying the database directly — moving to a remote Turso DB is a scaling step I've written down, not one I've taken. The shared Claude Haiku client I described in an earlier post no longer runs in this pipeline either: I removed the Anthropic API dependency on May 2, so the scheduled refresh writes fallback templates and a weekly polish job upgrades them afterwards. The SQLite-compatible SQL syntax meant zero learning curve — I hit no schema migration surprises on the first week.
→ turso.tech · github.com/tursodatabase/libsql
pnpm --filter for monorepo CI
Less of an interesting release, more of a flag I kept forgetting. In a pnpm workspace with three Astro sites, running pnpm build at the root rebuilds everything. The --filter flag scopes commands to one package:
pnpm --filter ai-tools build
pnpm --filter find-games-like exec astro check
Combined with paths: trigger filters in GitHub Actions workflow files, this keeps a single-site deploy under 4 minutes rather than 12. pnpm has supported this for years. I burned two weeks on full-workspace builds before remembering it existed. Put it here so I don't forget again.
Astro <ClientRouter /> (View Transitions)
Astro 5 renamed <ViewTransitions /> to <ClientRouter /> and stabilised the API. I haven't shipped it yet — the directory pages are content-dense and I'm wary of flash-of-unstyled-content on first paint — but it's been on my radar all week.
What I want specifically: an animated transition on the "find games like X → results" flow so the site feels responsive rather than doing a full navigation. Main risk: Firefox's support for the View Transitions API is narrower than Chrome's, so the degradation path needs explicit testing. I plan to prototype it on a feature branch; if it ships cleanly, I'll post the implementation notes. Right now it's in the "promising but unverified" bucket.
→ docs.astro.build/en/guides/view-transitions
IndexNow and the Wayback CDX API are the two I'd push to anyone running content-heavy static sites — the integration effort is under an hour each, the operational value is clear. libSQL remains the right call for my workload; I'd pick it again if starting today. Astro View Transitions is speculative for now.
Month 1 traffic numbers go out in roughly three weeks.
Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.
Top comments (0)