The good thing about us is that you don't need to learn about events, subscribers, backoffs, idempotency etc. Instead, you write a single line and can deploy reliable event-driven functions to any provider, even at the edge. Most people are afraid of tackling event-driven architectures because it's too hard to set up, debug, build, make reliable, deploy - all the standard stuff that's frustrating.
When I say durable, I mean:
- Functions get their own state, retries, idempotency, throttling, etc.
- You can create steps within functions which have their own retries, similar to Temporal
- You can eg `sleep`, `sleepUntil` within a serverless function to handle queues or delayed jobs
- You can `waitForEvent` within functions to wait for other events which match arbitrary expressions. This lets you do magic things like "when a user adds something to their cart, wait for the checkout event from this user for 1 day. If the event is null/not received, send a reminder email". This is hard to do out of the box, but with us it's built in and takes a single line of code.
- We also store each event so you can do things like local replay, event versioning, schema management & governance, etc.
When you mention "distributed transactions", there's many ways to go. For us, we're working on CDC so that you can atomically react to actual DB transactions. For everything else, durability and retries becomes important.
There's a *lot* to talk about here. I'd love to discuss more in depth - shoot me an email if it's of interest! :)