3 ms·

This exists, as I mentioned before, in Cloudflare's Durable Objects. You have serverless JavaScript and WebAssembly with consistent, durable, per user state. Y

This exists, as I mentioned before, in Cloudflare's Durable Objects. You have serverless JavaScript and WebAssembly with consistent, durable, per user state. You could emulate this in your language and framework of choice by loading user state at the start of the request, manipulating it in memory, and save it at the end. Like with durable objects, you’d also need to gate requests and process them one at a time to keep things consistent. A simple queue could be used to do that. It’s really not connected to async/await, you could write it synchronously or with goroutines or actors or whatever.

VikingCoder 3y ago
I'm quite certain I'm not explaining myself well. Being able to write my code as though it's synchronous is the most important aspect of this to me. Writeline("What's your first name?"); string First = await Readline(); Writeline($"Hello, {First}, what's your last name?"); string Last = await Readline(); I understand what you're saying about using a state object. But then I'm responsible for keeping track of the state machine of my code. It stops looking like async/await code, and starts looking like event-driven code again.
- slashdev 3y ago
  I don’t see the point of that. Your code won’t look like that anyway, change your example to a typical web application backend to see the problem. All you have is requests and responses. They don’t come in a predictable order. Whether you use async/await or not it’s irrelevant. Loading and restoring the state is trivial. If you just want one state object per user, you can load and save it in your framework middleware. In real life you typically need more state than just per user state, which is why it’s uncommon to see that. In the end you’ll find yourself back at the typical application server plus database architecture.

VikingCoder 3y ago

I'm quite certain I'm not explaining myself well. Being able to write my code as though it's synchronous is the most important aspect of this to me. Writeline("What's your first name?"); string First = await Readline(); Writeline($"Hello, {First}, what's your last name?"); string Last = await Readline(); I understand what you're saying about using a state object. But then I'm responsible for keeping track of the state machine of my code. It stops looking like async/await code, and starts looking like event-driven code again.

slashdev 3y ago
I don’t see the point of that. Your code won’t look like that anyway, change your example to a typical web application backend to see the problem. All you have is requests and responses. They don’t come in a predictable order. Whether you use async/await or not it’s irrelevant. Loading and restoring the state is trivial. If you just want one state object per user, you can load and save it in your framework middleware. In real life you typically need more state than just per user state, which is why it’s uncommon to see that. In the end you’ll find yourself back at the typical application server plus database architecture.