// 01 · Serviço headless
Um binário, sem UI embutida. Sua app nunca importa GFire como biblioteca — só HTTP e curl.
Jobs em background
sem biblioteca.
GFire é um serviço Go headless: apps enfileiram trabalho via HTTP, workers executam binários handlers externos, estado vive em PostgreSQL, Redis ou ValKey. v1.0.0 — pronto para produção: bulk enqueue, cron recorrente, métricas Prometheus, CLI e testes E2E incluídos.
curl -fsSL https://get.gfire.hermesrodriguez.com/install.sh | sh
// 02 · Storage multi-backend
PostgreSQL com SKIP LOCKED, Redis/ValKey com BRPOP e scripts Lua. Escolha o backend do seu stack.
// 03 · Escala horizontal
Nós peer, storage compartilhado, sem Raft. Adicione pods; coordenação via storage.
// Releases recentes
- 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
// Como funciona
Notas técnicas · v1.0.0
// Orquestração pronta para produção
GFire é um serviço headless de orquestração: qualquer cliente HTTP enfileira sem library atada a runtime. v1.0.0 entrega o stack completo — backends PostgreSQL (SKIP LOCKED), Redis e ValKey, API REST com bulk enqueue e chaves de idempotência, jobs cron recorrentes com distributed locks, CLI, métricas Prometheus e suite E2E. Agnóstico por design; handlers são binários externos.
// Arquitetura Redis / ValKey
go-redis/v9
Um driver para Redis e ValKey — troque o endereço, mesma implementação. Compatível com forks open source e Redis gerenciado.
BRPOP (push por bloqueio)
Workers bloqueiam na fila em vez de polling. Menos CPU e rede; o job acorda o worker na chegada.
Scripts Lua
N nós GFire peer compartilham storage — sem Raft entre pods. Lua move jobs atomicamente; integridade na camada de dados.
Sorted sets (ZSET)
Jobs adiados usam score = timestamp Unix. Scheduler só puxa trabalho vencido — escala com backlogs grandes.
// Comparativo
| Ferramenta | Modelo | Storage | Acoplamento |
|---|---|---|---|
| GFire | HTTP / serviço 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 é standalone: enqueue com curl ou HTTP/JSON — sem SDK na app. Diferente do TCP do Faktory ou libs embarcadas, handlers são binários externos.
// Handlers externos
GFire não executa sua lógica in-process. Workers fazem dequeue e spawnam subprocesso por job (`cmd` no YAML). Handlers Go, Python, Node, shell — GFire rastreia exit, retries, continuations. Handlers não falam com Redis/PostgreSQL.
Instruction cards (~1 KB)
Jobs são gatilhos pequenos, não payloads pesados. Dados grandes em S3 ou DB; GFire carrega a instrução. Memória Redis previsível.
// Início rápido
Instale o CLI e verifique o binário (hoje: gfire version).
$ curl -fsSL https://get.gfire.hermesrodriguez.com/install.sh | sh $ gfire version
v1.0.0 — release estável. API REST, worker engine e CLI completos.
Marcos planejados:ROADMAP.md
// Repositórios
| Repo | Papel |
|---|---|
| hrodrig/gfire | Serviço, backends de storage, releases |
| SPECIFICATIONS.md | Contrato de comportamento e design |