seeing a lot of ad hominem comments on a16z and think that's a pretty low quality response - let's try to respect HN guidelines and discuss the substance of the article? this is an emerging space and we all lack the language to adequately describe it, so cut them a little slack there if the chosen terminology doesnt connect at first.
> "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
> (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.
> 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
Thanks swyx again for sharing your insight in this space.
I closely followed your work while you were at Temporal. "React for Backend" resonated with what I experienced while building couple of systems in the backend!
It's been a year or two since then, and I'm frankly surprised that Temoporal-like services don't appear that mainstream. At least in my small circle friends, orchestration framework is still in the "early adopter" stage of innovation.
Any recent take on the adoption of Temporal-like frameworks? Do you still believe it will have a React like moment in the future?
> I'm frankly surprised that Temoporal-like services don't appear that mainstream. At least in my small circle friends, orchestration framework is still in the "early adopter" stage of innovation.
yup and the problem is in both demand and supply. it is still too difficult to get up and running (whether with temporal or orkes or other) and also not enough developers realize the business value of/(difficulty of doing well) doing long running async work (i tried to communicate that in all my temporal intros, but getting devs to care about what code has abnormal biz value is surprisingly difficult, only a minority look at code like that).
further - choreography (as referenced in my article) will always be simpler to start with than orchestration, so many people will start there first and basically stop there. so the activation energy to feel the pain is nonzero.
that said, we have evidence that app developers will eventually be convinced to overcome learning curves and shift work left, with typescript released in 2012 but only "winning" in 2018-19. there was no React "moment", it grew and grew through the work and advocacy of a small group of believers and the fortunate self immolation of Angular 2
Thanks - just reading the article that you linked to above on your website. It seems like a very similar concept to state machines; can you help me wrap my head around how this might play with something like xstate or that concept?
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