Cloudflare Developers•3y ago

Have a link for that?

KKevin Have a link for that?

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

https://github.com/markusahlstrand/trpc-durable-objects

GitHub

GitHub - markusahlstrand/trpc-durable-objects: A POC for using trpc...

A POC for using trpc for cloudflares durable objects - GitHub - markusahlstrand/trpc-durable-objects: A POC for using trpc for cloudflares durable objects

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

Personally I don’t love tRPC much myself, but that’s just cuz it feels boilerplatey to me… I’m sure it’s great for folks that like it!

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

Interesting how it's flipped on its head.. with this approach it creates a DO class for you based on your router

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

Where as itty-durable you define the class but subclass something

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

The example looks rather succinct

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

Haha yeah… see, that’s the part that I didn’t want to have to think about when making DOs. I only want to care about the business logic… in the case of a counter for instance, just the value and the increment. All the rest of the native DO code was noise IMO… the storage bits, fetch, internal routing, even building a request from the Worker.

KKevin Haha yeah… see, that’s the part that I didn’t want to have to think about when m...

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

Looks like this takes a similar approach, you just define a tRPC router with your business logic

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

Obviously doesn't have the persistence magic though

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

Obviously the definition isn't as minimal because you write the method input shape using a zod scheme instead of just method arguments, but that gets you type safety

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

I guess it also doesn't have the idea of querying arbitrary properties

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

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

Have a link for that?

Similar Threads

Similar Threads

Similar Threads