Hey HN - over the past few months, I’ve been working on Hatchet, which is a workflow engine meant for event-driven applications. Workflows are triggered by user-defined events (along with schedules and cron jobs). It bundles a web UI for observability and has several integrations built out (Sentry, OpenTelemetry, Slack).
It’s very similar to using an SQS + EventBridge + AWS Lambda stack, but uses worker pools to process functions instead of isolated function invocations. Some features that Hatchet offers:
1. Publish, react to, and query events using the Events API [1]
2. You can define services via `worker.NewService` which can run a set of methods. For example, you can define a `users` service which schedules user notifications, creates a user sandbox environment, processes user events, etc.
3. It’s designed to be modular, so you can plug in your own task queue implementation or event storage repository. I built it using Postgres and RabbitMQ, but would love to support better event storage via Clickhouse and other message queues.
4. Workflows are declarative, which means you define the structure of your workflow when registering them with the Hatchet engine. This means that each workflow run is predictable and executes an immutable workflow version.
It currently only supports a Go SDK but Typescript and Python are on the near-term roadmap.
Looking forward to hearing any questions or feedback you have!
[1] https://docs.hatchet.run/go-sdk/pushing-events
-being able to spec a workflow w/ Go is really nice. yaml always feel cumbersome to me, but I also don't use it regularly in my day to day.
- love that it's MIT
-the Slack use case is cool, but I'd kill for Matrix or maybe Zulip. Feels like there isn't a simple way to do this w/ the other team comm apps beyond Slack rn.
-more use-case examples in the README might be a good idea too. Workflow is an overloaded term in my head and I did struggle to figure out where I'd reach for the "hatchet" in my day to day.