DEV Community: Calogero Cascio

Built a local AI ops platform where every feature is a plugin and Claude Code writes the plugins

Calogero Cascio — Tue, 19 May 2026 15:00:59 +0000

I have a confession: I keep starting "automation projects" and abandoning them at the same point.

The pattern is always the same. I write a script that does One Useful Thing: fetch some news, summarise it, post a draft somewhere. Three weeks later I want to add a second destination, or a different source, or a new model provider. The original script has grown a // TODO: refactor comment, and the new thing requires touching six files I don't remember (which is even worse since most of the code is written by Claude/Codex now).

So this time I tried a different rule:

Every feature is a plugin. The core knows nothing about my domain. If adding a capability requires me to edit the host, the host is wrong.

The result is BFrost (could you let me know what you think about this name in the comment?), a worker-first local AI operations platform (I'm publishing today as a public preview (v0.1.0)). It's a small Node.js host that runs on your machine, schedules jobs, moves items between producers and consumers, calls local and remote LLMs and renders a live React dashboard. Everything else (news harvesting, publishing to X or WordPress (current provided as an untested example), Telegram delivery, model providers, assistant tools) is a worker you drop into a folder.

Below: what makes this different from "yet another agent framework" what I had to give up to keep the rule honest, and how a bundled Claude Code skill scaffolds new workers without ever editing the core.

The one rule

Most extensible tools start extensible and decay. Plugins get "first-class" features the core knows about. Feature flags accumulate. The plugin API quietly becomes "the things our most-used plugin happens to need."

BFrost's hard rule, written into the repo's contributing docs and a Claude Code skill:

src/ outside src/workers/    →  domain-free. Never names a worker.
web/src/ outside web/src/workers/   →  same.
workers/local/<id>/   →  where your stuff lives.

That single constraint forced every interesting decision in the project.

What "worker-first" looks like in practice

A worker is a folder with three things:

workers/local/my-mastodon-publisher/
├── worker.json          # the manifest - id, surfaces, settings, cron jobs
├── src/index.ts         # the backend module
└── dashboard.tsx        # optional - a runtime-loaded React tab

The manifest is the single source of truth. It declares the worker's id, the cron jobs it contributes to the scheduler, the settings forms the dashboard should render for it, any credentials it needs, and any dashboard surfaces it owns. The host reads it, mounts the worker, and stays out of the way.

The backend module exports a BackendWorkerModule (TypeScript or JavaScript, your call). The host compiles TypeScript on first load with esbuild and caches the result or by clicking the activate button, in the dashboard). There's no build step you run manually; you edit the file, save, and the next time the worker is enabled the host rebuilds it.

// workers/local/my-mastodon-publisher/src/index.ts
import {
  listItemsForConsumer,
  applyConsumerSuccess,
  applyConsumerFailure,
  openWorkerKv,
} from 'bfrost';

export const workerModule = {
  manifest: /* loaded from worker.json */,
  jobs: {
    'mastodon-publish': async ({ workerId }) => {
      const items = await listItemsForConsumer(workerId, {
        itemType: 'news.article',
        excludeAlreadyHandled: true,
      });
      for (const item of items) {
        try {
          const post = await publishToMastodon(item);
          await applyConsumerSuccess(workerId, item.id, {
            metadata: { postUrl: post.url, postedAt: new Date().toISOString() },
          });
        } catch (err) {
          await applyConsumerFailure(workerId, item.id, { reason: String(err) });
        }
      }
    },
  },
};

That's it. No registration boilerplate, no DI container, no "register this with the scheduler." The host already knows about this worker because its folder exists.

The Item Bus is just a typed queue

When the news worker scrapes an article and the X publisher posts it, what's happening between them?

The temptation is to wire them directly. Worker A imports worker B, calls a method, done. That's also exactly what I'm trying not to do - now A knows B exists, and adding a third consumer means editing A.

BFrost's answer is the Item Bus. The shared queue is generic, owned by core, and looks like this:

{
  "id": "itm_abc",
  "producerWorkerId": "core.news",
  "itemType": "news.article",
  "tags": ["ai", "tooling"],
  "payload": {
    "article": { "title": "...", "url": "..." },
    "source":  { "host": "...", "label": "..." }
  },
  "metadata": {
    "local.publisher.wordpress": {
      "publishedUrl": "https://example.com/posts/xyz",
      "publishedAt": "2026-05-17T10:30:00Z"
    }
  }
}

A producer writes payload. Each consumer reads payload, does its work, and writes back into its own namespace under metadata. Consumers never mutate each other's metadata. That single discipline lets you have five consumers of the same item type without any of them caring about the others.

Want to add Mastodon? Subscribe to news.article, write to metadata['local.mastodon-publisher'] when you post. Want to add BlueSky? Same shape, different folder. The news worker doesn't know either of you exist.

Dashboards that workers own

The dashboard is a React SPA. Built-in workers ship their UI under web/src/workers/builtin/<id>/dashboard.tsx. Local workers can ship dashboard.tsx inside their own folder; the host bundles it with esbuild (browser target, IIFE, React resolved to window.bfrost.React so we don't ship a duplicate copy), serves it from /api/workers/:id/dashboard.js, and the admin app loads it via a <script> tag at runtime.

The bundle calls window.bfrost.registerDashboardView({...}) with the surface ids it claims. The host cross-references those against the manifest, so a worker can't accidentally take over a tab it didn't declare. Toggle the worker off and its tab vanishes. Edit the TSX, refresh, the new bundle is served because the ETag is mtime-derived.

This means an end user can install a worker and immediately see its dashboard, with its own KPIs, its own forms, its own events - without me approving anything or merging any PR.

What I had to give up

This isn't free. Several things became harder so that the contract could stay honest:

No worker can call another worker directly. Cross-worker coordination goes through the Item Bus (async) only. The synchronous "services" interface is on the roadmap but deliberately deferred until a real use case demands it.
The core never imports worker code. Even the bundled news, X publisher, and research workers live in src/workers/builtin/ and are loaded through the same registry path as any local worker. They prove the contract is expressive enough; they aren't load-bearing for the host.
No worker marketplace. Workers load from local disk only. No remote fetching, no signed worker bundles from the internet. v1.0 will get a permission/sandbox model first.
No magic on either side. No decorators, no reflection, no class hierarchies. A worker is a folder with a manifest and an exported object. If you can read TypeScript, you can read every line of how a worker is wired.

The payoff: I can read BFrost end-to-end in an afternoon. So can you. So can a Claude Code agent.

Claude Code writes the workers

This is the part that surprised me.

I bundled a Claude Code skill - bfrost-worker-author - inside the repo at .claude/skills/. When you run claude in a BFrost checkout and ask "create a new BFrost worker," the skill activates. It knows the worker contract, the file layout, the hard rules ("never edit the core"), and the order of operations (pick id → scaffold folder → declare surfaces → write tests).

A real session looks like:

> Add a BFrost worker that consumes news.article items and posts them
> to my Mastodon instance. I'll set the access token at runtime.

[Claude] I'll scaffold local.mastodon-publisher as a local worker under
workers/local/. Confirming a few things first:

  - Producer or consumer? → consumer of news.article
  - Credentials? → secret-reference field for the access token
  - Dashboard tab? → config-tab settings only (no custom tab)
  - Built-in or local? → local

Proceeding to scaffold...

Three minutes later there's a working worker. It reads news.article items, posts them, writes back into its metadata namespace, exposes a settings form, and ships with a README.md describing what it produces and consumes. The skill physically refuses to edit the core - if a request would require it, Claude stops and surfaces "this looks like a contract gap, here's what I think the core needs."

The whole reason this works is that the contract is small and stable. The skill isn't smart; the rules are simple enough that following them produces correct code.

What's in `v0.1.0`

Worth being honest about state. Today, v0.1.0 ships:

✅ The full worker-first contract (manifest, lifecycle hooks, dashboard bundles, item bus, per-worker storage).
✅ Built-in reference workers: news harvester, X publisher, research notes, Telegram channel, LM Studio provider, plus assistant-tool workers (memory, Google search, article fetch).
✅ Local TypeScript workers with compile-on-load (esbuild).
✅ A typed bfrost SDK that workers import from - the host registers it as a synthetic module so a worker can't accidentally bundle a duplicate copy.
✅ The Claude Code skill.
✅ A real-world example: workers/examples/wordpress-publisher/ consumes news items and publishes them to a self-hosted WordPress via the REST API. Copy it, configure it, run it.

What's deferred to v1.0:

🔜 A permissioned action runtime - formal approval queue + per-worker filesystem/network/credential scopes. Until this lands, keep destructive workers narrow.
🔜 Frontend smoke tests, per-worker metrics in the dashboard, an accessibility pass.
🔜 A hosted docs site and a Worker Gallery in the dashboard.

The browsable docs already live at https://convertprivately.com/bfrost/ - getting started, architecture, example workers, and authoring with Claude Code, all four pages.

Try it

git clone https://github.com/ccascio/BFrost.git
cd BFrost
npm install
npm run dev          # host + admin API
npm run dev:web      # dashboard at http://localhost:5173

Then either copy workers/examples/wordpress-publisher into workers/local/, or run claude from the repo root and ask it to scaffold a worker for whatever you actually want to automate. Star the repo if you like the direction, open an issue if you don't - the worker-proposal template is set up specifically for "I want to extend BFrost with X."

Why I'm publishing this now

The honest answer: because I've shipped the project past its own bar twice and held it back both times for "one more polish pass." Workstream 5 (the permission runtime) genuinely matters for v1.0 - workers that touch the real world need approval gates. But v0.1.0 is for people who want to read the code, copy an example, and tell me where the contract breaks.

If you build a worker, drop a link in the comments. If the contract doesn't fit your case, I want to know - that's a roadmap item, not a defect in your worker.

Repo: https://github.com/ccascio/BFrost
Docs: https://convertprivately.com/bfrost/
About me: https://convertprivately.com/about/

Lazy-loading a 600KB WebAssembly library in Next.js (without killing your bundle)

Calogero Cascio — Mon, 06 Apr 2026 12:00:19 +0000

A developer recently asked a great question on Stack Overflow: how do you use heic2any in a Next.js project without adding ~600KB to the client bundle?

They'd tried next/dynamic, await import() inside a function, even moving it to an API route. Nothing worked; the bundle stayed bloated.

I run ConvertPrivately, a set of 250+ browser-based conversion tools where files never leave the user's device. We use heic2any extensively for HEIC-to-JPG/PNG/WebP conversion, and we hit exactly this problem. Here's what we learned.

Why `heic2any` is 600KB (and why tree-shaking won't help)

heic2any bundles libheif compiled to WebAssembly. That WASM binary is ~500KB, and it's the HEIC decoder; you can't shake it out. If your bundler sees import('heic2any') anywhere in the dependency graph, it includes that chunk.

The problem isn't the dynamic import syntax. The problem is when the bundler resolves it.

Why `await import()` inside a function still bloats the bundle

This is the pattern most people try first:

async function convertHeic(file: File) {
  const heic2any = (await import('heic2any')).default;
  return heic2any({ blob: file, toType: 'image/jpeg' });
}

It looks like it should work; the import only runs when the function is called, right?

Not quite. Webpack (and Turbopack) perform static analysis at build time. They see the import('heic2any') string, resolve the module, and create a chunk for it. That chunk becomes part of the route's chunk group. Depending on your framework's prefetching strategy, it may get preloaded even before the user interacts with anything.

next/dynamic has the same issue; it's designed for React components, not arbitrary libraries. It wraps a component in Suspense, but the underlying chunk is still in the build graph.

Pattern 1: Web Worker (best for production)

The most reliable approach is to move the conversion into a dedicated Web Worker. Workers are separate entry points; the bundler emits them as independent chunks that are never preloaded or merged into your route's JS.

// lib/heic-worker.ts
self.onmessage = async (e: MessageEvent) => {
  const { buffer, toType, quality } = e.data;
  const heic2any = (await import('heic2any')).default;

  const blob = new Blob([buffer]);
  const result = await heic2any({ blob, toType, quality });
  const output = Array.isArray(result) ? result[0] : result;

  const ab = await output.arrayBuffer();
  self.postMessage({ buffer: ab, type: output.type }, [ab]);
};

// hooks/useHeicConverter.ts
export async function convertHeic(file: File): Promise<Blob> {
  const worker = new Worker(
    new URL('../lib/heic-worker.ts', import.meta.url)
  );
  const buffer = await file.arrayBuffer();

  return new Promise((resolve, reject) => {
    worker.onmessage = (e) => {
      resolve(new Blob([e.data.buffer], { type: e.data.type }));
      worker.terminate();
    };
    worker.onerror = reject;
    worker.postMessage(
      { buffer, toType: 'image/jpeg', quality: 0.92 },
      [buffer] // transferable - zero-copy
    );
  });
}

The key line is new URL('../lib/heic-worker.ts', import.meta.url). This tells webpack to emit the worker as a separate entry point. The main bundle stays completely clean.

Capping parallelism

One thing we learned the hard way: the WASM HEIC decoder is memory-hungry. If a user drops 20 photos at once and you spin up 20 workers, the tab will crash on mobile devices.

We cap concurrent workers at 2:

const MAX_PARALLEL = 2;
const queue: Array<() => Promise<void>> = [];
let running = 0;

async function enqueue(task: () => Promise<void>) {
  if (running >= MAX_PARALLEL) {
    await new Promise<void>(resolve => queue.push(resolve));
  }
  running++;
  try {
    await task();
  } finally {
    running--;
    queue.shift()?.();
  }
}

This keeps memory under control even during batch conversion of entire camera rolls.

Pattern 2: Manual chunk isolation with Vite/Rollup

If you're using Vite (we are), you can tell Rollup to isolate heic2any into its own chunk that's only loaded when actually imported:

// vite.config.ts
export default defineConfig({
  build: {
    modulePreload: false, // critical — prevents eager preloading
    rollupOptions: {
      output: {
        manualChunks: {
          'vendor-heic': ['heic2any'],
          'vendor-pdf': ['pdfjs-dist'],
          'vendor-xlsx': ['xlsx'],
        },
      },
    },
  },
});

The modulePreload: false is crucial. Without it, Vite injects <link rel="modulepreload"> tags that defeat the purpose of code splitting. With it disabled, the vendor-heic chunk only loads when your code actually calls import('heic2any').

In Next.js specifically, you don't have direct Rollup config access the same way, which is why the Web Worker pattern (Pattern 1) is more reliable.

Pattern 3: Script injection (simplest, least elegant)

If you just need it to work and don't care about type safety:

async function loadHeic2Any() {
  if ((window as any).heic2any) return (window as any).heic2any;

  return new Promise((resolve, reject) => {
    const script = document.createElement('script');
    script.src = 'https://cdn.jsdelivr.net/npm/heic2any@0.0.4/dist/heic2any.min.js';
    script.onload = () => resolve((window as any).heic2any);
    script.onerror = reject;
    document.head.appendChild(script);
  });
}

Zero bundle impact. The ~600KB loads from a CDN only when a user uploads a HEIC file. Downsides: no types, CDN dependency, harder to test.

Bonus: do you even need to convert?

Before loading 600KB of WASM, check if the browser can handle HEIC natively:

function canRenderHeic(): Promise<boolean> {
  return new Promise(resolve => {
    const img = new Image();
    img.onload = () => resolve(img.width > 0);
    img.onerror = () => resolve(false);
    // 1x1 HEIC test image (base64)
    img.src = 'data:image/heic;base64,AAAAHGZ0eXBoZWlj...';
  });
}

// Usage:
const nativeSupport = await canRenderHeic();
if (nativeSupport) {
  // skip conversion entirely — Safari, Chrome 130+
} else {
  const converted = await convertHeic(file);
}

Safari has supported HEIC natively for years. Chrome added support in version 130 (October 2024). If your users are mostly on modern browsers, you might be able to skip the conversion entirely for a growing percentage of them.

The bigger picture

This isn't unique to heic2any. Any large WASM library; ffmpeg.wasm (25MB), tesseract.js (15MB), pdfjs-dist (2MB); has the same bundling challenge. The patterns above work for all of them:

Web Workers for true isolation from the main bundle
Manual chunks + disabled preload for Vite/Rollup projects
Script injection as a quick escape hatch

The general principle: if a library is > 100KB and only used for a specific user action, it should never be in your initial bundle. Structure your code so the bundler can't even see it until the user needs it.

I built ConvertPrivately: 250+ file conversion tools that run entirely in the browser. HEIC, PDF, images, audio, data formats; all client-side, no upload, no account. The architecture decisions in this post come from building and optimizing that platform.