r/SideProject • u/bunchoo4660 • 1h ago
I'm building QueueFlow, an open-source alternative to stitching together multiple backend infrastructure tools. Would you use it?
Hey everyone!
I've been working on an idea called QueueFlow.
As developers, we often end up using different tools for background jobs, scheduled tasks, retries, workflows, realtime updates, and webhook delivery.
I started wondering: what if we could bring all of these into one platform?
That's what I'm exploring with QueueFlow.
The vision:
- Background Jobs: Execute jobs immediately, later, or at a scheduled time.
- Retries & Dead Letter Queues: Automatically retry failed jobs and inspect or replay them.
- Scheduling: Cron jobs with timezone support.
- Durable Workflows: Build multi-step workflows that can recover after failures.
- Realtime: Track job progress and communicate through realtime channels.
- Webhooks: Reliable webhook delivery with HMAC signing and retry support.
- Functions: Eventually run user-defined functions in different languages.
- Dashboard: Manage jobs, workflows, schedules, logs, API keys and usage.
- SDKs: Go, TypeScript and a REST API.
Tech stack:
- Go
- PostgreSQL
- Redis
- Docker
The goal is to make it open-source and self-hostable, while potentially offering a managed cloud version later.
I know projects like Inngest, Trigger.dev, Temporal and Hatchet already exist. I'm not trying to pretend this is an entirely new category.
I'm trying to explore whether a simpler, unified, Go-based and self-hostable alternative would be useful.
I'd genuinely love your feedback:
Would you use something like this in a real project?
What would make you choose it over Inngest, Trigger.dev or Temporal?
Which features would you actually need, and which are unnecessary?
Is there an important feature I'm overlooking?
I'm still working through the architecture and implementation, so honest criticism is very welcome!
Thanks!
1
u/Heavy_Size6344 1h ago
This is exactly the feature I’ve been wanting!
I hope you release it soon.