I wish they had talked more about the implementation, this is a cool abstraction, but how are durable promises persisted? Is this just abstracting away a job queue, because you are still saying when something can come up and say "are there any pending charges that need permission" that implies some kind of queue of awaiting promises to be fulfilled. It seems like for example 2, you could just enqueue the permission granting onto a job queue as part of the charge operation and then perform it locally for performance, and if anything picks up the permission granting event it will just no-op due to idempotency. I assume there is some kind of distributed lock for the event so you don't have both the local and remote execution happening at the same time as well.
i think its like a runtime to orchestrate the whole main executing process, and it runs parallel worker processes for each of the sub functions that is going to emit some events, and the orchestrator basically acts as a bridge to communicate the events in the sequential flow defined for the main executing process. so basically there is no actual processing/execution of any business logic in the resonate runtime but in their own isolated systems. resonate just coordinates the passing of events in the sequential flow defined in the main process while each of the event emiting function executes on their own isolated system and the main process also runs in its own isolated system , this is what i think is happening....
Hey, I'm happy you like the abstractions. I have a P99 Conf presentation coming up where I talk more about the implementation in case you are interested. tl;dr You are correct, the heart of the distributed async await programming model is a distributed event loop, in essence, a job queue
hey @@dominiktornow1052 , just a question , is resonate like a lightweight orchestration engine/runtime that can be used for general purpose applications with async func calls to add extra features on these async func calls like retries , schedulars, etc without the developer needing to write any logic for these extra features but resonate will handle all this so basically by wrapping a single main func with multiple async sub func calls with resonate , we make this main func very reliable and durable ?
Thanks for the talk! At 30:12 you pose a question that I find interesting. Given we need the functions that charge a credit card and grant access to a user to be idempotent, what's the difference between a durable execution and a simple background job that retries until it's completed?
BTW, even if your functions are idempotent, the composition of your functions may not be correct under retry. Resonate implements deterministic simulation testing for your workflows so you can make sure your resulting application is correct
I feel like it tries to abstract events but there is still a high coupling to events, so what happens if you have an event with multiple handlers ? Which have their own lifecycles ? Plus, you now have to deal with this context everywhere, mixing business logic with technical concern occupying some parts of your mind. And you change your mental model from a stack to a corroutine. I guess that one is kind of the point. My developer experience is pretty good with event driven, so i don't feel his pain ... Yet. I guess I'd be more at ease with automatic schemas but still.
Resonate and Temporal both implement Durable Executions. Resonate's main goal－and the core of our technical values－is being dead simple. That starts with a dead simple programming model, based on two abstraction, functions and promises, that is dead simple to understand and extends to a dead simple developer experience and a dead simple operational experience. Achieving this level of simplicity is challenging, but that's where we spend all our energy
I was at Temporal for 2 years before founding Resonate. I'll copy a reply from before: Resonate and Temporal both implement Durable Executions. Resonate's main goal－and the core of our technical values－is being dead simple. That starts with a dead simple programming model, based on two abstraction, functions and promises, that is dead simple to understand and extends to a dead simple developer experience and a dead simple operational experience. Achieving this level of simplicity is challenging, but that's where we spend all our energy.
@@dominiktornow1052 thanks for the clarification. I used temporal io before once, really liked it, but it did take me a day to understand what its doing overall, now after going through parts of resonate docs, i totally agree, the abstractions for resonate is way more developer friendly to both understand and use , so yeah dead simple for sure, i really like this. Hoping to somehow convince my startup to use resonate soon 😅
based frieren enjoyer
I wish they had talked more about the implementation, this is a cool abstraction, but how are durable promises persisted? Is this just abstracting away a job queue, because you are still saying when something can come up and say "are there any pending charges that need permission" that implies some kind of queue of awaiting promises to be fulfilled.
It seems like for example 2, you could just enqueue the permission granting onto a job queue as part of the charge operation and then perform it locally for performance, and if anything picks up the permission granting event it will just no-op due to idempotency. I assume there is some kind of distributed lock for the event so you don't have both the local and remote execution happening at the same time as well.
i think its like a runtime to orchestrate the whole main executing process, and it runs parallel worker processes for each of the sub functions that is going to emit some events, and the orchestrator basically acts as a bridge to communicate the events in the sequential flow defined for the main executing process. so basically there is no actual processing/execution of any business logic in the resonate runtime but in their own isolated systems.
resonate just coordinates the passing of events in the sequential flow defined in the main process while each of the event emiting function executes on their own isolated system and the main process also runs in its own isolated system , this is what i think is happening....
@@wdvhi sounds a lot like airflow with a different API.
@@cowshrptrn yep , architecture wise, but this is general purpose kind of framework you can use for any kind of systems
Hey, I'm happy you like the abstractions. I have a P99 Conf presentation coming up where I talk more about the implementation in case you are interested. tl;dr You are correct, the heart of the distributed async await programming model is a distributed event loop, in essence, a job queue
hey @@dominiktornow1052 , just a question ,
is resonate like a lightweight orchestration engine/runtime that can be used for general purpose applications with async func calls to add extra features on these async func calls like retries , schedulars, etc without the developer needing to write any logic for these extra features but resonate will handle all this
so basically by wrapping a single main func with multiple async sub func calls with resonate , we make this main func very reliable and durable ?
Thanks for the talk! At 30:12 you pose a question that I find interesting. Given we need the functions that charge a credit card and grant access to a user to be idempotent, what's the difference between a durable execution and a simple background job that retries until it's completed?
BTW, even if your functions are idempotent, the composition of your functions may not be correct under retry. Resonate implements deterministic simulation testing for your workflows so you can make sure your resulting application is correct
I feel like it tries to abstract events but there is still a high coupling to events, so what happens if you have an event with multiple handlers ? Which have their own lifecycles ?
Plus, you now have to deal with this context everywhere, mixing business logic with technical concern occupying some parts of your mind.
And you change your mental model from a stack to a corroutine. I guess that one is kind of the point.
My developer experience is pretty good with event driven, so i don't feel his pain ... Yet. I guess I'd be more at ease with automatic schemas but still.
Cool stuff. What are the advantages over Temporal? It looks similar!
I think the workflow stuff at the start is a reference to something like Temporal?
Resonate and Temporal both implement Durable Executions. Resonate's main goal－and the core of our technical values－is being dead simple. That starts with a dead simple programming model, based on two abstraction, functions and promises, that is dead simple to understand and extends to a dead simple developer experience and a dead simple operational experience. Achieving this level of simplicity is challenging, but that's where we spend all our energy
is this similar to temporal io ? if i remember , dominik is also part of temporal io right ?
I was at Temporal for 2 years before founding Resonate. I'll copy a reply from before: Resonate and Temporal both implement Durable Executions. Resonate's main goal－and the core of our technical values－is being dead simple. That starts with a dead simple programming model, based on two abstraction, functions and promises, that is dead simple to understand and extends to a dead simple developer experience and a dead simple operational experience. Achieving this level of simplicity is challenging, but that's where we spend all our energy.
@@dominiktornow1052 thanks for the clarification.
I used temporal io before once, really liked it, but it did take me a day to understand what its doing overall, now after going through parts of resonate docs, i totally agree, the abstractions for resonate is way more developer friendly to both understand and use , so yeah dead simple for sure, i really like this. Hoping to somehow convince my startup to use resonate soon 😅