DEV Community: Justin Henry

Angular 🤝 Preact: The Ultimate Team

Justin Henry — Tue, 13 Oct 2026 15:32:05 +0000

Why Angular and Preact?

Building scalable and maintainable frontend applications becomes a difficult task when the framework is too opinionated or too loose. The goal is to provide familiar patterns on both sides while sacrificing nothing. Once thought to be nigh impossible is now brought into fruition by bridging similarities between two very different frameworks.

Angular thrives on structural architecture design and enforcing boundaries that make sense for large scale applications. We know through many years that MVC is a solid pattern not to be dismissed easily. We also know that through many years of exploring flexible developer experiences that React's ability to adapt is unrivaled. Where these two can come together is through Preact's Signals library and combining the efforts that Angular and React have honed into a solid set of practices.

Angular's architecture, rendered by Preact: modules, DI, and class views without the template compiler

Pick a side, the industry says. Want structure? Buy the whole framework:
template compiler, DI container, opinionated everything, and a migration
path when the ecosystem moves on without you. Want flexibility? Assemble
it yourself: but the structure you improvise at ten files becomes tribal
knowledge at a hundred, and the conventions that kept things tidy exist
only in the senior dev's head. Frameworks sell you structure or
freedom, and quietly charge you for the one you gave up.

PreactMVC refuses the trade. It gives you Angular's structural
machinery (hierarchical injectors, module ownership, an enforced MVC
split) as a library over ordinary Preact: opt into scope enforcement
where it pays, and stay plain JSX everywhere else. Signals replace
change detection, every Preact library works unmodified, and the same
view classes optionally render inside Web Workers as islands. The sales
pitch in one sentence: this is structure you call, not structure you
join.

Flexibility: render() is just Preact

// counter.view.tsx
import { Component, Controller, View, inject, signal } from '@preact-mvc/core';

@Controller()
class CounterController {
  count = signal(0);
  inc = () => this.count.value++;
}

@Component({ controllers: [CounterController] })
export class CounterView extends View {
  private c = inject(CounterController);

  render() {
    return <button onClick={this.c.inc}>count: {this.c.count.value}</button>;
  }
}

A view is a class constructed once per mount inside its own injector
scope: inject() in field initializers, signals as plain fields, and a
render() that stays plain JSX forever. No hooks rules, no deps arrays,
no memoization audits. Construction is setup; render is projection.

And because render() returns ordinary Preact vnodes, flexibility
extends to the ecosystem itself. Icon sets, UI kits, preact/compat
React shims: drop them in. Function components keep their hooks and get
useService/useController/Provide as bridges into the injector.
Signal-aware libraries subscribe directly: our signals are
@preact/signals. Everything else takes two moves: provide the client
through DI, bridge subscribe into a scope-bound signal. The enterprise
demo runs TanStack Query, ECharts, zod, and a Tailwind/shadcn layer with
zero adapter packages: that is what "no lock-in" looks like measured.

Structure: the injector graph is the app map

@Module({
  imports: [RouterModule.forRoot(routes), QueryModule.forRoot()],
  providers: [SessionService],              // scoped here, visible down
  controllers: [DashboardController],       // shared by this module's views
  components: [DashboardView],              // may only mount in this scope
  bootstrap: [DashboardView],
})
export class DashboardModule {}

components is an ownership declaration, not a registry: a declared
view refuses to mount outside an injector carrying its module. That is
the difference between structure as convention and structure as
contract: the architecture diagram is enforced at mount time, not
reviewed at PR time.

Providers are Angular's shapes: a class, { provide, useClass },
{ provide, useValue }, { provide, useFactory, deps }. Resolution
walks view scope, module scopes, root. DestroyRef ties teardown to the
scope, so a subscription created in a constructor dies with the view:
the same guarantee useEffect cleanup reaches for, made declarative.

The @Controller layer completes the MVC split Angular implied but
never enforced: controllers own interaction state, views project
signals, injectable stores own domain state. Declaration decides
lifetime: transient, view-scoped, or module-shared.

Structure that bends: opt out wherever it pays

The strictness is per-declaration, not global:

Undeclared views mount anywhere. components is opt-in enforcement, not a gate: skip it and the view is just a value you import, function components included.
Standalone views carry their module. @Component({ imports }) pulls a module's providers into one view's scope, so a feature can exist with no owning module at all.
The router is a module too. RouterModule.forRoot(routes) is a provider import, and routes can mount either a loose component or a full module with its own injector.

You buy structure exactly where you need it: the payment boundary, the
admin surface, the team's shared feature. Everything else stays the
JSX you would have written anyway.

Why use this?

Because the alternative is choosing between a framework that owns your
codebase and one that leaves it ungoverned. PreactMVC is for
developers who want the module map, the injector scoping, and the MVC
discipline: priced as four small packages, rendered by the 3kB engine
you already trust, compatible with the ecosystem you already use.

npm install -g @preact-mvc/cli
pmvc new my-app --islands
cd my-app && pmvc serve

The docs site walks DI, views, signals, the router, and the islands
contract end to end, with the demo and enterprise apps embedded live.

jwhenry3.github.io/preact-mvc

Inspecting Traffic and Details on Workers Isn’t Easy. Let’s Fix That.

Justin Henry — Sun, 04 Oct 2026 17:48:48 +0000

AtollJS is an open-source SDK for moving real work off the main thread: typed worker pools you call like local objects, shared-memory state that stays in sync across threads without serialization on the hot path, and UI islands that render React, Vue, Solid, Svelte, or Angular entirely inside web workers. The core is ~12 KB gzipped on the main thread with no runtime dependencies.

A pool is a method list on the worker side and a typed Proxy client on the main side:

// counter.worker.ts: the worker entry; methods live here
import { defineWorker } from '@atolljs/core';
import { counterMemory } from './counter.memory';

export const counterWorker = defineWorker({
  sharedMemory: counterMemory,
  methods: {
    increment(delta: number) {
      const next = counterMemory.count.read() + delta;
      counterMemory.count.write(next);   // in-place shared-memory write
      return next;
    },
  },
});
export type CounterWorker = typeof counterWorker;

// counter.ts: the main thread imports the type only, no worker code
import { connectWorker } from '@atolljs/core';
import { counterMemory } from './counter.memory';
import type { CounterWorker } from './counter.worker';

export const counter = connectWorker<CounterWorker>({
  sharedMemory: counterMemory,
  worker: () => new Worker(
    new URL('./counter.worker.ts', import.meta.url),
    { type: 'module' },
  ),
  poolSize: 'auto',   // navigator.hardwareConcurrency
});

await counter.increment(1);   // typed RPC; the pool spawns on first call

That ergonomics story has a catch, and it's the subject of this post: the moment real work moves into a pool, your app becomes a black box. console.log across eight threads is a scramble, the browser's own devtools treat workers as second-class (a list of threads you can switch between, one at a time), and the question that matters, which worker is slow, and doing what?, has no answer.

@atolljs/devtools is our answer: a live observability surface for the whole worker system, and it was almost free to build, because AtollJS's architecture already knew the shape of the system it was observing.

One line, gated by the URL

import { initDevtools } from '@atolljs/devtools';

initDevtools({ session: { name: 'my-app' } });
// Call before pools spawn: workers forward events only if the sink
// existed at INIT time.

Then:

my-app/?__atoll_devtools   → devtools on, dashboard flyout mounts
my-app/                    → zero cost; no sink installed

The ?__atoll_devtools param is the gate: production builds ship the code and never activate it. Turned on, initDevtools installs the event sink and mounts the overlay: a draggable, resizable flyout holding the full dashboard, served by the AtollJS vite plugin on your own origin at /__atoll/: no separate port, no extension, no CORS story.

What you see

The dashboard is a static, dependency-free app, index.html + main.js, no build step, rendering whichever event stream it hears:

The app map: one world-space canvas drawn like the logo it's named for: your app session at the center, pool sockets on the inner rim, workers on the mid orbit, islands on the outer orbit rendered as framework marks (⚛, V, S, A…). Wheel to zoom, clustering tiers collapse islands into a ring, sessions into labeled discs, click to drill into any worker or island's own inspector.
Tasks: a waterfall with one swimlane per worker slot: queued→dispatched→settled segments colored by outcome, per-task aggregates (failures, wait avg, run p95/max) with click-to-drill.
Network: rolling traffic charts plus a real fetch() log from main thread and workers; click a row for headers, capped body previews, sizes, and a Resource-Timing stage breakdown.
Memory: per-field shared-memory write rates (writes/sec, last writer poolId#slot, sparkline) next to per-context JS heap, every worker's heap identified by its script URL.
Islands / Workers / Pools: entity tables: round-trips, op batches, replay ms, respawns, errors, live state, cross-linked, since island:mount carries the client's poolId.
Log: the raw event stream when nothing else will do.

Sessions are pages and processes. A disconnected page doesn't vanish: it's retained (bounded) as an ended session so post-mortem history stays attributed; pin the ones you're comparing, dismiss the noise, let the TTL sweep the rest.

Why it was cheap

The part worth stealing for your own observability work is how little plumbing this took, and it doubles as the best argument for the platform
underneath: every transport decision leans on structure AtollJS already
had.

A sink, not a wire. Core instrumentation never transports anything. emitDevtools(event) is one branch on a module-level sink; connectDevtools() is the only production code that installs one. That single seam is why "off" costs literally nothing, and why every transport produces an identical event stream.

One transport per app, never per worker. This is where the pool design pays for itself. Workers don't get sockets; each event wraps in an ATOLL_DEVTOOLS postMessage on the task channel the pool already owns, and the main thread re-emits it stamped worker: {poolId, slot}. A poolSize: 32 pool costs exactly one connection, and the stream arrives single-ordered, which is what makes the waterfall lanes legible at all.

The transport is the scoping. In a browser window the default is BroadcastChannel: pure client, no backend, and same-origin isolation by spec: a dashboard can only ever hear apps on its own origin. That's not a filter; it's a guarantee. Node and cross-origin aggregation opt in to the WebSocket path instead, pointed at the standalone server (npx atoll-devtools, loopback port 4780): which is also what makes post-mortem retention possible, since it outlives the page.

Guard the hot paths, not the log. memory:write fires on every shared-memory commit: write-rate frequency, and AtollJS shared memory is designed for exactly that kind of write rate. The call sites check devtoolsEnabled() before building the event object, not just rely on the sink no-op. Cheap is a design decision made at the call site, not a hope placed in the transport.

On Node, same stream

AtollJS pools also run on node:worker_threads (Express, Fastify, Hono, Koa, NestJS adapters), and the devtools follow: Node takes the WebSocket path by construction, pointed at the same standalone server, which is the dashboard:

// src/devtools.ts: a dedicated module, imported FIRST from the entry.
// No-op unless ATOLL_DEVTOOLS is set in the environment.
import { initDevtools } from '@atolljs/devtools/node';
initDevtools({ session: { name: 'my-api' } });

// main.ts: ESM evaluates imports before the body runs; pools spawn
// inside sibling modules (or NestFactory), so the sink must be first.
import './devtools';

ATOLL_DEVTOOLS=1 npm run start &
npx atoll-devtools          # http://127.0.0.1:4780

Worker-side events still reach the sink automatically: the pool stamps a devtools flag into INIT, worker_threads forward over the task channel, and process.memoryUsage() fills the per-worker heap columns. Express and NestJS sessions land on the aggregate dashboard as runtime: 'node', right alongside any browser apps pointed at the same server. One stream shape, both runtimes.

Try it

npx @atolljs/cli new            # scaffolds a runnable project
npx @atolljs/cli add devtools   # init module + @atolljs/devtools install

Spawn a pool, open your app with ?__atoll_devtools, and watch the map draw itself. Everything above ships in the repo today:

GitHub: github.com/jwhenry3/atolljs
Docs and live demos: jwhenry3.github.io/atolljs
Devtools internals and invariants: docs/devtools.md
Node wiring examples: examples/express, examples/nestjs

If you've got a worker pool in production and no way to see inside it, we'd love to hear what the dashboard is missing.

Five Frameworks, One Page, Zero Runtime Tax — Micro-frontends in Web Workers

Justin Henry — Sat, 03 Oct 2026 03:23:08 +0000

Your micro-frontends are sharing one thread. AtollJS's aren't.

The micro-frontend pitch is great: teams own their features, ship on
their own cadence, pick the framework that fits the problem. The
asterisk nobody puts in the README: every one of those frameworks runs
on the same main thread, in the same module graph, fighting for
the same 16ms frame budget.

Module federation, import maps, iframe sandwiches — the orchestration
varies, but the physics don't. Pick Vue for one widget and Angular for
another and every user loads every runtime. "Independent teams" quietly
becomes "every framework on every page, all the time."

I built AtollJS around a
different answer: run each micro-frontend inside a real Web Worker.
Not a shim, not a renderer subset — the actual React/Vue/Solid/Svelte/
Angular runtime, rendering in its own thread, streaming DOM ops back to
the page.

The result is the thing micro-frontends always promised:

Real isolation — a wedged MFE wedges its worker, not your page
Real independent deployment — the worker bundle is a URL; ship it from npm or a CDN without touching the shell
Zero runtime tax — the shell never imports or bundles the MFE's framework. A React shell hosting a Vue island loads zero bytes of Vue

The trick: the shell imports a contract, not a component

Here's the part that makes it work. Instead of importing the MFE's
component tree, the shell imports a framework-neutral contract —
the MFE's entire public API in one dependency-free module:

// counter.contract.ts — the package's only export.
// No framework imports: runs on the main thread AND inside the worker.
import { z } from '@atolljs/core';
import { defineIslandContract } from '@atolljs/islands';

export const counterContract = defineIslandContract({
  app: 'counter',
  props: z.object({ label: z.string().optional() }),
  events: {
    incremented: z.object({ count: z.number(), label: z.string() }),
  },
  worker: () => new Worker(bundledWorkerUrl, { type: 'module' }),
});

Four fields: which app to register, what props it accepts, what events
it emits, and where its worker lives. The schemas aren't decorative —
the worker enforces them at runtime, so a producer that ships a prop
rename fails loudly with a schema error naming the field instead of a
silent undefined three teams away.

The shell gets a real component anyway

From the consumer side it's just your framework, fully typed. React
shell:

import { islandComponent } from '@atolljs/react-island';
import counterContract from '@atolljs/mfe-counter';

const CounterIsland = islandComponent(counterContract);

<CounterIsland
  label="alpha"                    // typed from the props schema
  onEvent={(name, payload) => {    // payload narrows per event name
    console.log(name, payload);    // 'incremented', { count, label }
  }}
/>

Vue, Solid, Svelte, and Angular shells get the same inference through
their own facades — defineIslandComponent, an injectable, whatever's
idiomatic. The types flow from the contract module, so the shell never
installs the worker's framework or its types.

And since the worker attaches the same contract object, the two
ends can't drift:

// counter.worker.tsx — inside the worker bundle
export default defineReactMonoWorker(CounterApp, {
  contract: counterContract,  // mount, updateProps, emit all validated
});

The 5×5 matrix, with no glue code

The matrix that falls out of this is the fun part: any supported
framework in the shell × any supported framework in the worker — all
25 combinations ride the same op protocol. No per-pair adapters, no
glue code.

The repo proves it rather than claiming it:
examples/
has five shell apps — React, Vue, Solid, Svelte, Angular — each
mounting the same five worker-rendered MFEs written in all five
frameworks. Same API every time.

Independent deployment is the actual product

This is where worker MFEs stop being a neat demo and start being an
architecture. A published MFE is two artifacts in two lanes:

// package.json — the producer
{
  "exports": { ".": "./src/mfe/counter.contract.ts" },
  "files": ["src/mfe", "dist-mfe"]
}

The contract is the module entry — consumers import it.
The worker is a fetched asset — dist-mfe/counter.worker.js, one self-contained bundle from vite build --config vite.mfe.config.ts.

Two distribution shapes, both working end-to-end in the repo:

npm package — ship dist-mfe/ inside the package. The contract's new URL('../../dist-mfe/counter.worker.js', import.meta.url) makes the consumer's bundler emit it byte-for-byte.
CDN / remote origin — point the contract's factory at your CDN. Versioned URLs mean the shell and the MFE upgrade on independent schedules — the whole point.

One gotcha worth knowing if you go remote: worker script URLs must be
same-origin (new Worker('https://cdn…') throws SecurityError
regardless of CORS). The escape is a one-line blob: shim that imports
the remote bundle — it's in the docs and the generated contract
template.

Scaffolding, not boilerplate

You don't hand-write any of this:

# standalone publishable MFE package
atoll new my-mfe --framework react --mfe

# add an MFE to an existing project
atoll add mfe counter

That emits the contract, the worker, a self-contained publish build,
and a dev harness that mounts the island through its own contract — so
vite dev previews exactly what your consumers will see.

Honest limits

This isn't free magic, so the caveats:

Workers are capability isolation, not a security boundary — same-origin workers still share storage and can fetch. Great for untrusted-ish vendor widgets; not a sandbox.
Cross-seam traffic is postMessage — cheap, but don't put per-mousemove state through it.
If you have one team, one framework, one repo: skip the distribution machinery entirely. A plain mountIsland gets you the worker perf isolation without the packaging story.

Try it

If "isolation and independent deployment" is why you wanted
micro-frontends in the first place:

Docs + live demos of all 25 combos: jwhenry3.github.io/atolljs/consumer/island-mfe
Repo: github.com/jwhenry3/atolljs — the mfe-publish / mfe-consumer pair is a working publish-consume round-trip
npm: npmjs.com/org/atolljs

Curious what breaks when you try this in your stack — drop a comment.

Breaking the Single-Threaded Barrier: How AtollJS Brings True Multithreading and Shared Memory to Modern JavaScript

Justin Henry — Thu, 01 Oct 2026 04:21:11 +0000

JavaScript has had workers for fifteen years, and the way most apps use
them hasn't changed: pick the expensive function, post it some data,
await the result. That works, until the work isn't a function call.
It's a million-row scan. It's a UI tree re-rendering every frame. It's
state that both threads need live, not cloned-and-stale.

AtollJS is built around four goals, each one a layer:

1. Share state, don't serialize it

postMessage clones everything, fine for results, wrong for state a
worker updates continuously. The raw alternative, SharedArrayBuffer,
is fast and gives you nothing to keep both sides honest.

So the layout is a type. defineSharedMemory takes a spec of
fixed-width fields and compiles it to a deterministic byte layout,
one declaration, imported by main and worker alike:

// incidents.memory.ts - the contract both threads import
import { defineSharedMemory, field, reef } from '@atolljs/core';

export const incidentsMemory = defineSharedMemory({
  lists: {
    incidents: field.list({
      schema: reef.object({
        id:       reef.u32(),
        severity: reef.int(0, 3),    // domain bound → narrowest width (u8)
        site:     reef.string(10),   // 10 inline UTF-8 bytes, schema-enforced
        open:     reef.boolean(),    // flag byte
      }),
      count: 1_000_000,
    }),
  },
  signals: { seedProgress: field.number() },
});

The schema is the layout: reef mints validators the compiler reads a
byte width from, so the two sides can't disagree - there's only one
source of offsets. And it costs nothing you didn't ask for: the schema
engine is vendored into reef, so no zod dependency ships with the SDK.

Deep dive: Shared Memory Is a Contract, Not a Buffer.

2. Make worker calls feel like method calls

A worker is an RPC surface - it should look like one. defineWorker
declares the method list inside the worker; connectWorker gives the
main thread a typed proxy over a lazily-spawned pool:

// incidents.worker.ts - worker side owns the runtime
import { defineWorker } from '@atolljs/core';

export const incidentsWorker = defineWorker({
  sharedMemory: incidentsMemory,
  methods: {
    async seedIncidents(n: number) {
      /* writes straight into shared memory - results don't cross postMessage */
    },
    queryIncidents(q: QueryArgs) { /* scan in place, return the page */ },
  },
});

// main.ts - the client is a Proxy typed by typeof worker
import { connectWorker } from '@atolljs/core';
import type { IncidentsWorker } from './incidents.worker'; // type-only

const incidents = connectWorker<IncidentsWorker>({
  sharedMemory: incidentsMemory,
  worker: () => new Worker(
    new URL('./incidents.worker.ts', import.meta.url), { type: 'module' },
  ),
  poolSize: 'auto',
});

await incidents.queryIncidents({ offset: 0, limit: 50 });

import type matters: worker code never enters the app bundle. Under
the hood the pool handles what bare workers don't - queueing,
taskTimeout, cancellation, crash respawn. A pool call always settles.

Deep dive: Worker Pools That Fail Gracefully.

3. Let results flow back as reactivity

The payoff of shared memory is live reads - main doesn't await a
return value, it watches the field the worker is writing:

import { observe, defineTask } from '@atolljs/core';

const progress = observe(incidentsMemory, 'signals.seedProgress');
// snapshot-stable, refcounted - activates on first subscriber

const queryTask = defineTask((q: QueryArgs) => incidents.queryIncidents(q));
// { data, pending, settled, elapsedMs, error } - latest-wins by default

observe and defineTask are the primitives; framework bindings adapt
them - useSharedValue/useTask in React, equivalents in Vue, Solid,
Svelte, Angular, Next.js. Your component subscribes; the worker writes;
the diff flows through the version counter, not a message.

Deep dive: Reactivity Without Messages.

4. Render UI itself off-thread

Push the idea to its limit and the framework tree can live in the
worker too. @atolljs/islands mounts a registered app inside a worker;
it renders against a proxy document and streams serialized DOM ops back
to a driver that replays them. A React island, end to end:

// counter.app.tsx - a plain React component; it runs INSIDE the worker.
// islandApp() stamps it with its registry key (minification-proof).
import { useState } from 'react';
import { islandApp, type EventPayload } from '@atolljs/islands/worker';
import { emit } from '@atolljs/react-island/worker';

// Worker-side handlers get the wire payload - { type, value, key } -
// not a SyntheticEvent; handler() adapts it to JSX's event prop types.
const handler = <E,>(fn: (e: EventPayload) => void): ((e: E) => void) =>
  fn as unknown as (e: E) => void;

export const CounterApp = islandApp('counter', function CounterApp({
  label = 'count',
}: {
  label?: string;
}) {
  const [count, setCount] = useState(0);    // state never leaves the worker
  return (
    <button
      onClick={handler(() => {
        const n = count + 1;
        setCount(n);
        emit('incremented', { count: n });  // island → shell channel
      })}
    >
      {label}: {count}
    </button>
  );
});

// counter.worker.tsx - the whole worker entry
import { defineReactPolyWorker } from '@atolljs/react-island/worker';

export const counterWorker = defineReactPolyWorker({
  apps: { counter: CounterApp },            // one worker, many islands
});

// counter.island.ts - a shell-safe contract module: registry key + worker
// factory, no worker code imported. The dynamic import is the bundler's
// split point - it (and the worker entry) only loads when the island mounts.
export const app = 'counter';
export const worker = () =>
  new Worker(new URL('./counter.worker.tsx', import.meta.url), { type: 'module' });

// app.tsx - the shell is ordinary React; the facade is the boundary.
// lazyIsland mints a proxy component off the contract - attrs ARE the props.
import { Suspense } from 'react';
import { lazyIsland } from '@atolljs/react-island';

const CounterIsland = lazyIsland(() => import('./counter.island'));

export function App() {
  return (
    <Suspense fallback={<p>mounting worker…</p>}>
      <CounterIsland
        label="clicks"                      // serialized across postMessage
        onEvent={(name) => name === 'incremented' && console.log('worker-side click')}
      />
    </Suspense>
  );
}

// main.tsx - an ordinary bootstrap; React on both sides, DOM on one
import { createRoot } from 'react-dom/client';

createRoot(document.getElementById('root')!).render(<App />);

Render, diff, and state all run off the main thread - what's left behind
is a thin shell replaying ops. The facade wraps the same mountIsland
driver call - the contract's dynamic import is the split point, so a
heavy island's chunk only loads when it mounts - and the driver takes a
bare element on framework-free shells.
Per-framework packages (react-island, vue-island, …) keep each
worker's renderer to the framework it actually uses.

Deep dive: Islands That Render in Workers.

On the server - NestJS

Everything above is the browser story; the pool doesn't change when the
runtime does. On node:worker_threads, @atolljs/nestjs puts the pool
behind dependency injection: AtollModule.registerPool makes it an
injectable provider, and @AtollService makes a service class the
interop surface - inject it anywhere and every method dispatches:

// digest.service.ts - the decorator picks the thread
import { Injectable } from '@nestjs/common';
import { AtollService } from '@atolljs/nestjs/decorators';
import { defineSharedMemory, field } from '@atolljs/core';

export const digestMemory = defineSharedMemory({ jobsDone: field.number() });

@Injectable()
@AtollService({ pool: 'digest' })   // every method dispatches to the pool
export class DigestService {
  async hash(input: string) {
    // executes inside the worker's own Nest context
    // injected dependencies resolve there too
  }
}

// digest.module.ts - the API-thread side: the feature module owns the
// pool and the shared memory it was built on
import { Module } from '@nestjs/common';
import { Worker } from 'node:worker_threads';
import { AtollModule } from '@atolljs/nestjs';
import { digestMemory, DigestService } from './digest.service';

@Module({
  imports: [
    AtollModule.registerPool({
      name: 'digest',
      // webpack emits the worker entry as its own chunk
      worker: () => new Worker(new URL('./digest.worker.ts', import.meta.url)),
      sharedMemory: digestMemory,
      poolSize: 2,
    }),
  ],
  providers: [DigestService],
})
export class DigestAtollModule {}

// digest.worker.ts - the whole worker entry
import { runAtollWorker } from '@atolljs/nestjs/worker';
void runAtollWorker(DigestAtollModule);

// digest.controller.ts - injecting the service is the whole consumer story
import { Body, Controller, Post } from '@nestjs/common';

@Controller('api/digest')
export class DigestController {
  constructor(private readonly digest: DigestService) {}

  @Post('hash')
  hash(@Body() body: { input: string }) {
    return this.digest.hash(body.input);   // dispatches to the pool
  }
}

// app.module.ts - forRoot once; feature modules own their pools
@Module({
  imports: [AtollModule.forRoot(), DigestAtollModule],
  controllers: [DigestController],
})
export class AppModule {}

// main.ts - an ordinary bootstrap; nothing about it is worker-aware
import { NestFactory } from '@nestjs/core';

const app = await NestFactory.create(AppModule);
app.enableShutdownHooks();               // pools terminate on module destroy
await app.listen(3100);

Each worker boots its own Nest application context, so the method body
runs with real DI on both sides - the class file is the contract, the
same discipline as every browser layer. Node needs no COOP/COEP for
SharedArrayBuffer, so shared memory comes along free; and a route
subtree can even be housed inside workers outright, proxied at the
framework boundary.

Deep dive: Dependency Injection Across the Boundary.

What ties it together

Every layer leans on the same discipline: declare once, in types both
threads share. The memory contract is a schema; the worker surface is
typeof your worker module; islands scope every mount to an app@N
instance. Nothing is duplicated across the boundary - so nothing drifts.

And the footprint follows the same rule. Dependencies stay external and
opt-in - no shared-memory fields means no schema code in your bundle at
all; islands need no SharedArrayBuffer and no special headers, so the
graceful-degradation story is real. The whole stack is what you use of
it, byte for byte.

Teachable Moments

Justin Henry — Wed, 09 Jun 2021 18:46:36 +0000

Why do teachable moments matter?

When there is an opportunity to enlighten those around you, any time you don't act on it is basically withholding potentially helpful information, which could have negative effects.

How do I decide when to act on a teachable moment?

You will probably encounter many scenarios where you have a different opinion than someone, or you are asked what you think about a problem or solution. If you happen to have some knowledge on the topic, don't feel like your voice doesn't matter. You'd be surprised at where great ideas come from.

Does providing a teachable moment mean I am egotistical?

Not always. Wording your expressions in just the right fashion can express your care and devotion to spreading knowledge when it is needed. Coming from a place of "I've experienced that too, and let me show/tell you how I solved it in my scenario" is better than "This is the right way to do this, if you don't do this, you're wrong"

What happens if my opinion is challenged?

Accept the challenge. The point of presenting an alternative view is to compare and agree on a solution that works best for each other. If one solution works for you, it may not work for another person's case. It is excruciatingly difficult to find one-size-fits-all solutions that helps everyone. Accept the fact that your opinion might not always be the answer, just express that your opinion exists and move on.

Why did you write this post?

I decided that there have been so many comments on DEV articles where they express their opinion in such a negative context, like "Why did you choose that language, it sucks!" or "I can't believe you think that...". As a community, we should spread awareness that your views on a given topic are solely observational analysis and is subject to research that supports or refutes the opinion. I'd like to see this as a teachable moment for those who go about teachable moments in a demotivating manner.