as someone who has worked in this space (https://www.swyx.io/why-temporal), here's a few quick responses:
> "We’re seeing the emergence of systems that extend strong transactional guarantees beyond the database, into the distributed apps themselves."
yes absolutely. but its not just transactions, but also the ability to route/distribute work, and "self provision" (https://www.swyx.io/self-provisioning-runtime) queues and timers and new application states (unconstrained by preset DAG) as you code
> a giant hairball of queues and retry logic is too brittle
my favorite img on how this looks (on a real diagram, from a real aws blogpost) https://twitter.com/swyx/status/1423025792783568899
> (temporal) will ensure the code runs to completion, even during a failure.
i'd correct to "transient failure" (eg due to network or uptime issues). retries cant solve application logic issues and mostly fatten the tail of timeout failures that still need to be dealt with. fault tolerant code is a much better default, but there's no totally-free lunch here.
> The downside is that it (temporal) often requires a lot of integration work and wrapper code to expose useful and safe interfaces to application developers.
yes (example https://temporal.io/blog/why-rust-powers-core-sdk) - but there are lots of higher level systems built atop temporal (eg https://news.ycombinator.com/item?id=34686216 and https://www.youtube.com/watch?v=M25p1cgjM2U&list=PLl9kRkvFJr...) but this is also how netflix/stripe/etc are able to customize it for their stack and encode their opinions in a way that the other alternatives mentioned would not be able to
> The other approach, which is more popular with application developers (particularly Typescript/Javascript) is for the workflow engine to serve as an orchestrator of async functions (e.g. Inngest, Defer, and Trigger)... (truncated)
lest i sound like a pure temporal shill, i also agree that this is an attractive model for fullstack web developers (as opposed to say backend/systems devs). this is why i got excited about Defer enough to review it (https://www.youtube.com/watch?v=iGccpHaB1hA)
> Database-centric approaches start with a database, but extend it to support arbitrary code execution to allow for workflows alongside data management.
i've always used the analogy that workflow systems are "stored procedures on steroids". glad to see some signals that Convex (and Supabase?) have plans to make this available to their users. i think there'll be happy users of either approach, but personally am doubtful that the DB-centric approach will take significant share simply because 1) this stuff is not existential for them while it is for the workflow companies, so they will probably lag behind in features, investment, product/GTM focus, and 2), workflow systems easily bridge multiple systems and databases while the db-centric approach is necessarily limited to the system that db lives in. if you have a real microservices setup instead of a distributed monolith, its pretty obvious which approach will win here