Saltar al contenido

La capa web en Cloudflare Workers

Ejecuta una versión reducida de la capa web de Quire en Cloudflare Workers.

Ver como Markdown

El diseño se describe en la sección 6 de docs/architecture/23-ops.md. Workers ejecuta una capa web reducida. La paridad de funciones en Workers queda fuera del alcance (sección 12 del PRD): al iniciar, se rechazan por nombre las funciones que este destino no puede realizar.

Estado de esta versión

La configuración está lista (apps/web/wrangler.jsonc, el preajuste Nitro cloudflare-module, el puente Hyperdrive y las comprobaciones de inicio). Un Worker requiere almacenamiento compatible con S3 para R2 (QUIRE_STORAGE_DRIVER=s3), un controlador de tiempo real entre solicitudes (QUIRE_REALTIME_DRIVER=durable_objects o centrifugo), una caché compartida (QUIRE_CACHE_DRIVER=postgres o valkey) y un proveedor de correo HTTP. Sin estos, el Worker se niega a iniciar y sus registros indican cada configuración faltante. El controlador Durable Objects es cliente del Worker en tiempo real de apps/realtime-worker (un Durable Object por canal para distribuir eventos, manejar presencia e historial; y uno por persona para desconexiones); despliégalo junto con este, como se indica abajo, o usa Centrifugo.

Componentes

Componente En Cloudflare
web Un Worker con nodejs_compat
Postgres Externa, accesible mediante Hyperdrive: HYPERDRIVE para el rol de aplicación y REPORT_HYPERDRIVE para el rol de informes en esa misma base física. Al iniciar, la capa web copia cada cadena de conexión en DATABASE_URL y QUIRE_REPORT_DATABASE_URL
Archivos R2, mediante su API de S3 (S3_ENDPOINT=https://<account>.r2.cloudflarestorage.com); el binding FILES conecta el bucket
Tareas en segundo plano pg-boss mediante Hyperdrive cuando la tarea debe agregarse junto con una escritura. Con QUIRE_QUEUE_DRIVER=cloudflare en el worker complementario, las tareas ligeras (entregas de notificaciones y webhooks sin orden definido) pasan por Cloudflare Queues y no se consulta Postgres para ellas. El worker complementario ejecuta ambas opciones
Tiempo real Worker en tiempo real apps/realtime-worker, con Durable Objects
worker, scheduler, collab, content, ClamAV, Gotenberg y ffmpeg Host de contenedores complementario. Un Worker no puede ejecutarlos
Trazas Observabilidad de Workers, activada en wrangler.jsonc

REPORT_HYPERDRIVE proporciona el rol de informes para la base física indicada por HYPERDRIVE. Este destino no atiende a tenants fijados a otras bases físicas, como se explica abajo.

Limitaciones de este destino

Al iniciar, se rechaza la configuración y se enumeran todos los problemas:

  • No admite SMTP. Usa un proveedor HTTP en QUIRE_EMAIL_PROVIDER_CONFIG.
  • No hay disco local. QUIRE_STORAGE_DRIVER debe indicar almacenamiento de objetos.
  • No se puede usar tiempo real ni caché en el mismo proceso. Los Workers no comparten memoria entre solicitudes, por eso se rechazan QUIRE_REALTIME_DRIVER=inprocess y QUIRE_CACHE_DRIVER=memory.
  • El Worker no puede ejecutar ClamAV, Gotenberg ni ffmpeg. Se rechazan CLAMAV_URL, GOTENBERG_URL y FFMPEG_PATH si se configuran en el Worker; configúralos en el worker complementario.
  • No admite organizaciones con bases de datos dedicadas. Los bindings Hyperdrive de un Worker quedan fijos durante el despliegue, así que una organización con su propia base verá una página clara que indica “unavailable here”. Dale servicio desde Compose o Vercel.

También debes saber que la generación previa y la regeneración estática incremental no funcionan en Workers, sin importar lo que diga la documentación del framework. Cada ruta se genera en cada solicitud.

En este destino, mantén breves las transacciones y nunca las dejes abiertas durante una llamada de red: Hyperdrive restablece el estado de sesión cuando una conexión vuelve al pool, así que el contexto del tenant se establece por transacción.

Desplegar

  1. Crea los recursos:
    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
    Coloca los dos ID de Hyperdrive en apps/web/wrangler.jsonc.
  2. Configura los secretos, uno por uno con bun run --bun wrangler secret put <NAME> desde apps/web: QUIRE_SECRET_KEY, QUIRE_MASTER_KEY, QUIRE_EMAIL_PROVIDER_CONFIG, S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY, QUIRE_COLLAB_SIGNING_KEY y QUIRE_REALTIME_WORKER_SECRET. Las variables normales (QUIRE_APP_ORIGIN, QUIRE_CONTENT_ORIGIN, QUIRE_PLATFORM_DOMAINS, QUIRE_DATABASE_ID, S3_ENDPOINT, S3_BUCKET y QUIRE_COLLAB_URL) se agregan a vars.
  3. Compila y despliega desde apps/web:
    NITRO_PRESET=cloudflare-module bun run build
    bun run --bun wrangler deploy
  4. Despliega el Worker en tiempo real con el QUIRE_REALTIME_WORKER_SECRET de la capa web y su secreto de token en QUIRE_REALTIME_TOKEN_SECRET (la capa web firma los tokens con su propio QUIRE_REALTIME_TOKEN_SECRET o, si no está configurado, con QUIRE_SECRET_KEY; usa el mismo que usa la capa web). Configura QUIRE_REALTIME_WORKER_URL en la capa web con su dirección:
    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 usar Cloudflare Queues con tareas ligeras, crea una cola por cada una y configura estas variables en el worker complementario (un token de API con permisos de lectura y escritura de 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
    Configura QUIRE_QUEUE_DRIVER=cloudflare, CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_QUEUES_TOKEN y QUIRE_QUEUE_PREFIX si el prefijo no es quire-.
  6. Ejecuta el host complementario como se indica en el paso 3 de la guía de Vercel. Las migraciones se ejecutan ahí antes de cada despliegue del Worker.

Una configuración rechazada aparece en bun run --bun wrangler tail como «The web tier did not start on cloudflare», seguida de cada ajuste que debes cambiar.

Navegación

Escribe para buscar…

↑↓ navegar↵ seleccionarEsc cerrar