Awesome!

the set trap on a proxy can’t return a promise though, so i that await might not be doing what you expect.

it can only return true, but it can be async and await something inside... that with the fact that you can await anything (promise or not)

i'll create a single get to confirm that contents of the durable have been set... (one sec)

confirmed... setting and persisting in the durable just fine:

Where the final GET is a separate Worker route to:

sure, but if you're not awaiting a promise, those won't necessarily execute in the order you expect.

(basically since the trap always returns the value set and not a promise, you've got a race condition.)

so, yes... you're right, although in theory this would be not much of an issue... all interactions with the stub are firing fetches, and those fetches occur in-order within the durable. as long as you have a read at the end (which is also an async fetch) , it'll be reading after all the others have completed, I believe... conversely, any method (not setter) defaults to returning the JSON value of the durable as the response, so you could just use an

update(newContent)

method on your durable and update while returning response/latest-state in one fetch

so while the next line may fire, that fetch will have kicked off, and any future fetches will have to wait on the first to terminate (within the durable), unless I completely misunderstand how the execution enforcement within durables works :p

Regardless, def a good point to highlight in the docs regarding setters, then battle test with folks to see how it behaves in practice

having not looked in detail at DO code previously, what you posted above looks like what it should be like 😉

Interesting this should make graphql a lot more manageable I would assume. One question I guess is how is it saving these values on the DO? For example a basic use case of todos I would just save it to a User durable object and have the keys of each of the commands prefixed with

commands:[id]

. The I would run

list({ prefix: 'commands:' })

and I would have the list of commands normally. It seems the way you have this setup changes how that works quite a bit. Unless I am mistaken, havent yet made a DO as ive been pretty busy.

we can get something that's a bit more natural for async setters to work (e.g. https://stackoverflow.com/a/60609442/271561)

await (obj.foo = 'bar')

vs

await obj.foo('bar')

for setters

and with

await obj.foo

for async getters

Just my 2¢, I played around with basically the same thing for kv-orm, but found the awaiting a setter to unnatural and liable for bugs. TypeScript doesn't play nicely with it either. Personally, I found a repository model worked better.

js
const bookRepository = makeRepository(env.Book)

const newBook = new Book()
await bookRepository.save(newBook)

const loadedBook = await bookRepository.load(123)
const foundBook = await bookRepository.find({ title: "Hamlet" })

// etc.

Pretty cool, and I'd honestly expect to implement something like this around the DOs... but it's not like we could work "offline" on a locally-implemented instance and then just "save" the changes back to the DO while expecting it to enforce order of execution (the saves would be in-order but depending on how long an instance has been checked out, it may be from a stale origin point). I think in regards to the async setter (I'll run tests today to blast async setters at a DO and see if order is enforced), easy workaround is expose an update function or something in the DO and fire that async. Still much better that building a request from the worker, firing a fetch, putting routers (manually) in all your DOs, etc 🙂 I think we should def keep churning on this concept till we get something that solves all the gotchas! I'm just glad we have so many sharp folks here to point out the potential flaws, share their experiences, etc. Definitely a different breed of devs here!! 🤓 ❤️

Confirmed... async setters fall apart en-masse

Super helpful thread @User - that may be a pretty healthy compromise syntax (and you know... possible).

Ah that's a shame.

Yeah, good point about the stale local copy. Honestly, wasn't even considering that (kv-orm is built for KV)—I was just purely focused on the concept of saving methods. I'm guessing your stale problem is always going to be the case, unless you come up with a way of doing a transaction. E.g.

js
await with(bookRepository, 123, (book) => {
  book.title += 'abc'
})

Or something like that

Great minds 😄 I was just working on a way to do that! I may be able to track transactions within the stub, so things like setters etc just stack on a new async transaction... enforcing order. I was really hoping to send a relative setter function to the DO rather than a fixed value (result of a setter function), to help alleviate staleness issues.

Is there maybe a way to symbolize the transaction and send it to the DO to perform directly?

I think that's probably the most general solution

so I was trying something naive like fn.toString() of the setter function (to possible eval in the DO), but wasn't quite sure how to first resolve vars (that can be resolved) so they don't throw inside the DO where they clearly don't exist...

Straight up eval in Workers is impossible. But I can't see why we couldn't make a little little grammar ourselves? Haven't tried it before.

prob for the best (impossible to eval), haha - it felt dirty/scary even suggesting it

Quick Google found this: https://docs.symbolplatform.com/getting-started/first-application.html Which has

js

const transferTransaction = TransferTransaction.create(
  Deadline.create(epochAdjustment),
  recipientAddress,
  [new Mosaic(mosaicId, UInt64.fromUint(1))],
  PlainMessage.create('enjoy your ticket'),
  networkType,
  UInt64.fromUint(2000000),
);

https://github.com/nemtech/symbol-sdk-typescript-javascript/blob/main/src/infrastructure/transaction/SerializeTransactionToJSON.ts