3 ms·
I like the concept. The nice things is that it abstract the conditions checks on whether something is done, has succeeded or should be retried. The bad things
by BiteCode_dev 2y ago
I like the concept.
The nice things is that it abstract the conditions checks on whether something is done, has succeeded or should be retried.
The bad things is that it abstract the conditions checks on whether something is done, has succeeded or should be retried.
It's nice because that's something you do again and again, and that's a lot of code. A lot of ways it can go wrong.
But it's bad because that's a huge chunk of black box magic that may execute remotely. If you need a custom or more optimized behavior anywhere in this logic, you are done for. If there is a bug/problem in this logic, it's game over. I also have to imagine debugging and error reporting is likely not super fun.
One point in particular that strikes me, is that impotence is generically guaranteed with something like "has this task executed without error last time". But usually, what I want is something much more specific, like "has that entries been updated", "has that file been created" and so on. From a bird view, it looks the same, but from a system reliability point of you, they are not at all the same.
Hard to see how they avoid duplicate results, overlapping tasks, etc.
I don't think they really can at that level of abstraction, which means you need to implement it manually.
Eventually it seems it's a huge dep to bring in for the actual practical problem is really solves well.
But I'm willing to be proven wrong on this one, because the tech is really damn cool.