Cloudflare Developers•3y ago

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

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...

Kevin•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 ...

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

Def a good goal!

johtsoOP•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...

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

By short lived I mean the data is short lived

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

Like a DO representing a payment process

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

I see

johtsoOP•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

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

Let’s hope you did the math correctly then!

Kevin•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.

Kevin•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?

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

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

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

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

johtsoOP•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: boolean
reverse: 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.