gocelery VS temporal

I had a look at: 1. machinery - https://github.com/RichardKnop/machinery 2. go-celery - https://github.com/gocelery/gocelery 3. asynq - https://github.com/hibiken/asynq 3. taskq - https://github.com/vmihailenco/taskq

What about https://github.com/gocelery/gocelery ?

go-celery (https://github.com/gocelery/gocelery): Celery port in Go. Not much recent activity so a bit worried it's abandoned.

Please note that this blog post uses a Golang application (thanks to gocelery!) as an example, but the same applies to Python or any other application that uses the Celery protocol.

Just for clarification, So you can't really host this without open-sourcing my product (since your server is AGPL). Isn't it a stretch to call this really open-source? I compare this to something like a temporal which I can self-host without worrying (and which I believe is MIT license [https://github.com/temporalio/temporal/blob/main/LICENSE])

Temporal's go is... something. They used to use Java, then they switched to Go, and the Go is very Java-like.

Or maybe I just don't know Fx.

https://github.com/temporalio/temporal/blob/main/service/mat...

The issue we hit with Temporal - again and again - is that it's very under-documented, and it's something you install at the core of your business, yet it's really hard to understand what is going on, through all the layers and through the very obtuse documentation.

Maestro has... no documentation? OK Temporal wins by default.

I don't know if I agree with the argument regarding durability vs elastic execution. If I can get both (with a nice API/DX) via something like Temporal (https://github.com/temporalio/temporal), what's the drawback here?

Link to GitHub -->

However, as we mentioned, each shard needs management. Part of the management includes a cache of Workflow histories for that shard. We can see the History pods’ memory usage is rising quickly. If the pods run out of memory, Kubernetes will terminate and restart them (OOMKilled). This causes Temporal to rebalance the shards onto the remaining History pod(s), only to then rebalance again once the new History pod comes up. Each time you make a scaling change, be sure to check that all Temporal pods are still within their CPU and memory requests—pods frequently being restarted is very bad for performance! To fix this, we can bump the memory limits for the History containers. Currently, it is hard to estimate the amount of memory a History pod is going to use because the limits are not set per host, or even in MB, but rather as a number of cache entries to store. There is work to improve this: github.com/temporalio/temporal/issues/2941. For now, we’ll set the History memory limit to 8GB and keep an eye on them—we can always raise it later if we find the pod needs more.

Correct, the workflow's guarantee to always complete executing independent of hardware failures is dependent on the database not losing data. You host your workflow code with Temporal's Worker library, which talks to an instance of the Temporal Server [1], which is an open-source set of services (hosted by you or by Temporal Cloud), backed by Cassandra, MySQL, or Postgres. [2] So for instance increasing Cassandra's replication factor increases your resilience to disk failure.

[1] https://github.com/temporalio/temporal

[2] https://docs.temporal.io/clusters#persistence

Re:graph frameworks - thanks for the pointers, hadn't heard about them! I'd heard of temporal which I believe provides a similar memoization capability with the purpose of not losing work in workflows that failed partway through?

Documentation