DEV Community: Johnson Fash

The column that existed on staging and not on production

Johnson Fash — Fri, 04 Sep 2026 05:40:46 +0000

The deploy was green. Both jobs, both environments, nobody paged.

The column was on staging. It was not on production.

It had gone out in a pull request that also touched nine files of application
code, and the reviewer read the application code, because that's where the
interesting part was. The schema change was three words. The deploy step that
would have applied it never ran on production — somebody had moved that step a
year earlier, and nothing had needed it since.

Production found out at the first write, at eleven at night, and nobody could
tell me whether that invoice had saved.

Nothing about that is exotic. It's the ordinary failure mode of schema work,
and it has nothing to do with how nice your query API is. I spent months on
findMany. The thing that costs money is what happens the day you change a
column on a table that already has rows in it.

So: the unglamorous half.

`forge push` — the boring one

npx forge push
# → [forge:push] applied 1, skipped 47, failures 0

It reads your schema, introspects the live database, brings the database
forward. Run it again and it does nothing — applied 0, skipped 47.

The important property is what it refuses to do. push will not drop a column
you removed from the schema, will not drop a table, will not change a column's
type, and will not rename anything. It's additive by construction, which is
what makes it safe to wire into a container's start command and stop thinking
about. Destructive operations live somewhere you have to look at them.

`forge diff --check` — the gate

diff is the read-only sibling — introspect, compare, print, never write — so
CI can preview production with a read-only role.

npx forge diff --json          # a DriftReport for jq
npx forge diff --check         # exit 3 on drift

The exit codes matter more than they look. --check exits 3 for real drift
and 1 for "couldn't run at all": no DATABASE_URL, unreachable database,
schema didn't load. A job that fails identically on both trains everyone to
ignore it.

`forge generate` — a migration with no database in the room

forge diff apply generates by introspecting DATABASE_URL. That's right for
adopting a database somebody else created, and wrong for everyday work. CI has
no database, so nothing can verify that a schema change arrived with its
migration. Two developers generate against two local worlds, each file correct
relative to a state that stops existing at the merge. And the same schema
doesn't reliably produce the same SQL, so a reviewer can't regenerate one to
check it against the change in the same pull request.

So forge generate diffs the schema against the last committed snapshot
and connects to nothing:

npx forge generate --name add-org-slug

migrations/
  meta/_journal.json          ordering
  meta/0002_snapshot.json     the schema's shape after 0002
  0002_add-org-slug.sql

A snapshot is what introspect() would return if this schema were applied.
Once that's a file, the differ doesn't care that it didn't come from a socket.

Which unlocks the check a database-backed generator cannot perform:

npx forge generate --check

[forge:generate] 1 change(s) are in the schema but not in any migration.
  - add orgs.region

Exit 3, in a pipeline with no database in it. Commit the .sql and its
snapshot together: the SQL says what will run, the snapshot says what the
schema will then be. One without the other is half a change.

`forge migrate status` — the two states nobody reports

Everything above compares intent — your schema against a snapshot, or against
what a database reports. migrate status compares reality: the files in
migrations/ against the rows in _forge_migrations. It's the one command
that genuinely needs DATABASE_URL, because a database is the only thing that
knows what it has run.

  ✓ 0002_add-org-slug.sql       2026-08-19T16:40:55Z
  ! 0003_alice-adds-note.sql    OUT OF ORDER — sorts before
                                0004_bob-adds-tier.sql, which is already applied
  · 0005_add-index.sql          pending
  ? 0006_from-a-branch.sql      NOT IN THIS CHECKOUT   applied 2026-09-02

Applied and pending, every migration tool shows. The other two are where
production goes wrong, and no tool I know of — drizzle-kit included — reports
either.

OUT OF ORDER. Alice generates 0007 on Monday. Bob generates 0008 on
Tuesday. Bob's merges first and ships. When Alice's merges, a migrator walking
forward from the highest applied entry steps over 0007 in silence. It is
never applied at all, and nothing ever says so. You find out a fortnight later,
as "why is this column missing in staging". The fix is to delete the file and
its snapshot, pull, and regenerate — which also re-diffs it against the schema
as it now is, because 0007 was written against a world where 0008 hadn't
happened.

NOT IN THIS CHECKOUT. The database has applied a migration your folder
doesn't contain: somebody ran a branch against it. The schema in front of you
is not the schema that database has, so everything you generate from here is
built on a state you cannot see — correct against your snapshot, wrong against
that database.

npx forge migrate status --check   # exit 4

Exit 4 is distinct from generate --check's 2 and 3, so a pipeline can say
which gate refused it. Point it at staging; an empty per-PR database has
nothing to disagree about.

The two refusals

A rename is not a drop and an add

Comparing two schema states shows only that one name is gone and another has
appeared. A rename and a drop-plus-add look identical from there, and they do
opposite things to the data: one keeps every row, the other deletes a column's
worth of it.

Guessing "drop and add" loses data on a column somebody meant to keep.
Guessing "rename" is worse — it keeps a column somebody meant to delete and
quietly moves its data under a new name. So forge takes the answer from the
schema:

name: f.string().renamedFrom('full_name'),

-- up
ALTER TABLE "orgs" RENAME COLUMN "full_name" TO "name";

Without the annotation, a same-typed drop-and-add on one table is refused,
naming both columns and printing the line to add. --allow-drop is how you say
"it really is a drop, I mean to lose it" — deliberately a flag and not a
prompt, so it lands in the shell history.

drizzle-kit asks this interactively. Right question, wrong medium: a prompt
answered once at 2am is recorded nowhere, cannot run in CI, and is invisible in
review. An annotation is in the schema, the diff and the pull request.

A widening is emitted; a narrowing is refused

varchar(64) → varchar(255), int → bigint, dropping NOT NULL: every
existing row still fits, so the statement cannot fail on data. Emitted — with a
down that says out loud that reversing it can fail on rows written since. A
file that says "rollback" without saying that is lying to whoever runs it at
3am.

Everything else is refused, with the migration to write instead:

✖ orgs.name: text → int
  orgs.name changes from text to int, which is not a widening — existing
  rows may not fit, or may not convert at all.
  → forge will not guess at this. Write it with `forge generate
    --custom`: add the new column, backfill it with whatever conversion
    is correct for YOUR data, verify, then drop the old one and rename.

Exit 2, and nothing is written — including the safe changes in the same diff.
A migration that applies cleanly while leaving the schema and the database
disagreeing is the failure this exists to remove, not a smaller version of it.
NULL → NOT NULL is refused too, and the message says why the obvious fix
doesn't work: a DEFAULT applies to new rows, not to the NULLs already there.

The refusal is the feature. A tool that emits ALTER COLUMN … TYPE int
against a column holding text is more dangerous than one that emits nothing,
because the migration looks reviewed.

And before any of it, npx forge doctor — driver inventory, a redacted
DATABASE_URL check, a schema lint, and a live probe that tells you pg_trgm
isn't installed before a GIN index tells you at deploy time.

Two bugs, and one embarrassment

The empty upsert

db.user.upsert({ where, create, update: {} })

The ordinary "insert if it isn't there, otherwise leave it alone" idiom — the
first thing anyone writes for an idempotent seed. It compiled to:

INSERT INTO "users" (…) VALUES (…) ON CONFLICT ("email") DO UPDATE SET  RETURNING *

SET with nothing after it. And because a parser blames the token after an
empty clause, every dialect reported near "RETURNING": syntax error —
pointing squarely at the one part of the statement that was fine.

An empty set now emits a column assigned to its own stored value: valid SQL,
provably no change, and RETURNING still yields the row, which upsert's
contract requires. DO NOTHING would have parsed and is the shorter fix, but it
returns no row on conflict — so upsert would have resolved to undefined
exactly when the record already existed. A silent wrong answer in place of a
loud syntax error is not a fix.

The MySQL near-miss

This is the part that stayed with me.

MySQL rewrites each upsert assignment to col = VALUES(col) so the update
reuses the INSERT's values. Right for a real update. Catastrophic for the
no-op, because VALUES(`id`) is the id the INSERT proposed. On conflict
that would have silently replaced the existing row's primary key with a freshly
generated uuid, taking every foreign key that referenced it along with it.

No error. No failed statement. A row that still exists, under a new identity,
with its children pointing at nothing. On a table of invoices that isn't a bug
report, it's an incident. Caught before it shipped, by a hair.

The examples that quietly rotted

Both were found by running an example rather than reading one — which is the
embarrassing bit. The examples lived in their own repository, pinned at
^2.5.6 while the library reached 2.13.0, and three were broken. One by the
empty upsert above: a bug nothing caught for eight releases, because the
only code exercising that path sat where no CI was looking. They run against
the working tree now, on every push and pull request.

The argument

Every refusal here has the same shape. forge is handed two possibilities that
look identical from where it stands, and picks neither.

A rename and a drop-plus-add. A widening and a narrowing. An empty update
clause and one that meant to change something. In each case a differ could have
guessed, been right most of the time, and been catastrophically wrong the rest
— and the wrongness would not surface as an error. It surfaces as an empty
column, a foreign key pointing nowhere, an upsert returning undefined, a
migration nothing ever applied.

That's the real measure of a data tool. Not the query API — everyone's is fine
now, they converged on roughly the same shape and it took me a while to admit
it. The measure is what a tool does at the boundary of its own knowledge.

An error costs you a minute. A silent wrong answer costs you a quarter, and you
don't find out which quarter until the accounting doesn't add up.

Refusing to guess is a feature. It's the only one in this post that matters
solely when everything else has already gone wrong — which is exactly when
you'll care about it.

The series

Five posts, and I'm grateful to everyone who read past the first.

Part 1 — "I picked MongoDB on day one. By month eight I needed Postgres."
The day-one database decision, and one API over six databases.

Part 2 — "The afternoon my teammate lost to a stale generated client."
Inferred types instead of codegen, and $explain.

Part 3 — the browser: the same findMany in a tab, against SQLite compiled
to WebAssembly.

Part 4 — React Native, where every native module is a rebuild.

Part 5 — this one. The work that keeps a schema honest.

📖 Docs: johnsonfash.github.io/forge-orm
📦 npm: forge-orm
⭐ GitHub: johnsonfash/forge-orm

Thank you for reading the whole thing — genuinely. One last question, and it's
the one I most want answered: what's the worst thing a migration has ever done
to your data, and did you find out from an error or from a customer?

The same models, on a phone with no signal

Johnson Fash — Fri, 04 Sep 2026 05:39:56 +0000

There is a stretch of the Lagos–Ibadan expressway where the network drops
for about four minutes. Not enough to notice if you're a passenger. Plenty
if you're a Dallio user standing at the back of a customer's shop trying to
record twelve cartons of soap against an invoice.

One of the first people to use Dallio's field app was a distributor's rep
who spent his day exactly like that: shop to shop, six or seven stops,
somewhere between two bars of signal and none. The first version of that
app did the obvious thing — every action was a request. Tap "record
delivery", spinner, timeout, retry, and a rep who had learned to take a
photo of his paper ledger as a backup. Which tells you the app had already
lost.

So the local database stopped being a cache and became the database. Write
to SQLite on the phone, always, whether or not there's signal. Push to the
server when there is. That part is not a novel idea; it's the standard
shape of an offline-first app and half the mobile ecosystem is built around
it.

The problem was what it did to my models.

Three codebases describing the same invoice

By that point Dallio had a server — Node, talking to Postgres and Mongo. It
had a browser build where the whole thing ran locally in a tab (that was post 3 —
sqlite-wasm and IndexedDB). And now it had a phone.

Same invoice in all three. Three definitions of it.

The server had the real one. The web build had a copy, close enough that
you'd never spot the difference reading them side by side, subtly wrong in
one place — the discount field was nullable on the server and defaulted to
zero in the browser, which meant one report disagreed with another by a few
hundred naira and took me a full evening to find. The phone had a third,
hand-written CREATE TABLE in a string literal, because that's what you do
when your ORM won't run on React Native.

Three files. One concept. Every schema change was a three-way merge I
performed in my head.

The models are the same file

Here is what I actually wanted, and what forge does now.

// models.ts — shared. Node imports it. The browser imports it. The phone imports it.
import { f, model, rel } from 'forge-orm';

export const Customer = model('customers', {
  id:         f.id(),
  name:       f.string(),
  phone:      f.string().optional(),
  created_at: f.dateTime().default('now'),
}).relate(() => ({
  invoices: rel.many('invoice', { on: 'customer_id', refs: 'id' }),
}));

export const Invoice = model('invoices', {
  id:          f.id(),
  customer_id: f.objectId(),
  total_cents: f.int().default(0),
  status:      f.string().default('draft'),
  created_at:  f.dateTime().default('now'),
  updated_at:  f.dateTime().default('now').updatedAt(),
}).relate(() => ({
  customer: rel.one('customer', { on: 'customer_id', refs: 'id', onDelete: 'Cascade' }),
}));

export const schema = { customer: Customer, invoice: Invoice } as const;

Three ways to open it.

// server.ts — Node, Postgres
import { createDb } from 'forge-orm/postgres';
import { schema } from './models';

export const db = await createDb({ url: process.env.DATABASE_URL!, schema });

// web.ts — browser, sqlite-wasm over OPFS
import { createDb, wasmSqliteDriver } from 'forge-orm';
import { schema } from './models';

const worker = new Worker(new URL('forge-orm/wasm/worker', import.meta.url), { type: 'module' });
export const db = await createDb({
  schema,
  driver: wasmSqliteDriver({ worker, url: 'opfs-sahpool:///app.sqlite' }),
});

// mobile.ts — Expo
import * as SQLite from 'expo-sqlite';
import { createDb, expoSqliteDriver } from 'forge-orm';
import { schema } from './models';

export const db = await createDb({
  schema,
  driver: expoSqliteDriver(SQLite.openDatabaseSync('app.db')),
});
await db.$migrate();

Bare React Native, where you can prebuild, uses op-sqlite instead — it talks
JSI directly rather than crossing an async bridge per row, which shows up on
write-heavy work:

import { open as openSqlite } from '@op-engineering/op-sqlite';
import { createDb, opSqliteDriver } from 'forge-orm';
import { schema } from './models';

const native = openSqlite({ name: 'app.sqlite' });
export const db = await createDb({ schema, driver: opSqliteDriver(native) });
await db.$migrate();

db.invoice.findMany({ where: { status: 'draft' }, include: { customer: true } })
is the same call in all four files. Not a similar call. The same one, against
the same models, fully typed, with nothing generated.

A warning: never import `forge-orm/sqlite` on React Native

This one deserves a box, because I watched someone hit it and lose an hour.

forge has per-dialect entry points — forge-orm/postgres, forge-orm/mysql,
forge-orm/sqlite and so on. They exist so a bundler can see the driver:
inside forge-orm/postgres, pg is brought in with a static import, which
webpack and esbuild understand in a way they never understand a computed
require.

forge-orm/sqlite is the better-sqlite3 one. better-sqlite3 is a native
Node addon. It cannot exist on React Native — not "is slow there", not
"needs configuration": there is no build of it that runs. Import it from an
Expo or RN app and Metro fails on a module that has no business being in the
graph.

The entry point isn't wrong. It's a server entry point that happens to
share a dialect name with the thing you want. On a phone you use the main
forge-orm entry and pass driver: — and because you write the
import * as SQLite from 'expo-sqlite' line yourself, it's static, and Metro
resolves it like any other import. The pluggable driver is the bundler-safe
path here, not the escape hatch.

One dialect, several packages

This is the part I find genuinely interesting, and it took me a while to see
it clearly.

Fifteen driver packages sit behind forge's six dialects. SQLite alone
accounts for six of them: better-sqlite3 on a server, expo-sqlite and
OP-SQLite on React Native, @libsql/client for libSQL and Turso,
@sqlite.org/sqlite-wasm in a browser tab, @tauri-apps/plugin-sql on
desktop. Postgres has three, MySQL three, and MongoDB, DuckDB and SQL Server
one each.

Six packages, one adapter. Every one of those SQLite clients runs the same
forge sqlite adapter — same IR compiler, same DDL emitter, same
introspection reader — and emits identical SQL. The adapter has no idea
which of them is underneath. It hands down a SQL string and an array of
params and gets rows back; that is the entire contract, five methods wide.

Which is why no two of them can share an entry point. Each would drag in a
package the others cannot load. A single forge-orm/sqlite importing all
six would put a WebAssembly SQLite and a native Node addon into your Metro
bundle together, and neither belongs there.

Adapters are stable. Engines aren't. Keeping them apart is the reason the
phone got the real models instead of a hand-written CREATE TABLE.

`$migrate()`, because there's no CLI on a phone

forge push is a Node CLI. You cannot shell out to Node from an iPhone, so
forge ships the same emitter and applier as a runtime call:

const report = await db.$migrate();
// { applied, skipped, failures, alteredColumns, pending }

It reads the schema you passed to createDb, emits the same DDL forge push
would, skips tables and indexes that already exist, then introspects the live
database and adds any missing column that can be added safely — nullable, or
with a constant default. Destructive drift (column drops, type changes) is
left alone and reported under pending.

It's idempotent, so calling it on every app boot is the intended usage. On
mobile that matters more than it does on a server, because over-the-air
updates ship a JS bundle whose schema can run ahead of what the installed
build's database knows about. db.$diff() gives you the report without the
apply, which makes a decent release-branch test.

One Metro-specific wrinkle: fast refresh re-runs your module, so memoise the
handle at module scope rather than opening a connection on every save.

The honest limits

Expo managed gets stock SQLite. FTS5 is there from SDK 51, but there's no SQLCipher and no extensions — you prebuild and move to op-sqlite for those. The forge schema, models and queries don't change when you do.
Geo needs fallback mode. No mobile build ships SpatiaLite, so f.geoPoint({ fallback: true }) stores {lng, lat} as JSON and the adapter post-filters with Haversine. Correct, and slower — fine to roughly 50k rows.
f.vector(N) needs a custom build that links sqlite-vec. Stock op-sqlite and expo-sqlite don't have it.
Size. forge itself is around 80 KB minified with no driver. The drivers carry the weight: expo-sqlite is roughly 150 KB of JS plus about 1.2 MB of native per arch, op-sqlite roughly 600 KB plus 3–4 MB per arch. ABI splits keep the per-APK number down.
Sync is yours. forge is local-first and ships none. MOBILE.md documents three patterns — pull-on-foreground, an outbox table replayed with backoff, CRDT blobs — and the outbox is a plain forge model, not a special API. Which is the point: the local SQLite is the app's database, and sync is a separate program that happens to read and write it.

The rep on the expressway doesn't know any of this. He taps, it saves, the
number is right when he gets back into signal. That was the whole
requirement.

Next in this series: the CLI — forge push, forge diff, migration
snapshots, and the bugs that shipped before I got drift detection right.

📖 Docs: johnsonfash.github.io/forge-orm
📦 npm: forge-orm
⭐ GitHub: johnsonfash/forge-orm

If you've shipped an offline-first mobile app, how did you keep the phone's
schema and the server's schema from drifting apart? I've yet to hear two
people answer that the same way.

The network died mid-sale. The customer still had cash in her hand.

Johnson Fash — Fri, 04 Sep 2026 05:38:37 +0000

There is a shop on the ground floor of a plaza off Lagos Island. Fabric,
mostly. Two staff. One counter. The internet is a phone on top of the till,
tethered, propped against a bottle of water because that's the corner of the
room where it holds a signal.

I was standing in that shop when the connection dropped.

The cashier had scanned three items. She tapped Save. The button went
into that state buttons go into — greyed, a small spinner, the polite lie
that something is happening. The customer was holding four thousand naira,
counted out, waiting. Ten seconds. Twenty. Behind her, two more people.

The cashier did what anyone would do. She wrote it in a notebook, took the
cash, and told me she'd "enter it later." Which she did — sometimes.

That's the bug. Not the spinner. The notebook.

Every sale that lands in a notebook is a sale that will not match the
inventory count on Friday. Dallio's whole promise to a retailer is your
numbers are right, and a dropped connection was quietly turning that into
your numbers are right when NTEL is having a good day.

What you normally do about this

You cache. Of course you cache.

The first version is localStorage and a JSON blob. It works for about a
week, until you need to find "unsynced sales for this branch since Monday"
and discover you're writing Array.prototype.filter over a parsed string.

The second version is a hand-rolled IndexedDB wrapper. Now you have stores,
and keys, and a promise shim, and you've reinvented about 15% of a query
engine, badly, in a file nobody wants to open.

The third version is the honest one: a second data layer. Local models that
shadow your server models. A second set of types. A second implementation of
soft delete, of tenant scoping, of "don't show voided sales." Every bug fixed
on the server has to be fixed again, slightly differently, in the tab.

I'd already lived that in post 1 — Mongo for operations, Postgres for
reporting, two of everything. I was not doing it a third time in JavaScript.

The version I wanted

The same models. The same findMany. A different driver.

const sales = await db.sale.findMany({
  where:   { locationId, postedAt: { gte: startOfDay } },
  orderBy: { postedAt: 'desc' },
});

That line should not know or care whether it's talking to Postgres over TCP
or to a database living inside the tab. forge ships no driver of its own —
every backend is an optional peer dependency, which sounded like packaging
trivia when I wrote post 1 and turned out to be the reason any of this is
possible.

There are two browser tiers. They read the same schema and take the same
calls.

Tier one: IndexedDB, nothing to install

Every browser since roughly 2017 has IndexedDB built in. No wasm blob to
download and host, no Web Worker, no bundler plugin, no COOP/COEP headers to
argue with your CDN about.

import { createDb, f, model } from 'forge-orm';
// Side-effect import registers the IndexedDB adapter with the factory.
import 'forge-orm/indexeddb';

const Sale = model('sales', {
  id:         f.id({ type: 'uuid' }),
  locationId: f.string(),
  total:      f.int(),
  postedAt:   f.dateTime().default('now'),
});

export const schema = { sale: Sale };

const db = await createDb({ schema, url: 'idb:dallio' });
await db.$migrate();

The idb: prefix (or the alias indexeddb:) picks the adapter, and the
string after the colon is the IndexedDB database name — the same thing you'd
hand to indexedDB.open(name) yourself. If you'd rather not thread a URL,
indexedDbDriver({ name: 'dallio' }) from forge-orm/indexeddb gets you the
same adapter and lets you hand in a database you opened in your own bootstrap
code.

That's the whole setup. Installed size of the database layer: zero bytes over
what you already shipped.

`$migrate()`, because there is no CLI in a browser tab

forge push is a Node CLI. You cannot shell out to Node from a tab, so the
same DDL emitter is exposed as a runtime call.

await db.$migrate();

Call it at app boot. It's idempotent — existing stores and indexes are
skipped, and on the SQLite tier, columns added since the last boot get
patched in with ALTER TABLE … ADD COLUMN where that's safe. Anything
destructive (a dropped column, a type change) is left alone and reported
under report.pending for you to decide about, rather than silently eating
someone's sales history.

On IndexedDB it maps onto the platform's own onupgradeneeded versioning,
and rather well: adding a field is a no-op because IDB is schemaless, and
adding an index back-populates existing rows for free. The engine
fingerprints the DDL plan and only bumps the IDB version when the fingerprint
changes, so $migrate() on an unchanged schema is a boot-time metadata check
and nothing more.

The offline-first shape

Local write first, sync second. Never the other way round.

const sale = await db.sale.create({ data: { locationId, total } });

await db.outbox.create({
  data: { saleId: sale.id, op: 'create', payload: { total: sale.total } },
});

The outbox is an ordinary model in the same schema — id, target id, op, a
f.json() payload, queuedAt, tries. A drain loop empties it when the
connection comes back:

setInterval(async () => {
  if (!navigator.onLine) return;
  const pending = await db.outbox.findMany({
    orderBy: { queuedAt: 'asc' },
    take: 10,
  });
  for (const op of pending) {
    await pushToServer(op);
    await db.outbox.delete({ where: { id: op.id } });
  }
}, 5000);

The cashier's Save button now returns in a millisecond and is honest
about it. The queue depth goes in the corner of the screen — 3 pending —
because a shop owner would rather see a number than trust a spinner.

That pattern is examples/02-sqlite-browser-offline-first, and it is the
shape Dallio's POS uses.

Tier two: real SQLite, over OPFS

IndexedDB stops being enough at a fairly specific moment: when you want the
browser to answer a question rather than hand you rows.

The end-of-day report joins sales to line items to products, groups by
category, and sums. On the SQLite tier that's SQL — the same C engine that
runs on a server, compiled to WebAssembly, in a Web Worker, persisted on the
Origin Private File System.

import { createDb, f, model, wasmSqliteDriver } from 'forge-orm';

const worker = new Worker(
  new URL('forge-orm/wasm/worker', import.meta.url),
  { type: 'module' },
);

const db = await createDb({
  schema,
  driver: wasmSqliteDriver({ worker, url: 'opfs-sahpool:///dallio.sqlite' }),
});
await db.$migrate();

Three URL schemes: opfs-sahpool:///file.sqlite is the default and the one
to pick — its VFS coordinates access handles across tabs, so a user with your
app open twice doesn't get a surprise. opfs:///file.sqlite is slightly
faster and single-writer; a second tab opening the same file throws
SQLITE_BUSY. :memory: is for tests and demos, and dies with the tab.

The worker is required, not stylistic — OPFS synchronous access handles only
exist inside a Worker. Bundler wiring is one import: forgeWasm() from
forge-orm/wasm/vite, withForgeWasm() from forge-orm/wasm/next, or
forgeWasmWebpack(config) from forge-orm/wasm/webpack. Parcel needs
nothing.

Pick sqlite-wasm when you need real joins, groupBy/having, FTS5 with
BM25 ranking, or more data than a cursor scan enjoys. IndexedDB is enough
when your browser workload is a working set — today's sales, this branch's
stock list, an outbox — that you filter and sort and page, and the serious
reporting happens on a server.

Cost of the second tier: about 1 MB of wasm, a worker file, and COOP/COEP
headers to get right. Code-split it so your landing page doesn't pay.

The limits, stated plainly

IndexedDB has no SQL. forge compiles your query to an IR, the planner picks
one index, scans a cursor over it, and applies the rest as a compiled JS
predicate. That's honest and it's fast enough at the sizes browsers actually
hold — the docs put the comfortable ceiling around 100k rows — but it is not
a query optimiser.

Specifics worth knowing before you commit:

AND at the root of a where unlocks index selection. OR and NOT at the root fall back to a full-table scan plus the residual predicate.
Relations work, but there is no join. The executor does the lookups.
JSON path queries ({ meta: { path: 'address.city', equals: 'Lagos' } }) get no index acceleration at all. If a path goes hot, promote it to a real field with its own index.
Vector search is brute-force cosine/L2 in JS — fine to roughly 1k vectors, slow past that. Geo is a bbox prefilter plus Haversine. On stock sqlite-wasm those two are also fallbacks; native R-Tree and sqlite-vec need a custom wasm build.
Full-text is a multiEntry token index and an AND of tokens. No stemming, no stopwords, no ranking.
IDB transactions auto-commit the moment the microtask queue idles. That is a platform rule, not a forge choice. $transaction(fn) gives you best-effort atomicity and rollback on throw, but not strict serialisability — a fetch between two writes will let the first commit alone. For genuine atomicity use the array form, $transaction([a, b]), which maps to one readwrite transaction.

And the one that catches everybody: Safari deletes it. Since 2020, ITP
clears IndexedDB, OPFS and LocalStorage for any site the user hasn't visited
in 7 days. Same rule for both tiers. The mitigation is the same for both too:

if (navigator.storage?.persist) await navigator.storage.persist();

Persistence is granted automatically to installed PWAs and after enough
engagement elsewhere; the first call often returns false, so retry on later
visits. For data the user can't get back, tell them to add the app to their
home screen and mean it.

Did it fix the shop?

The spinner is gone. Sales write to the tab in a millisecond, the outbox
drains when the phone finds a signal, and the notebook has stopped being part
of the accounting system.

The part I keep being pleased about is what didn't happen: no second set of
models, no shadow query layer, no local-only bugs. db.sale.findMany in the
browser is the same call, against the same model, as db.sale.findMany on
the server.

Next in this series: the same models on a phone. React Native and Expo,
where there is no OPFS, no IndexedDB, and a different driver again.

📖 Docs: johnsonfash.github.io/forge-orm
📦 npm: forge-orm
⭐ GitHub: johnsonfash/forge-orm

What's the worst connection your app has ever had to survive? I'd like to
know whether Lagos is unusual or whether everyone's been quietly building
notebooks.

The afternoon my teammate lost to a stale generated client

Johnson Fash — Fri, 04 Sep 2026 05:37:45 +0000

Someone on my team once spent most of a Thursday convinced I had broken the
build.

He'd pulled a branch where I'd renamed a column. Nothing exotic: phone
became phoneNumber, one line in the schema file, one migration. He pulled,
ran the app, and started wiring up the settings form. Autocomplete offered him
phone. He used phone. TypeScript was happy. The editor was happy. At
runtime the field came back undefined, every time, on a column that was
sitting right there in the database with data in it.

He checked the migration. He checked the connection string. He checked whether
he was pointed at the wrong branch's database. Around five o'clock he asked me
to look, and I said the sentence you say roughly once a fortnight on a Prisma
codebase: did you run prisma generate?

His generated client was three commits old. It had been describing a database
that no longer existed, confidently, in green squiggle-free TypeScript, for
about four hours.

That is not a Prisma bug. It is the shape of the thing.

Why the codegen step exists

I want to be fair here, because prisma generate is not a mistake and it is
not laziness. It solves a real problem.

Prisma's schema lives in schema.prisma, its own DSL file. TypeScript cannot
read that file. The compiler has no idea it exists. So something has to stand
between the two and turn one into the other, and that something is a
generator that writes a concrete .d.ts describing your models. Once written,
those types are ordinary declared types. The compiler reads them the way it
reads any other declaration file, which is fast, predictable, and scales to
schemas with three hundred models without your editor going quiet for four
seconds every time you type a dot.

There's a second thing codegen buys. Because the client is generated per
project, Prisma can bake in exactly the operations your schema supports and
nothing else, and it can ship a query engine binary alongside it. That engine
is where a lot of Prisma's correctness and speed lives.

Both of those are genuine wins. I don't think the people who built it were
wrong.

I do think the bill is higher than it looks.

The bill

You regenerate after every schema change, and after every pull that contains
someone else's schema change, and after npm ci wipes node_modules. Miss one
and you don't get an error, you get four hours of a colleague's Thursday.

You then choose between two unattractive options for source control. Gitignore
the generated client, and every fresh checkout is broken until a postinstall
hook fixes it. Commit it, and every schema change lands as a pull request with
one meaningful line and forty thousand generated ones, which nobody reviews,
which is exactly where the merge conflicts live.

Then there's the engine binary. It's platform-specific. I've had a deploy fail
because the image built on one libc and ran on another, and the error you get
at the far end of that is not "wrong binary target", it's a stack trace from
inside a Rust process at container start. It's fixable. It's documented. It's
still twenty minutes of your life at a bad moment.

And the part that ended it for me: none of this follows you into a browser tab
or a React Native bundle. A native binary and a generation step don't cross
that boundary. I'll come back to why I cared so much about that.

The other route

The alternative is not clever. It's the one TypeScript has been offering all
along: don't describe your schema in a foreign language, describe it in
TypeScript, and let inference do the work.

In forge, f.string() builds a plain object. So does f.int().optional().
model() collects them into an object and hands back a TypedModel carrying
the field map as a phantom type property, one that exists for the compiler and
not at runtime. createDb captures that map through a generic. Every call site
resolves against it.

import { createDb, f, model } from 'forge-orm';

const User = model('users', {
  id:        f.id(),
  email:     f.string().unique(),
  name:      f.string().optional(),
  age:       f.int().optional(),
  createdAt: f.dateTime().default('now'),
});

const schema = { user: User } as const;
const db = await createDb({ url: process.env.DATABASE_URL!, schema });

const adults = await db.user.findMany({ where: { age: { gte: 18 } } });
//    ^ { id: string; email: string; name: string | null; age: number | null; createdAt: Date }[]

Rename age to ageYears in that model and the where clause goes red
before you've finished typing the s. Not on the next build. Not after a
command you have to remember. There is no generated artefact that can be older
than your schema, because there is no generated artefact.

The shapes are exported as type helpers, so you can use them at service
boundaries rather than hand-writing DTOs:

import type { Row, Infer, InferCreate, InferWhere, InferSchema } from 'forge-orm';

type UserRow    = Row<typeof User>;
//   { id: string; email: string; name: string | null; age: number | null; createdAt: Date }
type UserCreate = InferCreate<typeof User>;
//   every scalar optional — defaults are filled at runtime
type UserWhere  = InferWhere<typeof User>;

// Or the whole bundle for one model:
type UserT = Infer<typeof User>;
UserT['Row']; UserT['Create']; UserT['Update']; UserT['Where']; UserT['Include'];

// Or every model at once — the right shape to export from a shared types.ts:
type Types = InferSchema<typeof schema>;
type UserSelect = Types['user']['Select'];

InferRow, InferUpdate, InferUpsert, InferOrderBy, InferSelect,
InferInclude and InferOmit are all there too. None of them require you to
register anything or call a build command. One gotcha worth knowing: the schema
map needs as const, or keyof typeof schema widens to string and the
relation walk quietly falls back to a loose shape.

What this costs, honestly

Inference is not free, and I'd rather say so than have you find out on a large
schema.

Prisma's generated types are concrete. The compiler reads them once and moves
on. forge's are computed: where is a mapped type walking your field map,
the return type is a conditional type that looks at the literal type of the
arguments you passed and resolves the row, the projection, or the relation
tree. On a small or medium schema you will not notice. On a very large one,
with deep include chains, type-checking has more work to do than reading a
declaration file does, and that shows up in editor responsiveness and cold
tsc runs. I have not benchmarked the crossover point and I'm not going to
invent one, but the direction is real and it favours codegen at the top end.
The relation walk is capped at ten levels for exactly this reason; past that
nested args type loosely rather than exploding.

There's a second gap. To support composite-unique keys and raw Mongo
operators, where carries a string index signature at the bottom, which means
where: { nonexistent_field: 'x' } compiles and then matches nothing.
createDb({ schema, strict: true }) catches it at runtime with the valid keys
listed. Turn it on in development.

That's the trade. Live types with nothing to regenerate, against slower
type-checking at the large end and one loose escape hatch.

"But then how do I know what SQL runs?"

This is the fair objection to dropping the generated client, and it's the one
I care most about answering. With Prisma you can at least go and read the
thing. So forge has db.$explain(), which takes a call site and gives you the
statement without executing it:

const r = await db.$explain((q) => q.user.findMany({ where: { age: { gt: 40 } } }));
console.log(r.toString());

user.findMany  →  users  [sqlite]

  SELECT "users"."id", "users"."name", "users"."age" FROM "users" WHERE "users"."age" > ?

  params: 40

  -- with values inlined (for reading, not for running):
  SELECT "users"."id", "users"."name", "users"."age" FROM "users" WHERE "users"."age" > 40

The q handed to the callback holds no session and reaches no driver, so
nothing can execute even by accident. You get artifact.sql and
artifact.params as the pair you'd actually run, plus a readable version
with values substituted for pasting into psql. Don't execute that one; the
quoting there serves legibility, not safety.

Pass { analyze: true } and it asks the database for its own plan:

const r = await db.$explain((q) => q.user.findMany({ where: { name: 'u7' } }), {
  analyze: true,
});

  -- plan:
  SCAN users

SCAN means every row read. name has no index. Add one and the same query
comes back as SEARCH users USING INDEX users_name (name=?). That's a
property of the query rather than of the schema, which is why a schema linter
can't see it.

One deliberate omission: forge never emits EXPLAIN ANALYZE. EXPLAIN plans
a statement; EXPLAIN ANALYZE runs it. On a SELECT that difference is
accuracy. On deleteMany it's your data, and an API whose entire promise is
"this does not run" must not delete rows because you asked for more detail. If
you want real timings, run the statement yourself through $queryRaw, on
something you meant to execute.

Next in this series: the reason none of this has a build step or a binary
in the first place. The same query code, the same models, running in a browser
tab against SQLite compiled to WebAssembly.

📖 Docs: johnsonfash.github.io/forge-orm
📦 npm: forge-orm
⭐ GitHub: johnsonfash/forge-orm

What's the longest you've spent debugging something that turned out to be a
stale generated artefact? I'd like to know I'm not alone in this.

I picked MongoDB on day one. By month eight I needed Postgres.

Johnson Fash — Fri, 04 Sep 2026 05:36:34 +0000

The decision took about nine minutes.

It was the start of a new product — VirtualRx, a business-management app for
small retailers in Lagos. Point of sale, inventory, invoices, the lot. I
needed a database, I had a schema roughly in my head, and MongoDB let me
start writing code that afternoon instead of arguing with migrations. Nine
minutes. createdb, connection string, first model, move on.

That decision was fine for about eight months.

Then a client asked a question I couldn't answer: "Which of my three
branches actually makes money on Tuesdays?"

It's not an exotic question. It's a GROUP BY with a couple of joins and a
window function. On Postgres it's ten lines. On Mongo it was an aggregation
pipeline I rewrote four times, got working, and then couldn't read a week
later. I remember staring at a $lookup inside a $facet and thinking:
I chose this in nine minutes, and now I'm stuck with it.

The obvious move was to add Postgres for reporting. Keep Mongo for the
operational stuff, pipe the analytics somewhere that likes analytics. Sensible.
Boring. Standard.

Except that meant two data layers. Two sets of models. Two mental models. And
every helper I'd written — soft delete, tenant scoping, audit logging — needed
a second implementation that behaved almost the same.

What I actually wanted

I wanted to write this:

const rows = await db.sale.findMany({
  where: { locationId, postedAt: { gte: start } },
  include: { customer: true },
});

…and have it not care which database was underneath.

Not "abstract away SQL." Not "one query language to rule them all." Just:
the ordinary 90% of queries should be portable, and the other 10% should
drop to raw SQL without ceremony.

I looked at what existed.

Prisma has the API shape I wanted. But it's a code generation step. Every
schema change means prisma generate, a regenerated client committed or
gitignored, a Rust query engine binary in your deploy, and a real fight to run
in a browser or on React Native. I've watched a teammate lose an afternoon to a
stale generated client that looked fine.

Drizzle is excellent and I nearly used it. But it's SQL-shaped by design —
which is the right call for a SQL-only tool, and the wrong one when one of my
six targets is MongoDB.

TypeORM and friends: decorators, metadata, a lot of machinery.

None of them ran in a browser tab. That mattered more than I expected, and I'll
come back to it in a later post.

So I did the thing you're not supposed to do. I wrote my own.

forge-orm

It's a small, Prisma-shaped data layer for MongoDB, PostgreSQL, MySQL,
SQLite, DuckDB and SQL Server. You write models once in plain TypeScript and
the same query code runs against any of them.

npm install forge-orm
npm install pg          # only the driver you actually use

import { createDb, f, model } from 'forge-orm';

const User = model('users', {
  id:    f.id(),
  email: f.string().unique(),
  name:  f.string(),
  age:   f.int().optional(),
});

const db = await createDb({
  url: process.env.DATABASE_URL!,   // postgres:// … | mongodb:// … | sqlite: …
  schema: { user: User },
});

const adults = await db.user.findMany({
  where:   { age: { gte: 18 } },
  orderBy: { name: 'asc' },
  take:    20,
});

adults is fully typed. There was no build step. There is no generated client
in your repo. Change the model, and the types change on the next keystroke —
because they're inferred from the object you just wrote, not produced by a
tool you have to remember to run.

Point DATABASE_URL at Mongo instead and that same findMany runs as a Mongo
find. Point it at SQLite and it's a SELECT. The query code doesn't move.

The part I didn't expect to matter

forge ships no database driver of its own. Each one is an optional peer
dependency, so npm install forge-orm pulls nothing extra, and importing forge
needs no driver at all.

Database	URL starts with	Install
PostgreSQL	`postgres://`	`npm install pg`
MySQL / MariaDB	`mysql://`	`npm install mysql2`
SQLite	`sqlite:` or `file:`	`npm install better-sqlite3`
MongoDB	`mongodb://`	`npm install mongodb`
DuckDB	`duckdb:`	`npm install @duckdb/node-api`
SQL Server	`mssql:`	`npm install mssql`

That sounds like packaging trivia. It turned out to be the thing that let forge
run in places an ORM normally can't — a browser tab, an Expo app, an embedded
Postgres compiled to WebAssembly. Those posts are coming.

What it is not

I want to be straight about this, because I've been burned by READMEs that
weren't.

forge is not a replacement for Prisma or Drizzle in maturity. It has fewer
features, a much smaller ecosystem, and no GUI. Prisma's migration tooling is
more battle-tested than mine. Drizzle's SQL surface is broader. If you need
either of those things, use them — genuinely.

What forge gives you is a small dependency you can read in an afternoon, one
query API across six databases, full autocomplete with nothing to regenerate,
and the ability to drop to raw SQL whenever the abstraction stops helping:

const rows = await db.$queryRaw`
  SELECT location_id, SUM(total) AS revenue
  FROM sales WHERE posted_at >= ${start}
  GROUP BY location_id
`;

That escape hatch is not an admission of failure. It's the point. An ORM that
tries to own every query eventually owns the ones it's bad at.

Did it actually solve the problem?

VirtualRx still runs on MongoDB. The analytics moved to a Postgres read model.
Both go through the same db.<model>.findMany calls, the same models, the same
soft-delete and tenant-scoping helpers. The report that started all this is
about fifteen lines now.

And the nine-minute decision stopped being permanent, which is really all I
wanted.

Next in this series: the codegen step — why prisma generate exists, what
it's actually solving, and how you get the same autocomplete without it.

📖 Docs: johnsonfash.github.io/forge-orm
📦 npm: forge-orm
⭐ GitHub: johnsonfash/forge-orm

If you've been stuck with a day-one database decision, I'd genuinely like to
hear what it was. That's half of why I wrote this.

Prisma can now work in your browser, expo/react-native apps? — meet forge-orm

Johnson Fash — Mon, 06 Jul 2026 09:16:02 +0000

I love Prisma. I have shipped Prisma to production more times than I care to count. It changed how a lot of us write TypeScript against databases.

But here's the thing nobody tells you about Prisma:

It doesn't run in the browser.
It doesn't run on Cloudflare Workers unless you buy the accelerator.
It runs on iOS through a weird JSI bridge I can never remember how to configure.
On Expo you eventually give up and use expo-sqlite raw.
On DuckDB? MSSQL? IndexedDB? MongoDB? Enjoy either a codegen dance or "unsupported."

So awhile ago I did a very dumb thing. I opened an editor and wrote:

import { createDb, f, model, tauriSqlDriver } from "forge-orm"

Then I spent couple of months making that import actually work. On Postgres. On MySQL. On SQLite. On MongoDB. On DuckDB. On MSSQL. On IndexedDB. On sqlite-wasm inside a browser tab with OPFS. On Tauri. On React Native.

Same easy query API on all of them. Prisma-shape. No codegen. Type-safe end to end.

Let me show you what it does.

Pick any environment. Here's Node.js + SQLite:

import { createDb, f, model } from "forge-orm"

const User = model("users", {
  id:    f.id(),
  email: f.string().unique(),
  name:  f.string(),
})

const db = await createDb({
  schema: { user: User },
  url:    "sqlite:./app.db",
})

await db.$migrate()

await db.user.create({ data: { email: "ada@x.com", name: "Ada" } })
const found = await db.user.findMany({
  where:   { email: { endsWith: "@x.com" } },
  orderBy: { name: "asc" },
  take:    10,
})

Now, this is where it gets fun. Take that exact same code, and switch two lines:

import "forge-orm/indexeddb"                       // ← switch adapter
const db = await createDb({
  schema: { user: User },
  url:    "idb:app",                               // ← switch URL
})

Everything else? Same. db.user.create(). db.user.findMany(). Same query shape. Same TypeScript inference. Same schema definition.

It's now running in a Chrome tab, storing to IndexedDB, and you didn't write a single line of indexedDB.open().

But what if I want real SQL in the browser?

It got you.

import { createDb, wasmSqliteDriver } from "forge-orm"

const worker = new Worker(
  new URL("forge-orm/wasm/worker", import.meta.url),
  { type: "module" }
)

const db = await createDb({
  schema: { user: User },
  driver: wasmSqliteDriver({
    worker,
    url: "opfs-sahpool:///app.sqlite",             // real SQLite file in OPFS
  }),
})

sqlite-wasm running in a Web Worker, writing to a persistent OPFS file, exposing the same Prisma-shape query surface. No, I did not have a fun weekend making that work.

But my POS runs on Tauri!

I know. My POS runs on Tauri too. That's kind of why forge-orm exists.

import Database from "@tauri-apps/plugin-sql"
import { createDb, tauriSqlDriver } from "forge-orm"

const sqlite = await Database.load("sqlite:app.db")
const db = await createDb({
  schema: { user: User },
  driver: tauriSqlDriver(sqlite),
})
await db.$migrate()

Native SQLite through Tauri's sqlx bridge. Same query API. Wave your hand at your platform.

But my Cloudflare Worker only has D1!

Also handled — libsql driver works over Turso + Neon's HTTP flavour, and D1 support is on the near roadmap. There's also pgDriver, postgresJsDriver, mysql2Driver, mariadbDriver, planetscaleDriver, mongoDriver, duckdbDriver, mssqlDriver, expoSqliteDriver, opSqliteDriver. Ten adapters. One API.

Wait — you said no codegen?

Right, this is the part where Prisma users get suspicious. "No codegen means no types, right?"

No. It means no prisma generate, no .prisma files, no build step. Types come from the schema you defined in TypeScript directly:


const Order = model("orders", {
  id:     f.id(),
  amount: f.int(),
  status: f.enum(["pending", "paid", "refunded"]),
  tags:   f.stringArray(),
  loc:    f.geoPoint(),        // yes, geo
  emb:    f.vector(1536),      // yes, vectors
  meta:   f.json<{ notes: string }>(),
})

const schema = { order: Order }
const db = await createDb({ schema, url: "postgres://..." })

// db.order is fully typed from the schema you wrote 3 lines up
const paid = await db.order.findMany({
  where: {
    status:  "paid",          // ← "pending" | "paid" | "refunded" enum-narrowed
    amount:  { gte: 100 },
    loc:     { near: { lng: 3.3, lat: 6.5, withinMeters: 5000 } },
  },
  orderBy: { amount: "desc" },
  take:    20,
})
paid[0].meta.notes            // typed as string, from the f.json<{ notes: string }>()

You didn't run a build step. You didn't wait for a codegen to finish. The types just are. TypeScript infers everything from f.string() / f.int() / f.enum([...]).

I actually really enjoy watching new users try to break this. "But what about relations?" Yeah, those too. f.relation.one() / f.relation.many(). "But what about transactions?" db.$transaction(async tx => ...). "But what about raw SQL?" db.$queryRawSELECT ... — typed.

Real vector + geo queries, in the same API

This is the bit I'm proudest of. You know how Prisma has like six extensions to do vector search? forge-orm just:

const near = await db.docs.findMany({
  orderBy: { emb: { direction: "asc", nearTo: queryEmbedding } },
  take:    10,
})
near[0]._distance        // typed number

And geo:

const nearby = await db.cafe.findMany({
  where:   { location: { near: { lng, lat, withinMeters: 500 } } },
  orderBy: { location: { direction: "asc", nearTo: { lng, lat } } },
})
nearby[0]._distanceMeters

Same syntax on Postgres (with PostGIS), on DuckDB (with spatial), on SQLite (with SpatiaLite), on MongoDB (with $near), and on the browser IDB adapter with pure-JS ray-casting. Six backends, one API.

OK, sell me on the CLI

npx forge doctor — hits your DB, checks every model, tells you what's missing:

✔ Postgres 16.2 · schema "public"
✔ Model "user" — table users OK
⚠ Model "order" — field status DB has TEXT, schema wants ENUM
✔ 24 indexes match
✖ Extension pgvector — NOT installed (required by orders.emb)
Run: CREATE EXTENSION vector;

npx forge push — applies drift. Non-destructive by default, --force-destructive for the scary ones.

npx forge diff — dry-run of push. Shows exactly what SQL will run.

npx forge rollback — undoes the last push.

For browser + Tauri, none of that matters — you call await db.$migrate() at boot and it does the same thing at runtime.

The real-world proof: Dallio

I'm not shipping a library and hoping someone tries it. I'm running this in production on my own product.

Dallio is a POS/inventory SaaS for African SMBs. It has:

A backend on Node + hyper-express hitting MongoDB with forge-orm/mongo
A React frontend that persists an offline event log in forge-orm/indexeddb on web tabs
A Tauri desktop + mobile shell using forge-orm + tauriSqlDriver over @tauri-apps/plugin-sql
Same SyncEvent model definition across all three. Same query API. One schema file to change.

When a shopkeeper's phone loses internet mid-checkout, the sale writes to the local IndexedDB via forge-orm. When Wi-Fi comes back, the desktop till's forge-orm-backed SQLite catches up via a WebSocket. The backend's Mongo catches the same event.

No adapter code. No translation layer. No two-database-schema sync bug. Prisma cannot do this. Drizzle cannot do this. TypeORM… let's not talk about TypeORM.

Yes, I know what you're thinking

"Isn't this just another abstraction leak waiting to happen?" Every adapter has its own capability doctor — if you write a query the backend can't support (say, orderBy: nearTo on a Postgres without PostGIS), the doctor tells you at boot, not at 2am when a customer's till breaks.

"Why should I trust this over Drizzle?" Drizzle is excellent. It's my second-favourite ORM after mine. Drizzle's schema-first + SQL-close model is beautiful. forge-orm targets a different point on the trade-off curve: I traded some of Drizzle's raw-SQL flexibility for Prisma's ergonomics + Drizzle's edge-friendliness + genuine cross-database portability. Pick the shape that fits your team.

Getting started

npm install forge-orm
Then 20 lines and you're querying:

import { createDb, f, model } from "forge-orm"

const Todo = model("todos", {
  id:    f.id(),
  title: f.string(),
  done:  f.boolean().default(false),
})

const db = await createDb({
  schema: { todo: Todo },
  url:    "sqlite:./todos.db",
})
await db.$migrate()

const t = await db.todo.create({ data: { title: "Try forge-orm" } })
await db.todo.update({ where: { id: t.id }, data: { done: true } })
console.log(await db.todo.findMany({ where: { done: true } }))

You now have a working ORM. Change one line to point it at IndexedDB, or Postgres, or Tauri SQLite. Nothing else in your code moves.

Links

npm: npm install forge-orm — https://npmjs.com/package/forge-orm
GitHub: https://github.com/johnsonfash/forge-orm (stars appreciated 🙏)
Full docs: 60+ deep-dive chapters covering every adapter, geo, vector, JSON path, FTS, migrations, transactions
472 tests — I don't ship regressions

If you ship a side project on forge-orm, I want to see it. Tag me: @iamJohnFash. Especially if you've got it running somewhere weird (Deno? Bun? A Raspberry Pi POS?). I collect these.

One query language for SQL, Mongo, and the browser: the case for Forge

Johnson Fash — Sun, 28 Jun 2026 16:28:35 +0000

There's a moment in most TypeScript backend projects when the data layer stops being one thing.

Maybe you started on Postgres, then a feature shipped where audit events made more sense as a flat Mongo document. Maybe your mobile app needs to work on the train, so you added SQLite in the browser. Maybe a "find me the three nearest locations" endpoint forced you to drop into raw ST_Distance_Sphere() because your ORM didn't know what a geo point was. Maybe you added embeddings for an AI search box and now half your query path is a $queryRaw with a hand-rolled vector cosine clause.

Each of those moments seems small in isolation. Stacked, they're how a typed data layer becomes four data layers — a Prisma client over here, a Mongoose schema over there, Dexie wrapping IndexedDB, and a folder full of raw SQL strings nobody wants to touch. Each layer has its own concept of "model," its own migration story, its own way of describing a where clause. The code in your services is suddenly half plumbing.

I built Forge because every other TypeScript ORM I tried forced me to pick one surface and treat the rest as a foreign country.

(https://www.npmjs.com/package/forge-orm)

The constraint that produced it

I was working on a multi-tenant SaaS that had to:

Run Postgres for transactional state
Use Mongo for high-volume nested documents that didn't want a schema
Work fully offline in the browser on a Tauri-packaged client, including a point-of-sale flow that took payments without a network
Geocode every location and answer nearest-neighbor queries on them
Eventually add embeddings so an operator could type "blue cotton tee" and find products without exact keyword matches

Pick any two of those and the existing ORMs work. Pick three and you start writing glue. Pick all five and you spend more time keeping four data layers in sync than building features.

Prisma covers Postgres beautifully and treats Mongo as a second-class adapter. It has no browser story at all. Geo is raw SQL. Vector is raw SQL.

Drizzle is the cleanest TS-native SQL builder I've ever used — but it's SQL-only. No Mongo. No browser. Geo and vector escape into hand-written fragments.

Kysely has the best types of any query builder, but it's also SQL-only and intentionally not an ORM. You write joins. No relations sugar. No browser.

TypeORM has Mongo support, but the types degrade to any so often the TypeScript story is barely real, and decorators don't compose with edge runtimes.

Mongoose handles Mongo well. It does not handle Postgres at all.

Dexie handles IndexedDB. It does not handle anything else.

So you stack them. And you write a small in-house abstraction layer on top so service code doesn't have to know which one it's hitting. And that layer eats a month every year just keeping up.

Forge is what happens when you decide that's not acceptable and try to put one query language under all of it.

Video: https://youtu.be/FpOaneoCzpw

What you actually get

*One vocabulary across six dialects
*
Forge has adapters for Postgres, MySQL, SQLite, Mongo, DuckDB, and MSSQL. The same query method names work on all six:

// Postgres
await db.User.findMany({ where: { tier: "pro" }, limit: 20 })

// Mongo
await db.User.findMany({ where: { tier: "pro" }, limit: 20 })

// DuckDB (analytical)
await db.User.findMany({ where: { tier: "pro" }, limit: 20 })

That's not "compatible-ish." Those are byte-identical service-layer calls. The adapter underneath translates where, limit, orderBy, select, include, groupBy, upsert, transaction, and the rest into the dialect's native form. A Mongo $or becomes a SQL OR. A SQL NOT IN becomes Mongo's $nin. JSON path access becomes ->> on Postgres and dotted-key access on Mongo.

The point isn't that you'll switch databases (you mostly won't). The point is that when a feature lands that needs the other database, you don't relearn an ORM. You point a different db at the same schema and write the same code.

The browser is a first-class target

This is the part I haven't seen elsewhere.

Forge ships a browser adapter built on sqlite-wasm + OPFS, running in a Web Worker. It mounts as opfs:/your-db.sqlite or opfs-sahpool:/... for synchronous-access-handle mode, or :memory: for tests. There are Vite, Next.js, and Webpack plugins that handle the wasm loading without you wiring it.

// In the browser. Same API as the server.
const db = await createBrowserDb({ schema, url: "opfs:/dallio.sqlite" })
await db.Invoice.create({ data: { number: "INV-3308", total: 4250 } })
const drafts = await db.Invoice.findMany({ where: { status: "draft" } })

The query you wrote for your server's Postgres works in the user's browser against SQLite. You stop maintaining two data layers because the same model is the same model. Offline drafts, offline POS sales, offline product catalogs — all queryable with the same findMany your service code uses, no IndexedDB wrapper, no Dexie schema duplicated from your Postgres schema.

For a Tauri app or a PWA that needs to keep working when the network drops, this collapses an entire architectural sub-project into a config flag.

Geo, vector, and JSON path are typed


const Place = f.model("places", {
  id: f.id(),
  name: f.string(),
  location: f.geoPoint({ srid: 4326 }),
  embedding: f.vector(1536),
  details: f.json<{ openingHours: string[]; tags: string[] }>(),
})

// Nearest 10 places to a point — Postgres uses PostGIS, MySQL uses
// ST_Distance_Sphere, Mongo uses $near. Same query call.
const nearby = await db.Place.findMany({
  where: { location: { nearTo: { point: [3.42, 6.45], withinMeters: 5000 } } },
  limit: 10,
})

// Vector similarity — same vocabulary as geo
const similar = await db.Place.findMany({
  where: { embedding: { nearTo: { vector: queryEmbedding, take: 5 } } },
})

// Typed JSON path — no string fragments
const cafes = await db.Place.findMany({
  where: { "details.tags": { contains: "cafe" } },
})

None of those require raw SQL. None require a separate vector library. None require a PostGIS adapter package. The results are typed — nearby[0].location is a [number, number], similar[0].embedding is number[], details.tags is string[].

If you've ever written a cosine_similarity() SQL fragment by hand or tried to thread PostGIS through Prisma raw queries, you know what the absence of this costs.

No binary engine, no codegen step

Forge is pure TypeScript. There is no Rust query engine that needs to be downloaded per platform, no prisma generate step in your CI, no .prisma schema file written in a custom DSL.

Your schema is a TS file. Models are values. Importing them gives you typed query methods. That's the whole setup.

Cold start on Lambda or Vercel Functions is under 50ms, the same as Drizzle and Kysely, an order of magnitude faster than Prisma's historical baseline. Edge runtimes (Workers, Vercel Edge, Bun, Deno) work natively because nothing about Forge requires Node-specific APIs.

Drift detection that works in production

const report = await db.$migrate()
// {
//   alteredColumns: [{ table: "users", column: "phone", action: "added" }],
//   pending: [{ table: "users", column: "legacy_id", action: "drop" }],
// }

db.$migrate() walks the live schema against the model definitions. Safe drift (an added column, a new index) gets applied automatically. Destructive drift (a column that no longer exists in the model) is surfaced under pending for your migration tool to handle deliberately. You can opt out with db.$migrate({ alter: false }).

db.$diff(driver, { schema }) returns the same report without applying anything. db.$doctor() runs a live probe — checks extensions, indexes, encoding, latency — and tells you what's wrong. Both work in the browser too, against the user's OPFS SQLite.

In practice this means the day a new feature ships with two new columns, you don't need to ship a migration file. You can let $migrate() apply the additions on boot and ship a migration for the destructive part next sprint. Or, if you're more conservative, you can run $diff() in CI and refuse to deploy when drift is detected. Both flows work.

Atomic upsert that actually is atomic

await scopedDb.User.upsert({
  where: { email },
  create: { email, name, tier: "free" },
  update: { lastSeenAt: now },
})

That call compiles to INSERT ... ON CONFLICT DO UPDATE on Postgres, INSERT ... ON DUPLICATE KEY UPDATE on MySQL, MERGE on MSSQL,

findOneAndUpdate({ upsert: true }) on Mongo, and the SQLite equivalent. One round trip. No find-then-branch race condition. No accidental double-insert under concurrency.

I mention this because it's not glamorous, but every ORM that doesn't do it correctly produces a class of intermittent production bugs you can never reproduce locally and your tracing tool blames on "user double-clicked." Forge does it correctly across all six dialects.

What Forge is not

I'll be direct about this because honest tradeoffs are part of why anyone trusts a recommendation.

There is no Studio. Prisma Studio is a category-defining piece of tooling. db.$doctor is CLI-only and doesn't browse data. If your team includes people who want to click around tables in a GUI, Forge will frustrate them until a Studio ships.

There is no SaaS company behind it. That has good and bad sides. No paid Accelerate/Pulse/Optimize tier means the OSS roadmap isn't shaped by upsell pressure. No SaaS company also means no support contract, no enterprise SLA, no Salesforce conference booth, no team of dedicated maintainers if I get hit by a bus.

The community is tiny. If you Google a Forge error, you'll mostly find the README. Stack Overflow won't help. There are no YouTube tutorials. Onboarding a junior engineer takes longer because the answer to "how do I do X" is "read the source," not "watch this 20-minute video."

Depth versus breadth. Drizzle has gone deeper into Postgres-specific edge cases than Forge has. Mongoose has gone deeper into Mongo's aggregation pipeline. Forge covers six dialects well, but a dialect-specific ORM will always go deeper into its one dialect. If you need Postgres logical replication consumer slots or Mongo's exact change-stream resume semantics surfaced as a first-class API, you'll write that integration yourself in Forge.

It's young. First release was 2024. 2.5.3 is the current version. The shape is stable, the test suite is large (the test file count crossed 470 in 2.5.3, mostly per-dialect parity), but five-year battle scars accumulate things you can't get faster. Expect a few rough edges.

If those are dealbreakers, Drizzle or Prisma is your answer. That's a real choice, not a consolation prize.

When Forge is the right answer

Pick Forge when:

Your data already lives in more than one place. Postgres + Mongo. Postgres + SQLite (mobile sync). DuckDB for analytics over a transactional Postgres. MSSQL for a legacy system plus Postgres for the new one. Forge collapses the abstraction tax of running multiple ORMs.
You're building an offline-first or local-first app. Tauri desktop apps, Capacitor mobile apps, PWAs that need to work on flaky connections. Forge's browser adapter means you maintain one data layer instead of one server data layer plus one client IndexedDB layer plus the sync code between them.
Geo or vector is on your roadmap. Even if you don't need them today, building them on raw SQL fragments is a permanent tax. Forge surfaces both as typed primitives.
You care about cold starts. Lambda, Vercel Functions, Cloudflare Workers — Forge is pure TS, no binary, no codegen runtime. Drizzle and Kysely match it; Prisma still doesn't.
You like writing code more than configuration. The schema is a TS file. The migration story is "the live schema and the models disagree, here's what changed." There's no DSL, no codegen step, no separate migration CLI to learn.

Don't pick Forge when:

You have a senior Postgres-only team that already loves Drizzle. Forge wouldn't make their day better.
You need Studio and your stakeholders aren't going to budge.
You're shipping inside a company that requires a vendor with a support contract.

Getting started

npm install forge-orm@^2.5.3

Define a model file:

// schema.ts
import { f } from "forge-orm"

export const User = f.model("users", {
  id: f.id(),
  email: f.string({ unique: true }),
  name: f.string(),
  tier: f.enum(["free", "pro", "enterprise"]).default("free"),
  createdAt: f.timestamp().defaultNow(),
})

export const schema = { User }

Connect from your server:

import { createPostgresDb } from "forge-orm/postgres"
import { schema } from "./schema"

export const db = createPostgresDb({ schema, url: process.env.DATABASE_URL! })
await db.$migrate() // applies safe drift on boot

Or from the browser:

import { createBrowserDb } from "forge-orm/browser"
import { schema } from "./schema"

export const db = await createBrowserDb({ schema, url: "opfs:/app.sqlite" })
await db.$migrate()

The same db.User.findMany({ where: { tier: "pro" } }) works in both. That is the entire setup.

A statement about TypeScript data layers in 2026

The data layer should follow your data, not the other way around. When a feature pushes you toward a different database — analytical, document, offline — the ORM should come with you, not force you to maintain a second one.

Most TypeScript ORMs were built when "the database" meant Postgres or maybe MySQL. They optimize for the depth of that single relationship. That's an honest tradeoff and it produces excellent tools for the case where it's correct.

But TypeScript apps in 2026 aren't single-database anymore. They run partially in the browser. They store transactional data in one engine and analytical data in another. They pull embeddings out of vector indexes and locations out of geo indexes. They sync some state offline and reconcile it when the network returns.

Forge is what an ORM looks like if you take that reality as the starting point.

It is not the safe choice. The safe choice is Prisma. The cool choice is Drizzle. The purist choice is Kysely.

Forge is the choice when none of those covers your data's actual shape, and you'd rather pay the cost of a younger tool than the cost of running four mature ones in parallel for the rest of the project's life.

If that's where you are, forge-orm@^2.5.3 (https://www.npmjs.com/package/forge-orm) is one npm install away.

How I Built a Chrome Extension to Extract Emails and Phone Numbers – A Developer’s Journey

Johnson Fash — Sat, 29 Nov 2025 08:55:17 +0000

As a fullstack developer, I’m always on the lookout for tools that save time and automate repetitive tasks. One thing I noticed early in my career is that collecting contact information—emails and phone numbers—from websites can be tedious, especially if you’re doing it manually. Whether it’s for outreach, research, or building a curated contact list, manually scanning pages is slow, error-prone, and frankly, exhausting.

That’s when I decided to create my very first Chrome extension: an Email and Phone Extractor. This project wasn’t just about scraping data; it was about building a lightweight, user-friendly, and reliable tool that anyone could use ethically and efficiently.

You can add the Extension to your chrome browser here!

Why I Built This Extension

The idea came from my own workflow frustrations. I often needed contact information from company websites, portfolio pages, or public directories. Copying and pasting each email or number was draining. I wanted a tool that would scan the page automatically, organize the results, and give me a clean output I could use immediately.

I envisioned a simple Chrome extension that could:

Detect all email addresses and phone numbers on the current page.
Provide a clear interface to view, copy, or save the extracted contacts.
Handle dynamically loaded content without slowing down the browser.
Be easy for anyone to install and use, even without a technical background.

Getting Started with Chrome Extension Development

Building a Chrome extension was a new adventure for me. I started by diving into Chrome’s extension APIs. Chrome extensions have three main components:

Manifest file – defines the extension’s metadata and permissions.
Content scripts – allow the extension to interact with the web page’s DOM.
Background scripts – handle messaging, persistent storage, and long-running tasks.

Building a Clean and Intuitive Interface

One of my main goals was user experience. I wanted the extension to be simple but functional. The popup displays:

Emails and phone numbers in separate sections
A button to copy all results to the clipboard
A count of unique emails and phone numbers

Optional filters to remove duplicates

I wanted users to feel in control. They can extract all contacts with a single click and copy them without dealing with messy page content.

Ethical Considerations

While the extension can extract public information, I wanted to make ethical use clear. I added a disclaimer reminding users to respect privacy laws and not misuse the tool for spam. Emails and phone numbers collected should only be used for legitimate purposes, like reaching out professionally or conducting research.

Challenges Along the Way

Building this extension wasn’t without hurdles:

Handling large pages: Some websites have thousands of DOM nodes. I had to ensure the extension scanned efficiently without freezing the browser.
Dynamic content: Modern sites often load data asynchronously. Mutation observers were critical here.
False positives: Regex sometimes matched text that looked like emails or phone numbers but weren’t. I added filtering and validation to minimize this.
Cross-browser quirks: While building primarily for Chrome, I ensured that the extension’s logic could be adapted for other Chromium-based browsers like Edge and Brave.

Real-Life Use Cases

Here are some ways developers and professionals can benefit from this extension:

Sales and Business Development: Quickly gather leads from public directories and websites.
Recruitment: Extract contact information of potential candidates from company pages or LinkedIn profiles (respecting platform policies).
Networking: Build professional connections by compiling contact lists for outreach.
Research & Data Collection: Academics and researchers can collect emails for surveys or collaborations.

Because of these use cases, the extension isn’t just a productivity tool—it’s a way to automate routine tasks and focus on what truly matters.

Sharing My Work

After testing extensively and refining the features, I published the extension on the Chrome Web Store. The process taught me a lot about packaging, metadata, and compliance with Google’s publishing rules. I also shared it with friends and colleagues, who found it immediately useful.

For those interested, you can try it here: Email & Phone Extractor Chrome Extension

Lessons Learned

Building this Chrome extension was more than a coding exercise—it was a lesson in user experience, problem-solving, and ethical development. Some key takeaways:

Even small projects can have complex technical challenges
Regex is powerful but requires careful testing
Handling dynamic content is critical for modern web tools
Ethical considerations should never be overlooked

Conclusion

Creating the Email and Phone Extractor Chrome extension was a fulfilling journey. It started as a personal tool to save time and evolved into a polished extension that can help other developers, researchers, and professionals streamline their workflows.

If you’re a developer looking for a practical project, Chrome extension development is a fantastic way to combine front-end skills with practical problem-solving. And who knows—you might just build a tool that thousands of people end up using!

Email & Phone Extractor — One-Click Contact Collection for Any Website

Johnson Fash — Tue, 25 Nov 2025 10:04:03 +0000

A friend of mine spent hours manually collecting emails and phone numbers from websites. If you have, then you know it can drive one insane.

After watching a friend on a google meet “speed-run” through LinkedIn, and opened a couple of company websites for lead generation, I realized something: the tools that automate this were either too expensive or too limited.

So, as a developer, i built a solution — a Chrome extension that extracts emails and phone numbers from any webpage with just one click.

Here’s the story behind it, how it works, and why it could change the way you handle web-based contacts.

The Story Behind Email & Phone Extractor

About two months ago, a friend of mine, a digital marketer, was giving me tips on LinkedIn optimization.

While talking, he opened Google Maps, lists of companies, multiple website tabs, and internal links — basically navigating a maze while multitasking. I asked him,

“Bro, why is this so manual?”
He laughed and said:

“The extensions that automate this are too expensive for Nigerians.”
That one sentence sparked an idea. I love turning repetitive, manual tasks into clean, one-click solutions. That night, I started building the first version of Email & Phone Extractor, and now it’s a real Chrome extension that works today.

How It Works

Install the Extension
Available on the Chrome Web Store. One click installs it in seconds.

Navigate to Any Page
Works on LinkedIn, WhatsApp Web, company websites, and almost any Single Page Application (SPA).

Click the Extension Icon
Instantly extracts emails and phone numbers visible on the page, including content loaded dynamically via JavaScript.

View or Export Data
Export contacts as JSON or copy to clipboard. Manage them on your local machine or via our optional account sync feature.

Handles Complex Sites
Unlike simple scrapers, this tool digs into local and session storage, IndexedDB, and cached data to extract contacts even when they’re hidden from the DOM.

Why I Built It

The mission is simple: save time, reduce frustration, and make web contact collection accessible to everyone.

Whether you’re a marketer, sales professional, researcher, or just curious, this extension turns tedious manual scraping into a clean, one-click workflow.

Speed: Collect data in seconds, not hours.

Versatility: Works on almost any site.

Accessibility: No expensive subscriptions or complex setups.

Demo Video

Watch it in action:

https://youtu.be/GWFwXpZ9Tl4

Screenshots

Get Started

Install the Chrome extension, and start extracting emails and phone numbers in one click:

Let Me Introduce to You My Portfolio Website

Johnson Fash — Mon, 26 Apr 2021 14:45:59 +0000

Hello Everyone,

I have finally completed the built of my portfolio website

Features

Static Landing Page with CSS,HTML and JavaScript Custom Animation
Blog Posts
Custom Management System (WordPress Clone) with SEO Manager
Project Demo and more

Here is the Link: https://apluswebmaker.com

JavaScript On Scroll Animation Library

Johnson Fash — Thu, 22 Apr 2021 07:51:59 +0000

OnScroll Animation

On Scroll Animation Library is a simple JavaScript library for animation when element(s) are in view while scrolling the browser.

🚀 Demo

⚙ Installation

Option A.

NPM installation

npm install onscroll-animation --save

Import:

import OnScrollAnimation from "onscroll-animation";

const animate = new OnScrollAnimation({
  ...
});

Option B.

Use CDN - load directly from jsDelivr CDN

<script src="https://cdn.jsdelivr.net/npm/onscroll-animation@latest/dist/animate.bundle.js"></script>


<script>
var animate = new OnScrollAnimation({
  ...
});
<script>

Use

var animate = new OnScrollAnimation({
        ".grid11": {
          parameters: [
            "animation-duration: 0.8s",
            "animation-delay: 1s",
            "animation-fill-mode: forwards"
          ],
          to: ["transform: translateX(-150px)"]
        },
        "section.one .left, section.three .book, section.five .other": {
          from: ["left: -500px"],
          to: { left: "0px" }
        },
        "section.one .right, section.three .complex, section.five .person": {
          from: ["right: -500px"],
          to: ["right: 0px"]
        },
        "section.two": {
          from: ["opacity: 0", "transform: translateY(100px)"],
          to: [ "opacity: 1", "transform: translateY(0px)"]
        },
        ".grid10":{
          parameters: ["animation-duration: 0.8s", "animation-fill-mode: forwards"],
          to: ["transform: translateY(-110px)"]
        }
      });
      animate.defaultParam(["animation-duration: .8s", "run: once", "animation-fill-mode: forwards","pixel-correction: -100px", "animation-time-function: ease-out"]);
      animate.init();

Explanation

OnScrollAnimation class

OnScrollAnimation({....}) accept only an object {...}. This object contains css selectors like ".grid10", "section.two img, section.four img" etc.

Basically, this object properties can be any css selector, which a document.querySelector() method accepts.

The value for the CSS Selector i.e ".grid4" must be an object which holds various properties and values for animation to work.

Properties

1. `parameters:[...] or parameters: {...}` ;

This define @keyframes property for each element i.e parameters: [...] or parameters: {...) can be an array containing strings of regular css or object containing its javascript equivalent like the example below:

run

run can be omitted or included. This lets you determine if animation runs once or continous anytime an animated element is in view.

pixelCorrection

pixel-correction or pixelCorrection use to make correction (in pixel) to when animation starts for an element. i.e 100px means scroll 100px downward before animation starts for an element in viewport, and -100px the opposite.

parameters: [
  "animation-duration: 1s",
  "animation-delay: 2s",
  "animation-fill-mode: forwards",
  "animation-time-function: ease-in",
  "pixel-correction: -200px",  // makes correction to how far down or up to go before element in view animates
  "run: once",   //can be ommited. default is to run everytime element is in view
    ..........
  ]

  or using object

  parameters: {
  animationDuration: "1s",
  animationDelay: "2s",
  animationFillMode: "forwards",
  animationTimeFunction: "ease-in",
  pixelCorrection: "-200px",
  run: "once",
    ..........
  ]

NOTE:

There is non shortcut like "animation: drop 1s forwards" for now. Please specifically list out your @keyframes by name and function like in the example above.

Properties of a selector i.e parameters, **from**, to, 0%, **75%** and more can both be an array, containing string equivalent of your regular css property or an object containing its equivalent in javascript. i.e "max-width" is maxWidth when working with objects.

2. from: [...] or from:{...}

Similar to css property from {.....} used in @keyframe. i.e from: ["width: 0px","height:20px"....]

3. to: [...] or to: {....}

Similar to css property to: {.....} used in @keyframe after defining from {...} i.e to: {width: "100%",height: "200px"}

4. 0: [...], 50: [...], 100:{.....}

This is similar to using percentage in @keyframes, only difference is not including the % sign i.e

const animation = OnScrollAnimation({
  "#imag1": {
    parameters: [.....],
    0: ["width: 20px".....],
    30: [......],
    80: [.....]
  },
  ..........
});
animation.init();

Using custom css

Without defining animation @keyframes in javascript, custom css can be used with each element by including a class that defines the @keyframe in your stylesheet i.e

<body>
  <img alt="ball" scr="./asset/ball.jpg" class="image1"/>
</body>

<style>
  .move {
    animation: ballmove 1s forwards;
  }
  @keyframes ballmove{
    from {
      transform: -100px;
    }
    to {
      transform: 300px;
    }
  }
</style>

<script>
const animation  = new OnScrollAnimation({
  ".image1": {
    css: "move"  // adds custom css class only
  },
  "img": {
    css: "bounce"
  }
});
animation.init();
</script>

Animation.defaultParams()

The Animation method defaultParams() defines a default paramter for each selector. Meaning you can ommit the parameters property for every element if they are all thesame i.e

const animation = new OnScrollAnimation({
  ".grid1, .grid2": {
    from: [....],
    to: [....]
  },
  ".grid4": {
    0: [...],
    50: [...]
  }
  ........
});
animation.defaultParams(["animation-duration: 1s", "animation-fill-mode: forwards"]); // or animation.defaultParams({animationDuration: "2s".......});
animation.init();

You can also ovaride the defaultParams() method for an element by specifying its own parameters i.e

const animation = new OnScrollAnimation({
  ".grid1, .grid2": {
    from: [....],
    to: [....]
  },
  ".grid4": {
    parameters: [....]  // override defaultParams
    0: [...],
    50: [...]
  }
  ........
});
animation.defaultParams(["animation-duration: 1s", "animation-fill-mode: forwards"]); // or animation.defaultParams({animationDuration: "2s".......});
animation.init();

Animation.init()

The init() method initialize the animation to run after the page loads.

More Example:

const animation = new OnScrollAnimation({
        ".one": {
          parameters: [
            "animation-duration: 1s",
            "pixel-correction: -100px",
            "animation-delay: .5s",
            "animation-time-function: linear"
          ],
          from: [
            "transform: translateY(-1000px)"
          ],
          to: [
            "transform: translateY(0px)"
          ]
        },
        ".two": {
          parameters: [
            "animation-duration: 1s",
            "pixel-correction: -300px"
          ],
          from: {
            transform: "rotate(0deg)"
          },
          to: [
            "transform: rotate(360deg)"
          ]
        },
        "article.three": {
          parameters: {
            animationDuration: "1s",
            animationFillMode: "forwards",
            animationTimingFunction: "ease-in"
          },
          0: [
            "transform: translateX(-1000px)",
          ],
          50: [
            "transform: translateX(1000px)",
            "background-color: red"
          ],
          100: [
            "transform: translateX(0px)"
          ]
        },
        ".four": {
          parameters: [
            "animation-duration: 1s"
          ],
          from: [
            "transform: skewX(20deg) translateX(-1000px)"
          ],
          to: [
            "transform: skewX(0deg) translateX(0px)"
          ]
        },
        ".five": {
          parameters: [
            "animation-duration: 1s"
          ],
          from: [
            "position: relative",
            "right: -1000px",
            "transform: skewX(-20deg)"
          ],
          to: [
            "position: relative",
            "right: 0px",
            "transform: skewX(0deg)"
          ]
        },
        ".six": {
          parameters: [
            "animation-duration: 2s",
            "animation-fill-mode: forwards",
          ],
          0: [
            "transform: translateY(0)"
          ],
          75: [
            "transform: translateY(50vh)"
          ]
        },
        ".seven": {
          parameters: [
            "animation-duration: 1.5s"
          ],
          from: [
          "transform: rotateY(0deg)"
          ],
          to: [
          "transform: rotateY(360deg)"
          ]
        }
      });
      animation.init();

DEV Community: Johnson Fash

The column that existed on staging and not on production

forge push — the boring one

forge diff --check — the gate

forge generate — a migration with no database in the room

forge migrate status — the two states nobody reports

The two refusals

A rename is not a drop and an add

A widening is emitted; a narrowing is refused

Two bugs, and one embarrassment

The empty upsert

The MySQL near-miss

The examples that quietly rotted

The argument

The series

The same models, on a phone with no signal

Three codebases describing the same invoice

The models are the same file

A warning: never import forge-orm/sqlite on React Native

One dialect, several packages

$migrate(), because there's no CLI on a phone

The honest limits

The network died mid-sale. The customer still had cash in her hand.

What you normally do about this

The version I wanted

Tier one: IndexedDB, nothing to install

$migrate(), because there is no CLI in a browser tab

The offline-first shape

Tier two: real SQLite, over OPFS

The limits, stated plainly

Did it fix the shop?

The afternoon my teammate lost to a stale generated client

Why the codegen step exists

The bill

The other route

What this costs, honestly

"But then how do I know what SQL runs?"

I picked MongoDB on day one. By month eight I needed Postgres.

What I actually wanted

forge-orm

The part I didn't expect to matter

What it is not

Did it actually solve the problem?

Prisma can now work in your browser, expo/react-native apps? — meet forge-orm

One query language for SQL, Mongo, and the browser: the case for Forge

The constraint that produced it

What you actually get

Geo, vector, and JSON path are typed

No binary engine, no codegen step

Drift detection that works in production

What Forge is not

When Forge is the right answer

Pick Forge when:

Don't pick Forge when:

Getting started

Define a model file:

Connect from your server:

How I Built a Chrome Extension to Extract Emails and Phone Numbers – A Developer’s Journey

Why I Built This Extension

Getting Started with Chrome Extension Development

Building a Clean and Intuitive Interface

Ethical Considerations

Challenges Along the Way

Real-Life Use Cases

Sharing My Work

Lessons Learned

Conclusion

Email & Phone Extractor — One-Click Contact Collection for Any Website

The Story Behind Email & Phone Extractor

How It Works

Why I Built It

Demo Video

Screenshots

Get Started

Let Me Introduce to You My Portfolio Website

Hello Everyone,

Features

JavaScript On Scroll Animation Library

OnScroll Animation

🚀 Demo

`forge push` — the boring one

`forge diff --check` — the gate

`forge generate` — a migration with no database in the room

`forge migrate status` — the two states nobody reports

A warning: never import `forge-orm/sqlite` on React Native

`$migrate()`, because there's no CLI on a phone

`$migrate()`, because there is no CLI in a browser tab