@mediamonks/canopy-data-plane

THE data-plane implementation, shared verbatim by its two hosts: canopy-api mounts these routers under /data/v1 against project databases, and canopy dev --local mounts the very same routers against PGlite — the sandbox can't drift from the platform because they share the code.

• dbRouter — the SDK's document API (collection().insert/find/search/ update/delete) plus the raw-SQL escape hatch. Statements are rendered through an injected DocDialect (docs/08-target-adapters.md §5): dialect-sqlite.ts (D1/SQLite: FTS5 search, RFC 7386 json_patch) and dialect-postgres.ts (Cloud SQL/PGlite: jsonb, substring-ILIKE search fallback, shallow merge — the deliberate differences are documented in that file's header and surfaced to clients as capabilities.fts / canopy.db.dialect()). Raw db.sql() passes through untranslated: the escape hatch is explicitly the target's dialect.
• blobRouter — file storage over an injectable BlobStore (an R2-shaped bucket + the project's key prefix), including short-lived HMAC-signed download URLs (signing.ts).
• doc-store.ts — dialect-driven DDL + FTS-index lifecycle around data-safety exports. sql-dump.ts — quote/comment/dollar-quote-aware dump splitting.

Authorization and project resolution are deliberately the host's job: paths carry no project, and store(c) is where each host applies its own auth wall and hands back { store, dialect } (or an early Response).

Tests

vp test runs the dialect matrix: one behavior suite executed against both dialects on real engines — node:sqlite and @electric-sql/pglite — with the intentional divergences (search semantics, patch depth) asserted explicitly.

Published to npm via the staged workflow (root CLAUDE.md); workspace consumers import the TS source directly, so the CLI bundles it via noExternal.