---
title: "Web tier sa Cloudflare Workers"
description: "Patakbuhin ang pinasimpleng web tier ng Quire sa Cloudflare Workers."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/fil/llms.txt
> Use this file to discover all available pages before exploring further.

# Web tier sa Cloudflare Workers

<span id="the-web-tier-on-cloudflare-workers"></span>

Nasa seksiyon 6 ng `docs/architecture/23-ops.md` ang disenyo. Pinapatakbo ng
Workers ang pinasimpleng web tier. Hindi saklaw ng layunin ang feature parity
sa Workers (PRD seksiyon 12): tinatanggihan sa pagsisimula ang hindi kayang gawin
gamit ang pangalan nito.

## Katayuan sa release na ito <!--quire:status-in-this-release-->

Nakahanda na ang configuration (`apps/web/wrangler.jsonc`, ang `cloudflare-module`
Nitro preset, Hyperdrive bridge, at mga startup check). Kailangan ng Worker ang
S3-compatible na storage para sa R2 (`QUIRE_STORAGE_DRIVER=s3`), realtime driver
sa iba't ibang request (`QUIRE_REALTIME_DRIVER=durable_objects` o `centrifugo`),
shared cache (`QUIRE_CACHE_DRIVER=postgres` o `valkey`), at HTTP email provider.
Kung wala ang mga ito, tatanggi itong magsimula at ililista ng log ang setting.
Client ng realtime Worker sa `apps/realtime-worker` ang Durable Objects driver
(isang Durable Object bawat channel para sa fan-out, presence, at history; isa
bawat tao para sa mga disconnect); i-deploy ito sa tabi ayon sa ibaba, o gumamit
ng Centrifugo.

## Mga bahagi <!--quire:the-pieces-->

| Bahagi | Sa Cloudflare |
| --- | --- |
| `web` | Worker na may `nodejs_compat` |
| Postgres | External, naaabot gamit ang Hyperdrive: `HYPERDRIVE` para sa application role at `REPORT_HYPERDRIVE` para sa report role sa parehong pisikal na database. Kinokopya ng web tier sa `DATABASE_URL` at `QUIRE_REPORT_DATABASE_URL` ang bawat connection string sa pagsisimula |
| Files | R2 gamit ang S3 API (`S3_ENDPOINT=https://<account>.r2.cloudflarestorage.com`); ikinakabit ng `FILES` binding ang bucket |
| Mga background job | pg-boss sa Hyperdrive kapag dapat ipila ang trabaho kasama ng write. Kapag `QUIRE_QUEUE_DRIVER=cloudflare` sa kasamang worker, dumaraan naman sa Cloudflare Queues ang magaang trabaho (walang pagkakasunod na notification at webhook delivery), kaya hindi ito i-poll sa Postgres. Pareho itong pinapatakbo ng kasamang worker |
| Realtime | Realtime Worker na `apps/realtime-worker` na may Durable Objects |
| `worker`, `scheduler`, `collab`, `content`, ClamAV, Gotenberg, ffmpeg | Kasamang container host. Hindi kayang patakbuhin ng Worker ang mga ito |
| Tracing | Workers observability na naka-enable sa `wrangler.jsonc` |

Ibinibigay ng `REPORT_HYPERDRIVE` ang report role para sa pisikal na database na
pinangalanan ng `HYPERDRIVE`. Hindi nagsisilbi ang target na ito sa tenant na
naka-pin sa dagdag na pisikal na database, gaya ng inilalarawan sa ibaba.

## Hindi kayang gawin ng target na ito <!--quire:what-this-target-cannot-do-->

Tinatanggihan ito sa pagsisimula at sabay-sabay na inililista ang lahat ng problema:

- **Walang SMTP.** Gumamit ng HTTP provider sa `QUIRE_EMAIL_PROVIDER_CONFIG`.
- **Walang lokal na disk.** Kailangang tumukoy ang `QUIRE_STORAGE_DRIVER` sa
  object storage.
- **Walang in-process realtime o cache.** Walang memory na pinaghahatian ang
  request ng Workers, kaya tinatanggihan ang `QUIRE_REALTIME_DRIVER=inprocess`
  at `QUIRE_CACHE_DRIVER=memory`.
- **Walang ClamAV, Gotenberg, o ffmpeg sa Worker.** Tinatanggihan ang
  `CLAMAV_URL`, `GOTENBERG_URL`, at `FFMPEG_PATH` kapag itinakda sa Worker;
  sa kasamang worker itakda ang mga ito.
- **Walang organisasyong may dedicated database.** Nakatakda sa deployment ang
  Hyperdrive binding ng Worker, kaya makakakita ng malinaw na “unavailable here”
  page ang organisasyong may sariling database. I-serve ito mula Compose o Vercel.

May isang bagay pang hindi tinatanggihan ngunit dapat malaman: **hindi gumagana
sa Workers ang prerendering at incremental static regeneration**, anuman ang
sinasabi ng dokumentasyon ng framework. Sa bawat request nirere-render ang route.

Sa target na ito, panatilihing maikli ang transaction at huwag itong panatilihing
bukas habang may network call: nire-reset ng Hyperdrive ang session state kapag
bumalik sa pool ang connection kaya itinatakda ang konteksto ng tenant bawat transaction.

## Pag-deploy <!--quire:deploying-->

1. Gumawa ng resource:
   ```sh
   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
   ```
   Ilagay ang dalawang Hyperdrive ID sa `apps/web/wrangler.jsonc`.
2. Isa-isang itakda ang secret gamit ang `bun run --bun wrangler secret put <NAME>` sa
   `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`. Itakda rin ang
   ordinaryong setting (`QUIRE_APP_ORIGIN`, `QUIRE_CONTENT_ORIGIN`,
   `QUIRE_PLATFORM_DOMAINS`, `QUIRE_DATABASE_ID`, `S3_ENDPOINT`, `S3_BUCKET`,
   `QUIRE_COLLAB_URL`) sa `vars`.
3. Mag-build at mag-deploy mula sa `apps/web`:
   ```sh
   NITRO_PRESET=cloudflare-module bun run build
   bun run --bun wrangler deploy
   ```
4. I-deploy ang realtime Worker gamit ang `QUIRE_REALTIME_WORKER_SECRET` ng web
   tier at token secret nito na `QUIRE_REALTIME_TOKEN_SECRET` (pinipirmahan ng
   web tier ang realtime token gamit ang sarili nitong `QUIRE_REALTIME_TOKEN_SECRET`
   o `QUIRE_SECRET_KEY` kung wala ang una, kaya gamitin kung ano ang ginagamit
   nito). Itakda sa web tier ang address nito sa `QUIRE_REALTIME_WORKER_URL`:
   ```sh
   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
   ```
5. Para sa magaang trabaho sa Cloudflare Queues, gumawa ng queue bawat light
   queue at itakda ang mga ito sa kasamang worker (API token na may Queues read
   at write):
   ```sh
   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
   ```
   Itakda ang `QUIRE_QUEUE_DRIVER=cloudflare`, `CLOUDFLARE_ACCOUNT_ID`,
   `CLOUDFLARE_QUEUES_TOKEN`, at `QUIRE_QUEUE_PREFIX` kung hindi `quire-`.
+6. Patakbuhin ang companion host gaya ng hakbang 3 sa [gabay sa Vercel](/fil/ops/vercel/).
+   Tumatakbo roon ang migration bago ang bawat Worker deployment.
+
+Makikita ang tinanggihang configuration sa `bun run --bun wrangler tail` bilang
+“The web tier did not start on cloudflare”, na sinusundan ng setting na dapat baguhin.
+EOF
perl -pi -e 's/^\+//' apps/docs-site/locales/fil/guides/ops/cloudflare.md
bun apps/docs-site/scripts/import-guide.ts fil ops/cloudflare.md

Source: https://docs.quirelms.com/fil/ops/cloudflare/index.mdx