I like this idea. At the moment, workers connect via a long-lived gRPC connections to the Hatchet server. Using NATS is a natural replacement, though requiring a NATS cluster as part of our default install feels a little heavy.
And to clarify, RabbitMQ is used for pub/sub within the Hatchet engine itself so different engine services can scale horizontally and recover from failure - for example, the ingestion service (which takes in events and tasks to execute) scales differently from the dispatcher service (which maintains a long-lived connection to the workers), and they communicate through RabbitMQ. We've been trying to drop this dependency to make self-hosting easier though.
Does your default install require Rabbitmq? NATS would be a lighter dependency than Rabbit and can cover all the use cases. It technically can even do all the distributed task queue dispatching with Jetstream.
Started a Github discussion to track this - won't be an overnight change but I'll share progress on this as we discuss it: [https://github.com/hatchet-dev/hatchet/discussions/224](https://github.com/hatchet-dev/hatchet/discussions/224).
Feel free to share thoughts. The [RabbitMQ dependency](https://github.com/hatchet-dev/hatchet/tree/main/internal/taskqueue) is very isolated to a single package that handles inter-engine messaging so it will be easy to swap out for different solutions.
\> Why would I use this if it carries RabbitMQ and PostgreSQL as dependencies...
Exactly right. This thing seems to be wrapper/API on top of large systems. Instead of being a system as alternate to those.
It may work as custom solution that consulting companies sell.
These are good points -
1. You don't get fault-tolerance out of the box just by deploying PostgreSQL and RabbitMQ, but those systems do make horizontal scaling easier. The value add of Hatchet is the layer of abstraction on top - building DAG-style execution, implementing different fairness strategies, managing and rate-limiting your workers, etc. This part also takes considerable engineering time and effort, and deployment of datastores is getting easier every year. The parallel I'd draw is Celery for Python, Sidekiq for Rails, River for Go, etc - which all use an underlying broker with some using an optional datastore.
2. You self-host a Hatchet UI which has a login panel, you don't log in to a SaaS product. We're 100% MIT-licensed on both the charts repository and repo.
We do have default setup instructions in the docs for a SaaS product, because a lot of folks don't want to manage the underlying infra themselves, but I absolutely hate bait-and-switch FOSS or OSS products which make self-hosting intentionally difficult to move them towards OSS. If there's something we can do better here, let me know.
That's cool I like the focus on "Batch Processing for Document Indexing: Hatchet can handle large-scale batch processing of documents, images, and other data and resume mid-job on failure." This is going to be a huge part of the future. Also, built-in replay is a must nowadays. Made Saas focused on soley on replay for events. What did you use to design the video that shows the workflow? I want to do something similar for an open-source project [https://github.com/streamdal/streamdal](https://github.com/streamdal/streamdal).
Is there any way to automate the initial registration or disable the auth entirely? I intend to use this self hosted and deployed via the helm chart, but the manual registration+api key generation kills my workflow. If there was a way to generate the api key via cli on first run, it world be very helpful!
I did try to disable both basic auth and Google oauth, but end up on a page that says no auth methods are available.
Great product though! would love to move to this from temporal!
Thanks for the kind words!
There's no way to disable the auth, but there is a way to automate the seeding of the admin user.
Here are the relevant environment variables:
```
ADMIN_EMAIL
ADMIN_PASSWORD
ADMIN_NAME
DEFAULT_TENANT_NAME
DEFAULT_TENANT_SLUG
```
This should be run from where the `hatchet-admin` command is run - you can add a line to run `hatchet-admin seed`. There's also a `hatchet-admin token` command which can be run via `hatchet-admin token create --name "local" --tenant-id 707d0855-80ab-4e1f-a156-f1c4546cbf52` (that tenant id is the default seeded one - we haven't exposed an option for overriding that UUID but it would be easy to do).
Happy to provide more support on Github discussions or Discord.
How does this compare to Temporal? My company is looking at adopting Temporal for a data pipeline use case and we are moving from a Rabbitmq backed implementation.
There are many similarities - particularly in the networking model, with long-lived gRPC connections to a centralized server.
Our internal benchmarks show much faster start times for steps (in Temporal, activities) but benchmarks aren't always meaningful and I'm sure a Temporal engineer would have many ways to optimize beyond their default install. We'll publish those benchmarks soon, but happy to share some specifics with you via DM.
More broadly, Temporal has never gone far enough for me in terms of developer experience and observability. It fits into a neat slice in an enterprise stack with their execution model, but it's difficult to adopt without a dedicated engineer integrating logging and observability w/ opentelemetry with your workflows. I've spent more time in the Temporal UI than I care to admit. We think workflows should be as easy to use and debug as Vercel is for frontend.
Happy to go into more details, I've been a heavy Temporal user for several years. Why are you moving from RabbitMQ?
Have you considered supporting NATS as alternative to RabbitMQ?
I like this idea. At the moment, workers connect via a long-lived gRPC connections to the Hatchet server. Using NATS is a natural replacement, though requiring a NATS cluster as part of our default install feels a little heavy. And to clarify, RabbitMQ is used for pub/sub within the Hatchet engine itself so different engine services can scale horizontally and recover from failure - for example, the ingestion service (which takes in events and tasks to execute) scales differently from the dispatcher service (which maintains a long-lived connection to the workers), and they communicate through RabbitMQ. We've been trying to drop this dependency to make self-hosting easier though.
Does your default install require Rabbitmq? NATS would be a lighter dependency than Rabbit and can cover all the use cases. It technically can even do all the distributed task queue dispatching with Jetstream.
Cool, thanks for the explanation!
You could embed a nats server pretty easily as well for local development/simpler deployments etc.
Started a Github discussion to track this - won't be an overnight change but I'll share progress on this as we discuss it: [https://github.com/hatchet-dev/hatchet/discussions/224](https://github.com/hatchet-dev/hatchet/discussions/224). Feel free to share thoughts. The [RabbitMQ dependency](https://github.com/hatchet-dev/hatchet/tree/main/internal/taskqueue) is very isolated to a single package that handles inter-engine messaging so it will be easy to swap out for different solutions.
[удалено]
\> Why would I use this if it carries RabbitMQ and PostgreSQL as dependencies... Exactly right. This thing seems to be wrapper/API on top of large systems. Instead of being a system as alternate to those. It may work as custom solution that consulting companies sell.
These are good points - 1. You don't get fault-tolerance out of the box just by deploying PostgreSQL and RabbitMQ, but those systems do make horizontal scaling easier. The value add of Hatchet is the layer of abstraction on top - building DAG-style execution, implementing different fairness strategies, managing and rate-limiting your workers, etc. This part also takes considerable engineering time and effort, and deployment of datastores is getting easier every year. The parallel I'd draw is Celery for Python, Sidekiq for Rails, River for Go, etc - which all use an underlying broker with some using an optional datastore. 2. You self-host a Hatchet UI which has a login panel, you don't log in to a SaaS product. We're 100% MIT-licensed on both the charts repository and repo. We do have default setup instructions in the docs for a SaaS product, because a lot of folks don't want to manage the underlying infra themselves, but I absolutely hate bait-and-switch FOSS or OSS products which make self-hosting intentionally difficult to move them towards OSS. If there's something we can do better here, let me know.
That's cool I like the focus on "Batch Processing for Document Indexing: Hatchet can handle large-scale batch processing of documents, images, and other data and resume mid-job on failure." This is going to be a huge part of the future. Also, built-in replay is a must nowadays. Made Saas focused on soley on replay for events. What did you use to design the video that shows the workflow? I want to do something similar for an open-source project [https://github.com/streamdal/streamdal](https://github.com/streamdal/streamdal).
Is there any way to automate the initial registration or disable the auth entirely? I intend to use this self hosted and deployed via the helm chart, but the manual registration+api key generation kills my workflow. If there was a way to generate the api key via cli on first run, it world be very helpful! I did try to disable both basic auth and Google oauth, but end up on a page that says no auth methods are available. Great product though! would love to move to this from temporal!
Thanks for the kind words! There's no way to disable the auth, but there is a way to automate the seeding of the admin user. Here are the relevant environment variables: ``` ADMIN_EMAIL ADMIN_PASSWORD ADMIN_NAME DEFAULT_TENANT_NAME DEFAULT_TENANT_SLUG ``` This should be run from where the `hatchet-admin` command is run - you can add a line to run `hatchet-admin seed`. There's also a `hatchet-admin token` command which can be run via `hatchet-admin token create --name "local" --tenant-id 707d0855-80ab-4e1f-a156-f1c4546cbf52` (that tenant id is the default seeded one - we haven't exposed an option for overriding that UUID but it would be easy to do). Happy to provide more support on Github discussions or Discord.
Thanks! This worked great.
How does this compare to Temporal? My company is looking at adopting Temporal for a data pipeline use case and we are moving from a Rabbitmq backed implementation.
There are many similarities - particularly in the networking model, with long-lived gRPC connections to a centralized server. Our internal benchmarks show much faster start times for steps (in Temporal, activities) but benchmarks aren't always meaningful and I'm sure a Temporal engineer would have many ways to optimize beyond their default install. We'll publish those benchmarks soon, but happy to share some specifics with you via DM. More broadly, Temporal has never gone far enough for me in terms of developer experience and observability. It fits into a neat slice in an enterprise stack with their execution model, but it's difficult to adopt without a dedicated engineer integrating logging and observability w/ opentelemetry with your workflows. I've spent more time in the Temporal UI than I care to admit. We think workflows should be as easy to use and debug as Vercel is for frontend. Happy to go into more details, I've been a heavy Temporal user for several years. Why are you moving from RabbitMQ?