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

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

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.

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

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

To me the API is just the exposed classes

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

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

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

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

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

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

Def a good goal!

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

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

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

By short lived I mean the data is short lived

Like a DO representing a payment process

I see

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

Let’s hope you did the math correctly then! 😅

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.

so much more complex, sadly

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

Hey team! What is the expected latency for a read and write to DO using wrangler POST api?

Where is best to submit a suggestion for the docs?

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.

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

Making an issue on the docs repo is generally the place

I am trying to create a auth system using DO. but the response time is around ~1.5s. Can you help me with suggestions to improve? Right now I have 3 DOs. Both talking to each other using internal fetch call in worker. 1. App 2. User 3. Token https://github.com/subhendukundu/authc1-do