I think just writing your DO a in full TS and casting the stub as you grab it in the Worker should s

I think just writing your DO a in full TS and casting the stub as you grab it in the Worker should still get you that… I’ll do some tests to confirm this

KKevin I think just writing your DO a in full TS and casting the stub as you grab it in...

johtso•3/9/23, 4:34 PM

I guess the only problem with this is you're still not validating, just asserting

KevinOP•3/9/23, 4:34 PM

I sometimes forget about that feature… I basically always use the methods to interact w the DO now, not awaiting direct props

johtso•3/9/23, 4:34 PM

Although I'm not sure when that might cause problems..

johtso•3/9/23, 4:35 PM

A deployment screwup where your worker doesn't get updated?

johtso•3/9/23, 4:38 PM

Oh wait.. trpc doesn't even actually do runtime validation?

KevinOP•3/9/23, 4:41 PM

If you think of a DO as a stateful object, I don’t think validation there makes much sense personally… as the real point of contact between an external source and any form of input is really at the Worker level. I’d put validation there.

johtso•3/9/23, 4:43 PM

Right I guess DOs are 2 things, a database and an api

KevinOP•3/9/23, 4:44 PM

yeah I guess so… I forget that’s the way they intended it, haha

KevinOP•3/9/23, 4:44 PM

To me the API is just the exposed classes

johtso•3/9/23, 4:44 PM

When you update a DO you have to worry about the schema of your data changing, and also the interface of your api

johtso•3/9/23, 4:45 PM

And there's potential for a worker to have a different idea of what the DO api is, if the deployments aren't perfect

KevinOP•3/9/23, 4:46 PM

yeah, for sure… migrating DOs is no joke sometimes. I usually write a temporary self-transform method, then run it across the DOs to sync them w new structure

Unsmart•3/9/23, 4:46 PM

I find DOs way easier to migrate than anything because you just do it when a request comes in

johtso•3/9/23, 4:46 PM

My goal is to never write a DO that's complicated enough for it to be a problem

UUnsmart I find DOs way easier to migrate than anything because you just do it when a req...

KevinOP•3/9/23, 4:47 PM

Totally agree, it just depends on the depth of your changes!

Jjohtso My goal is to never write a DO that's complicated enough for it to be a problem ...

KevinOP•3/9/23, 4:47 PM

Def a good goal!

johtso•3/9/23, 4:48 PM

Also if your DOs are all quite short lived that helps too

Unsmart•3/9/23, 5:10 PM

If you only do storage ops DOs use a very minimal duration

As an example I have a DO that only does storage ops... Total of 34,486,510 requests and only 83,293 GB-sec for last month

Unsmart•3/9/23, 5:12 PM

If I did my math correct thats $1 of duration charges for 34.5 million requests

UUnsmart If you only do storage ops DOs use a very minimal duration 🙂 As an example I h...

johtso•3/9/23, 5:17 PM

By short lived I mean the data is short lived

johtso•3/9/23, 5:17 PM

Like a DO representing a payment process

Unsmart•3/9/23, 5:17 PM

I see

johtso•3/9/23, 5:18 PM

So more like a function that might take a little while to complete, but needs to be durable in the case of temporary failure

UUnsmart If I did my math correct thats $1 of duration charges for 34.5 million requests

KevinOP•3/9/23, 6:49 PM

Let’s hope you did the math correctly then!

KevinOP•3/9/23, 6:53 PM

A small amount of DOs being frequently accessed seems pretty safe… the danger I’ve found is when you’re creating a LOT of DOs.

For instance, on itty.sh, I originally spun up a DO a for every entry created, just for a setAlarm to destroy it at expiration. That worked like a dream, but was gonna eat my lunch in the bill for every 128MB DO spun up. Instead, I had to create a a series of expiration managers, basically load balanced expiration DOs, each handling potentially many expirations.

KevinOP•3/9/23, 6:53 PM

so much more complex, sadly

Unsmart•3/9/23, 7:21 PM

I do 2 requests per minute per DO I have which is what the 34.5 million requests are

dctanner•3/10/23, 2:14 PM

Where is best to submit a suggestion for the docs?

dctanner•3/10/23, 2:15 PM

I couldn't find any mention of receiving SSE responses within a worker or DO, using the fetch api instead of EventSource. Eventually I found https://github.com/julienmachon/sse-client which works pretty well. It'd be nice if the docs just mentioned receiving SSE is possible in a DO.

GitHub

GitHub - julienmachon/sse-client: Server-sent event client using th...

Server-sent event client using the fetch API. Contribute to julienmachon/sse-client development by creating an account on GitHub.

dctanner•3/10/23, 2:15 PM

I'm sure you can guess what this is for.... receiving streaming ChatGPT api responses

Unsmart•3/10/23, 9:38 PM

That code base is really hard to follow, can you be more specific on where the problem is?

johtso•3/11/23, 11:28 AM

How do Workers Trace Events logs work when it comes to durable objects?

johtso•3/11/23, 12:42 PM

Does the durable objects list endpoint return in lexicographic order the same as the KV list endpoint?

johtso•3/11/23, 12:42 PM

Not mentioned in the API docs

Jjohtso Does the durable objects list endpoint return in lexicographic order the same as...

DaniFoldi•3/11/23, 1:02 PM

I believe it does, at least according to behaviour I've seen, and quoting from the docs

reverse: booleanreverse: boolean
If true, return results in descending order instead of the default ascending order.
Note that enabling this does not change the meaning of start, startKey, or endKey. start still defines the smallest key in lexicographic order that can be returned (inclusive), effectively serving as the endpoint for a reverse-order list. end still defines the largest key in lexicographic order that the list should consider (exclusive), effectively serving as the starting point for a reverse-order list.