I don’t consider the sleep and auto retry features that interesting, but definitely nice to have.
The advantages to me are the the ability to easily have long-lived “workflows” that are written in the language of your choice (5 SDKs the moment), remove the need for storing state in your application database (even remove the need for a database all together for some services), handle the rough edges around distributed concurrency, and provide out of the box visibility into workflow states.
It does seem like it would be overkill for simple use cases, but with the SaaS offering being so compelling IMHO, I think it can make sense to put smaller use cases there if there is a chance of more use cases in the future.
It does sound like you have more production experience with temporal than me though, so please push back if my glasses are a bit rosey
I do definitely think temporal is a good product, and I hope my original comment didn’t come across as overly negative. I also only have production experience with the go sdk, so maybe some of the pain points are less relevant in other languages. The main thing is that in order to accomplish all of the things it does, using temporal effectively adds a second runtime to your application. A runtime that most developers in your language of choice are not familiar with and, at least in my experience, has a fraction of the documentation.
I’d still definitely recommend temporal if your use-case involves long running workflows. I’ve just seen a decent number of developers viewing temporal as some sort of silver bullet but, as always, there are trade offs.
The advantages to me are the the ability to easily have long-lived “workflows” that are written in the language of your choice (5 SDKs the moment), remove the need for storing state in your application database (even remove the need for a database all together for some services), handle the rough edges around distributed concurrency, and provide out of the box visibility into workflow states.
It does seem like it would be overkill for simple use cases, but with the SaaS offering being so compelling IMHO, I think it can make sense to put smaller use cases there if there is a chance of more use cases in the future.
It does sound like you have more production experience with temporal than me though, so please push back if my glasses are a bit rosey