11) Cloudflare Runtime Boundary

11) Cloudflare Runtime Boundary

Goal

Keep Cloudflare runtime concerns (D1, KV, Queue, R2, Durable Object bindings) in runtime entry layers and dedicated adapters, not in domain/business modules.

Boundary Model

• Runtime entry points:
  • apps/dashboard server functions and server adapters
  • workers/* src/index.ts and infra/runtime modules
• Runtime adapter package:
  • packages/platform-cloudflare
  • Owns Cloudflare-specific helper logic for shard binding selection and runtime utility access
• Domain/business modules:
  • Should accept plain values and interfaces
  • Should not depend on Cloudflare binding selection details

Canonical D1 Adapter Helpers

Use these from @legaciti/platform-cloudflare:

• getD1DatabaseForOrcid(orcid, bindings)
• getD1DatabaseForDoi(doi, bindings)
• getAllD1Databases(bindings)

This keeps shard-routing ownership in one runtime-specific package.

Dashboard Runtime Adapter Layer

Notification queue access is localized via:

• apps/dashboard/src/server/adapters/notifications-runtime.ts

Notification services call this adapter instead of reading cloudflare:workers directly.

Current Transitional Exceptions

• @platform/utils still exports legacy D1 helpers:
  • getDatabaseForOrcid
  • getDatabaseForDoi
  • getAllDatabases
• These exports are temporary for compatibility and should be removed after all runtime consumers migrate.

Migration Rule

When touching runtime data-access code:

1. Prefer @legaciti/platform-cloudflare for Cloudflare-specific binding helpers.
2. Keep @platform/utils for runtime-agnostic utilities only (normalizeDoi, patch helpers, parsing helpers, etc.).
3. If a module needs getBindings() or queue/db handles, route it through a local adapter in apps/*/src/server/adapters or worker infra runtime module.