Weblaget på Cloudflare Workers

Designet beskrives i afsnit 6 i docs/architecture/23-ops.md. Workers kører et reduceret weblag. Funktionsmæssig lighed på Workers er uden for omfanget (PRD afsnit 12): det, denne platform ikke kan, afvises ved opstart og angives ved navn.

Status i denne udgivelse

Konfigurationen er på plads (apps/web/wrangler.jsonc, Nitro- forudindstillingen cloudflare-module, Hyperdrive-broen og opstartskontrollerne). En Worker kræver S3-kompatibel lagring til R2 (QUIRE_STORAGE_DRIVER=s3), en realtidsdriver på tværs af forespørgsler (QUIRE_REALTIME_DRIVER=durable_objects eller centrifugo), en delt cache (QUIRE_CACHE_DRIVER=postgres eller valkey) og en HTTP-e-mailudbyder. Uden dette nægter Workeren at starte, og loggen angiver hver indstilling. Durable Objects-driveren er klient til realtids-Workeren i apps/realtime-worker (ét Durable Object pr. kanal til udsendelse, tilstedeværelse og historik, og ét pr. person til afbrydelser). Udrul den sammen med webappen som beskrevet nedenfor, eller brug Centrifugo.

Komponenterne

Komponent	På Cloudflare
`web`	En Worker med `nodejs_compat`
Postgres	Ekstern, tilgås gennem Hyperdrive: `HYPERDRIVE` til applikationsrollen, `REPORT_HYPERDRIVE` til rapportrollen på samme fysiske database. Når weblaget starter, kopierer det hver forbindelsesstreng til `DATABASE_URL` og `QUIRE_REPORT_DATABASE_URL`
Filer	R2 via dets S3-API (`S3_ENDPOINT=https://<account>.r2.cloudflarestorage.com`); bindingen `FILES` tilknytter bucketten
Baggrundsjob	pg-boss gennem Hyperdrive, når jobbet skal lægges i kø med en skrivning. Hvis `QUIRE_QUEUE_DRIVER=cloudflare` er angivet på den tilhørende worker, går lette job (uordnede notifikations- og webhookleverancer) i stedet gennem Cloudflare Queues, så Postgres ikke spørges for dem. Den tilhørende worker kører begge dele
Realtid	Realtids-Workeren `apps/realtime-worker` med Durable Objects
`worker`, `scheduler`, `collab`, `content`, ClamAV, Gotenberg, ffmpeg	En tilhørende container-vært. En Worker kan ikke køre dem
Sporing	Workers-observability, aktiveret i `wrangler.jsonc`

REPORT_HYPERDRIVE leverer rapportrollen til den fysiske database, der er angivet af HYPERDRIVE. Denne platform betjener ikke lejere, der er fastlåst til yderligere fysiske databaser, som beskrevet nedenfor.

Hvad denne platform ikke kan

Afvises ved opstart, og alle problemer angives på én gang:

Ingen SMTP. Brug en HTTP-udbyder i QUIRE_EMAIL_PROVIDER_CONFIG.
Ingen lokal disk. QUIRE_STORAGE_DRIVER skal angive objektlagring.
Ingen realtime eller cache i processen. Workers deler ikke hukommelse mellem forespørgsler, så QUIRE_REALTIME_DRIVER=inprocess og QUIRE_CACHE_DRIVER=memory afvises.
Ingen ClamAV, Gotenberg eller ffmpeg i Workeren. Hvis CLAMAV_URL, GOTENBERG_URL og FFMPEG_PATH angives på Workeren, afvises de; angiv dem i stedet på den tilhørende worker.
Ingen organisationer med dedikerede databaser. En Worker’s Hyperdrive-bindinger er fastlagt ved udrulning, så en organisation med sin egen database får en tydelig side med meddelelsen “utilgængelig her”. Betjen den fra Compose eller Vercel.

Der er også én begrænsning, som ikke afvises, men som du skal kende: prerendering og inkrementel statisk regenerering fungerer ikke på Workers, uanset hvad frameworkdokumentationen siger. Hver rute gengives ved hver forespørgsel.

På denne platform skal transaktioner være korte, og du må aldrig holde en åben under et netværkskald: Hyperdrive nulstiller sessionsstatus, når en forbindelse vender tilbage til puljen, så lejerkonteksten angives pr. transaktion.

Udrulning

Opret ressourcerne:

bun run --bun wrangler hyperdrive create quire-app --connection-string="postgres://quire_app:...@db.example.com:5432/quire"
bun run --bun wrangler hyperdrive create quire-report --connection-string="postgres://quire_report:...@db.example.com:5432/quire"
bun run --bun wrangler r2 bucket create quire-files
bun run --bun wrangler queues create quire-jobs

Indsæt de to Hyperdrive-id’er i apps/web/wrangler.jsonc.

Angiv hemmelighederne én ad gangen med bun run --bun wrangler secret put <NAME> fra apps/web: QUIRE_SECRET_KEY, QUIRE_MASTER_KEY, QUIRE_EMAIL_PROVIDER_CONFIG, S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY, QUIRE_COLLAB_SIGNING_KEY, QUIRE_REALTIME_WORKER_SECRET. Almindelige indstillinger (QUIRE_APP_ORIGIN, QUIRE_CONTENT_ORIGIN, QUIRE_PLATFORM_DOMAINS, QUIRE_DATABASE_ID, S3_ENDPOINT, S3_BUCKET, QUIRE_COLLAB_URL) angives i vars.

Byg og udrul fra apps/web:

NITRO_PRESET=cloudflare-module bun run build
bun run --bun wrangler deploy

Udrul realtime-Workeren med weblagets QUIRE_REALTIME_WORKER_SECRET og dens tokenhemmelighed som QUIRE_REALTIME_TOKEN_SECRET (weblaget signerer realtime-tokens med sin egen QUIRE_REALTIME_TOKEN_SECRET eller med QUIRE_SECRET_KEY, hvis førstnævnte ikke er angivet; brug derfor den, som det anvender), og angiv QUIRE_REALTIME_WORKER_URL på weblaget til dens adresse:
```
cd apps/realtime-worker
bun run --bun wrangler secret put QUIRE_REALTIME_WORKER_SECRET
bun run --bun wrangler secret put QUIRE_REALTIME_TOKEN_SECRET
bun run --bun wrangler deploy
```
Hvis lette job skal bruge Cloudflare Queues, skal du oprette en kø pr. let kø og angive følgende på den tilhørende worker (et API-token med læse- og skriverettigheder til Queues):
```
bun run --bun wrangler queues create quire-events-notifications
bun run --bun wrangler queues create quire-events-notifications-dead
bun run --bun wrangler queues create quire-events-webhooks
bun run --bun wrangler queues create quire-events-webhooks-dead
```
Angiv QUIRE_QUEUE_DRIVER=cloudflare, CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_QUEUES_TOKEN og QUIRE_QUEUE_PREFIX, hvis præfikset ikke er quire-.
Kør den tilhørende vært som beskrevet i Vercel-vejledningen, trin 3. Migreringer køres dér, før hver Worker-udrulning.

En afvist konfiguration vises i bun run --bun wrangler tail som “The web tier did not start on cloudflare”, efterfulgt af hver indstilling, der skal ændres.