{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibfrdfqyonkqhs5s4tvjgmszxanx7izvsfebobyuouwzgatjneaqe",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mow2unzaodq2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreigx6fjl6akrpbbixu4xywpbexd3i34jipsmh4s73bewxzxjerabge"
    },
    "mimeType": "image/webp",
    "size": 62562
  },
  "path": "/martin_palopoli/cron-jobs-sin-celery-sin-redis-sin-beat-como-fitz-mete-un-scheduler-distribuido-adentro-del-bj9",
  "publishedAt": "2026-06-22T23:10:31.000Z",
  "site": "https://dev.to",
  "tags": [
    "webdev",
    "python",
    "opensource",
    "programming",
    "github.com/Thegreekman76/fitz",
    "docs/guide.md",
    "@celery_app.task",
    "@app.post",
    "@cron",
    "@background",
    "@post"
  ],
  "textContent": "> Para correr una task cada 5 minutos en Python necesitás Celery + Redis + Celery Beat + worker process + Dockerfile dedicado. En Fitz es un decorador. Con retry, timezone, persistencia y catch-up adentro del lenguaje.\n\n##  La historia de siempre\n\nTu cliente está contento con la API. Está corriendo. Entonces te pide tres cosas:\n\n  1. \"¿Podemos limpiar sesiones vencidas cada noche?\"\n  2. \"¿Podés mandar el email de bienvenida en background así el signup no espera?\"\n  3. \"El reporte diario tiene que correr a las 9 AM hora de Buenos Aires.\"\n\n\n\nTres pedidos chicos. Si estás en Python, la respuesta honesta es: \"ok, dame dos días para meter Celery.\"\n\n###  El stack típico de Python\n\n\n    pip install celery redis\n\n\n`celery_app.py`:\n\n\n\n    from celery import Celery\n    from celery.schedules import crontab\n\n    celery_app = Celery(\n        \"myapp\",\n        broker=\"redis://redis:6379/0\",\n        backend=\"redis://redis:6379/1\",\n    )\n\n    celery_app.conf.beat_schedule = {\n        \"cleanup-sessions-nightly\": {\n            \"task\": \"myapp.tasks.cleanup_old_sessions\",\n            \"schedule\": crontab(hour=3, minute=0),\n        },\n        \"daily-report\": {\n            \"task\": \"myapp.tasks.generate_daily_report\",\n            \"schedule\": crontab(hour=12, minute=0),  # 9am Buenos Aires = 12:00 UTC\n            # ojo: si DST cambia, esto te llega tarde\n        },\n    }\n    celery_app.conf.timezone = \"UTC\"\n\n\n`tasks.py`:\n\n\n\n    from .celery_app import celery_app\n    from .db import get_session\n\n    @celery_app.task(autoretry_for=(Exception,), retry_backoff=True, max_retries=3)\n    def cleanup_old_sessions():\n        with get_session() as s:\n            s.execute(\"DELETE FROM sessions WHERE expires_at < now()\")\n            s.commit()\n\n    @celery_app.task(autoretry_for=(SMTPError,), retry_backoff=True, max_retries=5)\n    def send_welcome_email(email: str):\n        smtp.send(email, \"Welcome!\")\n\n\n`api.py`:\n\n\n\n    @app.post(\"/signup\")\n    def signup(creds: Credentials):\n        user = create_user(creds)\n        send_welcome_email.delay(user.email)  # fire-and-forget vía broker\n        return user\n\n\n`docker-compose.yml`:\n\n\n\n    services:\n      api:\n        build: .\n        command: uvicorn api:app --host 0.0.0.0\n      celery-worker:\n        build: .\n        command: celery -A celery_app worker --loglevel=info\n        depends_on: [redis]\n      celery-beat:\n        build: .\n        command: celery -A celery_app beat --loglevel=info\n        depends_on: [redis]\n      redis:\n        image: redis:7-alpine\n\n\nMas:\n\n  * Un `supervisord.conf` o systemd unit que mantenga viva la cosa cuando crashee.\n  * (Opcional) `flower` para visibility — 4to proceso.\n  * Conversiones de timezone hechas a mano (Celery beat trabaja en UTC, vos tenés que calcular el offset).\n  * Cuando el worker crashea entre que pegó al broker y completó la task: ¿se reintenta? ¿queda colgada? Depende de cómo te configuraste el `acks_late` y `task_reject_on_worker_lost`.\n\n\n\nCuatro procesos en producción. Tres librerías nuevas. Un broker. Convenciones nuevas. Un día de setup.\n\n##  Lo mismo en Fitz\n\n\n    @cron(\"0 3 * * *\", tz=\"UTC\")\n    async fn cleanup_old_sessions(db: DbConn) {\n        db.exec(\"DELETE FROM sessions WHERE expires_at < now()\").await\n    }\n\n    @cron(\"0 9 * * *\", tz=\"America/Argentina/Buenos_Aires\")\n    async fn daily_report(db: DbConn) {\n        // ...\n    }\n\n    @background\n    async fn send_welcome_email(email: Str) {\n        // cosa cara\n    }\n\n    @post(\"/signup\")\n    fn signup(creds: Credentials) -> User {\n        let user = create_user(creds)\n        spawn(send_welcome_email(user.email))  // fire-and-forget tipado\n        return user\n    }\n\n\n`docker-compose.yml`:\n\n\n\n    services:\n      api:\n        build: .\n\n\nEso es todo. Un binario. Un proceso. Sin broker. Sin worker dedicado. Sin beat. El scheduler corre adentro del proceso de Fitz.\n\n##  La tabla cruda\n\nItem | Python (Celery + Redis + Beat) | Fitz\n---|---|---\nSetup inicial | 4 archivos + 3 servicios + 1 broker | 1 decorador\nSchedule |  `crontab(hour=3, minute=0)` en config | `@cron(\"0 3 * * *\")`\nTimezone | UTC + offset manual | `tz=\"America/Argentina/Buenos_Aires\"`\nRetry/backoff |  `autoretry_for=(...)` + `retry_backoff=True` | `retry={max=3, backoff=\"exponential\", initial_secs=1, max_secs=30}`\nPersistencia de runs | Redis result backend + visualización con Flower |  `store=db`, tabla auto-creada en Postgres\nCatch-up de runs perdidos | No nativo | `catch_up=true`\nBackground fire-and-forget |  `.delay(arg)` con broker |  `spawn(fn_call)` directo\nType checking de args | Ninguno (todo serializado vía JSON) | Static —`spawn` exige `@background` y refina a `Future<T>`\nProcesos en prod | api + worker + beat + redis | api\nImagen Docker | 3 (api, worker, beat) + redis | 1\n\n##  Persistencia opt-in con `store=db`\n\nCuando querés history de runs para auditoría:\n\n\n\n    @cron(\"0 3 * * *\", store=db, retry={max=3, backoff=\"exponential\"})\n    async fn cleanup_old_sessions(db: DbConn) {\n        db.exec(\"DELETE FROM sessions WHERE expires_at < now()\").await\n    }\n\n\nAl boot, Fitz crea (si no existe) `fitz_cron_jobs` y `fitz_cron_runs`. Cada attempt queda persistida con `started_at`/`finished_at`/`status`/`attempt`/`error`. Lo consultás con SQL plano:\n\n\n\n    SELECT job_name, status, attempt, error, started_at\n    FROM fitz_cron_runs\n    WHERE started_at > now() - interval '24 hours'\n    ORDER BY started_at DESC;\n\n\nSin instalar Flower. Sin webhook para Sentry. Tu DB que ya tenés.\n\n###  Catch-up\n\nSi el binario estuvo caído entre las 3 AM y las 7 AM y el cron era a las 3:\n\n  * **Celery beat** : la oportunidad se pierde. La task no se vuelve a disparar hasta la próxima medianoche siguiente.\n  * **Fitz con`catch_up=true`**: al boot, calcula que hubo un run perdido entre `last_run_at` y `now`, ejecuta UN run inmediato (no N — evita spam), y vuelve al schedule normal.\n\n\n\n\n    @cron(\"0 3 * * *\", store=db, catch_up=true)\n    async fn cleanup_old_sessions(db: DbConn) { ... }\n\n\n##  Retry con backoff configurable\n\nTres modos de backoff: `exponential` (1s, 2s, 4s, 8s...), `linear` (1s, 2s, 3s, 4s...), `constant` (1s, 1s, 1s...). Con cap `max_secs`:\n\n\n\n    @cron(\"*/10 * * * *\",\n        retry={ max=5, backoff=\"exponential\", initial_secs=1, max_secs=60 })\n    async fn sync_external_api(db: DbConn) {\n        // 1s → 2s → 4s → 8s → 16s (capeado a 60s si llegara más alto)\n    }\n\n\nEn Python con Celery:\n\n\n\n    @celery_app.task(\n        autoretry_for=(ConnectionError, TimeoutError),\n        retry_backoff=True,\n        retry_backoff_max=60,\n        retry_jitter=False,\n        max_retries=5,\n    )\n    def sync_external_api():\n        ...\n\n\nEquivalente. Pero notá que Celery tenés que enumerar las excepciones que disparan retry, y el backoff es un bool en lugar de un kind enum. Fitz hace retry ante **cualquier** error que devuelva la fn (consistente con el modelo Result del lenguaje), y el modo de backoff es explícito.\n\n##  Timezone real, no offset hardcoded\n\nLas DST changes son el bug que te despiertan a las 4 AM. Celery beat trabaja en UTC y vos tenés que recordar que entre marzo y noviembre tu cron de las 9 AM Buenos Aires se corre a las 12 UTC, pero el resto del año cambia. Tu cliente está en otro huso. Tu app vende a tres países más.\n\nFitz acepta IANA timezones directamente:\n\n\n\n    @cron(\"0 9 * * *\", tz=\"America/Argentina/Buenos_Aires\") async fn buenos_aires() { ... }\n    @cron(\"0 9 * * *\", tz=\"America/New_York\")              async fn new_york()      { ... }\n    @cron(\"0 9 * * *\", tz=\"Asia/Tokyo\")                    async fn tokyo()         { ... }\n\n\nCada uno corre a las 9 AM **local** de su tz, con DST manejado por la lib subyacente (`chrono-tz`). No conversiones a mano.\n\n##  Background jobs sin broker\n\n\n    # Python\n    @app.post(\"/signup\")\n    def signup(creds: Credentials):\n        user = create_user(creds)\n        send_welcome_email.delay(user.email)  # serializa args → Redis → worker\n        return user\n\n\n\n    // Fitz\n    @background\n    async fn send_welcome_email(email: Str) {\n        smtp.send(email, \"Welcome!\")\n    }\n\n    @post(\"/signup\")\n    fn signup(creds: Credentials) -> User {\n        let user = create_user(creds)\n        spawn(send_welcome_email(user.email))  // tokio::spawn nativo, tipado\n        return user\n    }\n\n\nEl compilador exige que la fn esté decorada con `@background` para autorizar el `spawn(...)` — sin esto, el callsite tira error de tipo en build time. Y refina el retorno a `Future<Null>` con el tipo concreto del target, no `Any`. Si `send_welcome_email` retorna `Result<()>`, el `spawn(...)` te lo da tipado.\n\n¿Cuándo NO usar `@background` y volver a Celery?\n\n  * Si necesitás que los jobs sobrevivan crashes del proceso → persistencia explícita con `store=db` cubre cron jobs; para `@background` con persistencia es deuda residual.\n  * Si necesitás distribuir jobs en N workers en N nodos → Celery con un broker compartido sigue siendo la respuesta. `@background` corre en el proceso.\n\n\n\nPara el 90% de servicios (cleanup nocturno, email transaccional, recálculo de KPIs, sync de cache) el modelo de Fitz alcanza y sobra.\n\n##  Cron-only mode para systemd\n\nPara servicios que SOLO tienen jobs (sin HTTP), `fitz build` produce un binario que arranca el scheduler y bloquea con ctrl+c:\n\n\n\n    @cron(\"0 3 * * *\") async fn cleanup() { ... }\n    @cron(\"*/15 * * * *\") async fn sync() { ... }\n\n\nComo systemd unit:\n\n\n\n    [Unit]\n    Description=Scheduled jobs for myapp\n    After=network.target\n\n    [Service]\n    ExecStart=/usr/local/bin/myapp-jobs\n    Restart=always\n    User=myapp\n\n    [Install]\n    WantedBy=multi-user.target\n\n\nCero brokers. El binario es 5 MB. `systemctl restart myapp-jobs` y listo.\n\n##  Paridad bit-a-bit `fitz run` ↔ `fitz build`\n\nEsto es lo que vuelve esto entregable: el binario que producís con `fitz build` ejecuta el mismo scheduler que `fitz run`, con el mismo cron expression parser, los mismos retries, la misma timezone. Misma sintaxis, mismas semánticas, sin \"ah esto solo funciona en producción si configurás Celery\".\n\n##  Lo que Fitz NO te da (todavía)\n\nSoy honesto sobre dónde no llega:\n\n  * **Distribuir jobs en N workers/nodos compartiendo cola**. `@cron` corre en el proceso. Si corrés dos binarios con el mismo `@cron`, ambos disparan — bug, no feature. Para horizontal scaling de jobs, sigue siendo Celery (o NATS JetStream, o Temporal). Hay deuda explícita en el roadmap sobre locks distribuidos.\n  * **UI tipo Flower**. Los datos están en `fitz_cron_jobs` y `fitz_cron_runs`. Si querés dashboards, dashboards externos (Grafana, Metabase) cubren.\n  * **`@background` con persistencia entre restarts**. Para `@cron` está en v0.11.2 (cierre 9.w.3.iter2). Para `@background` arranca el spawn pero no sobrevive crash — diferido a iter3 si entra demanda.\n  * **Cancelación de jobs en flight**. Hoy no hay API para \"cancelar todos los runs en cola de X job\". El proceso muere → los runs en flight mueren con él.\n\n\n\nSi estás en uno de esos casos, Fitz no es la herramienta hoy. Si no, el modelo de un solo binario cubre el caso real con menos partes móviles.\n\n##  Cierre\n\nEl argumento para sumar Celery a una API en Python típicamente es: \"pero después escala mejor.\" En el 90% de los servicios que escribí en la última década, ese \"después\" nunca llegó — la app pasó toda su vida útil con menos de 100 jobs por hora y nunca necesitó un cluster de workers.\n\nPara ese 90%, Fitz reemplaza 4 procesos + 3 librerías + 1 broker con un decorador. Cuando llegues al otro 10% donde necesitás scaling horizontal real, Celery sigue ahí — `from python import celery` también está disponible, podés hacerlo tú mismo.\n\nPero arrancar el proyecto con el modelo más simple posible y subir la complejidad solo cuando lo necesitás es el ciclo de feedback que Fitz quiere darte.\n\n**Próximo post de la serie** : **\"Auth con JWT, RBAC y token blacklist sin pegar 5 librerías: Fitz vs FastAPI + python-jose + passlib + Redis blacklist\"** — el flow completo de auth, lado a lado.\n\n**Repo** : github.com/Thegreekman76/fitz\n**Capítulo 30 de la guía** (Jobs sin Celery): docs/guide.md",
  "title": "Cron jobs sin Celery, sin Redis, sin Beat: cómo Fitz mete un scheduler distribuido adentro del lenguaje"
}