// 01 · Service headless
Un seul binaire, pas d’UI embarquée. Votre app n’importe jamais GFire comme bibliothèque — seulement HTTP et curl.
Jobs en arrière-plan
sans bibliothèque.
GFire est un service Go headless : les apps mettent des jobs en file via HTTP, les workers lancent des binaires handlers externes, l état vit dans PostgreSQL, Redis ou ValKey. v1.0.0 — prêt pour la production : bulk enqueue, cron récurrent, métriques Prometheus, CLI et tests E2E inclus.
curl -fsSL https://get.gfire.hermesrodriguez.com/install.sh | sh
// 02 · Storage multi-backend
PostgreSQL avec SKIP LOCKED, Redis/ValKey avec BRPOP et scripts Lua. Choisissez le backend adapté.
// 03 · Scale horizontal
Nœuds pairs, storage partagé, pas de Raft. Ajoutez des pods ; coordination via le storage.
// Dernières releases
- Bulk enqueue with partial acceptance (POST /v1/jobs/enqueue/batch)
- Recurring cron jobs with distributed lock (robfig/cron)
- CLI: gfire migrate, queue list, server status
- Prometheus GET /metrics endpoint
- Idempotency-Key for client retry deduplication
- OpenAPI spec at GET /openapi.json
- E2E test: docker-compose → curl → CLI verification
- Band 7 audit hardening — request IDs, logging, metrics polish
- Server shutdown grace period and drain
- Band 3 engine — workers, retry, cancel, DLQ, result capture
- REST API and CLI available for early testing
// Comment ça marche
Notes techniques · v0.3.0 Band 2
// Band 2 — fondation storage
GFire est un service headless d’orchestration : tout client HTTP peut enfiler sans library liée à un runtime. v0.3.0 (Band 2) étend PostgreSQL Band 1 (SKIP LOCKED) avec Redis et ValKey — même interface Storage, latence de queue réduite. Moteur, API et spawn de handlers dans les bandes suivantes.
// Architecture Redis / ValKey
go-redis/v9
Un driver pour Redis et ValKey — changez l’adresse, gardez l’implémentation. Compatible forks open source et Redis managé.
BRPOP (push par blocage)
Les workers bloquent sur la file au lieu de poller. Moins de CPU et réseau ; le job réveille le worker dès son arrivée.
Scripts Lua
N nœuds GFire peer partagent le storage — pas de Raft entre pods. Lua déplace les jobs atomiquement ; intégrité dans la couche données.
Sorted sets (ZSET)
Jobs différés : score = timestamp Unix. Le scheduler ne prend que le travail dû — scale avec de gros backlogs.
// Comparaison
| Outil | Modèle | Storage | Couplage langage |
|---|---|---|---|
| GFire | HTTP / service headless | PostgreSQL, Redis, ValKey | Élevé — agnostique |
| Faktory | Protocolo / headless | Redis | Alto — protocolo TCP propio |
| Asynq | Librería Go (embebida) | Redis | Bajo — solo Go |
| River | Librería Go (embebida) | PostgreSQL | Bajo — solo Go |
| Sidekiq | Gema Ruby (embebida) | Redis | Bajo — solo Ruby |
| Celery | Librería Python (embebida) | Redis, RabbitMQ, SQL | Medio — Python primero |
GFire est standalone : enqueue via curl ou HTTP/JSON — pas de SDK dans l’app. Contrairement au TCP Faktory ou aux libs embarquées, les handlers restent des binaires externes.
// Handlers externes
GFire n’exécute pas votre logique métier in-process. Les workers dequeue et lancent un sous-processus par job (`cmd` YAML). Handlers Go, Python, Node, shell — GFire suit exit code, retries, continuations. Les handlers ne parlent pas à Redis/PostgreSQL.
Instruction cards (~1 KB)
Jobs = petits déclencheurs, pas de gros payloads. Données lourdes dans S3 ou DB ; GFire porte l’instruction. Mémoire Redis prévisible.
// Démarrage rapide
Installez le CLI et vérifiez le binaire (aujourd’hui : gfire version).
$ curl -fsSL https://get.gfire.hermesrodriguez.com/install.sh | sh $ gfire version
v1.0.0 — version stable. API REST, moteur worker et CLI complets inclus.
Jalons prévus :ROADMAP.md
// Dépôts
| Dépôt | Rôle |
|---|---|
| hrodrig/gfire | Service, backends storage, releases |
| SPECIFICATIONS.md | Contrat de comportement et design |