// 01 · Headless-Service
Ein Binary, keine eingebettete UI. Ihre App importiert GFire nie als Library — nur HTTP und curl.
Background-Jobs
ohne Library.
GFire ist ein headless Go-Service: Apps stellen Jobs per HTTP ein, Worker starten externe Handler-Binaries, State liegt in PostgreSQL, Redis oder ValKey. v1.0.0 — produktionsreif: Bulk-Enqueue, Cron-Jobs, Prometheus-Metriken, CLI und E2E-Tests enthalten.
curl -fsSL https://get.gfire.hermesrodriguez.com/install.sh | sh
// 02 · Multi-Backend-Storage
PostgreSQL mit SKIP LOCKED, Redis/ValKey mit BRPOP und Lua-Skripten. Wählen Sie das passende Backend.
// 03 · Horizontale Skalierung
Peer-Knoten, gemeinsamer Storage, kein Raft. Pods hinzufügen; Koordination über Storage.
// Aktuelle 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
// So funktioniert es
Technische Notizen · v1.0.0
// Produktionsreife Job-Orchestrierung
GFire ist ein headless Job-Orchestrierungsdienst: jeder HTTP-Client kann Jobs einstellen ohne runtime-spezifische Library. v1.0.0 liefert den vollständigen Stack — PostgreSQL (SKIP LOCKED), Redis und ValKey Backends, REST-API mit Bulk-Enqueue und Idempotency-Keys, wiederkehrende Cron-Jobs mit Distributed Locks, CLI, Prometheus-Metriken und E2E-Testsuite. Sprachagnostisch; Handler sind externe Binaries.
// Redis- / ValKey-Architektur
go-redis/v9
Ein Treiber für Redis und ValKey — Adresse tauschen, Implementierung bleibt. Kompatibel mit Open-Source-Forks und Managed Redis.
BRPOP (Push per Blockierung)
Worker blockieren an der Queue statt zu pollen. Weniger CPU und Netzwerk; Jobs wecken Worker sofort.
Lua-Skripte
N GFire-Peer-Knoten teilen Storage — kein Raft zwischen Pods. Lua verschiebt Jobs atomar (z. B. enqueued → processing); Race-Freiheit in der Datenschicht.
Sorted Sets (ZSET)
Verzögerte Jobs nutzen Scores = Unix-Timestamps. Scheduler holt nur fällige Arbeit — skaliert bei großen Backlogs.
// Vergleich
| Tool | Modell | Storage | Sprachkopplung |
|---|---|---|---|
| GFire | HTTP / servicio headless | PostgreSQL, Redis, ValKey | Alto — agnóstico |
| 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 ist standalone und sidecar-ready: einreihen per curl oder HTTP/JSON — kein SDK in der App. Anders als Faktory-TCP oder eingebettete Libraries bleiben Handler externe Binaries.
// Externe Handler
GFire führt Ihre Geschäftslogik nicht in-process aus. Worker dequeueen und starten ein Subprocess pro Job (`cmd` in YAML). Handler in Go, Python, Node, Shell — GFire überwacht Exit-Code, Retries, Continuations. Handler sprechen nicht direkt mit Redis/PostgreSQL.
Instruction Cards (~1 KB)
Jobs sind kleine Trigger, keine schweren Payloads. Große Daten in S3 oder DB; GFire transportiert die Anweisung. Vorhersagbarer Redis-Speicher.
// Schnellstart
CLI installieren und Binary prüfen (heute: gfire version).
$ curl -fsSL https://get.gfire.hermesrodriguez.com/install.sh | sh $ gfire version
v1.0.0 — stabiles Release. Vollständige REST-API, Worker-Engine und CLI enthalten.
Geplante Meilensteine:ROADMAP.md
// Repositories
| Repo | Rolle |
|---|---|
| hrodrig/gfire | Service, Storage-Backends, Releases |
| SPECIFICATIONS.md | Verhaltensvertrag und Design |