Currently itty-durable itself (the invisible code) is not typed at all, but you can easily type your

Currently itty-durable itself (the invisible code) is not typed at all, but you can easily type your objects as you define them, then use those types throughout your worker code.

KKevin Currently itty-durable itself (the invisible code) is not typed at all, but you ...

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

For example will the return value of

COUNTER.get('myCounter').currentValue()

COUNTER.get('myCounter').currentValue()

be typed as a number if the DO method returns a number?

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

Looks like there's no typescript stuff going on, so you'd have to do something like

as ReturnType<typeof Counter.currentValue>

as ReturnType<typeof Counter.currentValue>

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

I would do something like const MyObj = DO.get(‘foo’) as MyDurableClass

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

Oh wow, that's a great idea

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

to just get the full typings at once

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

I’ve had to use that pattern at various places throughout worker code, esp as you pile on more magic… it just reconnects the types that may have been lost or difficult to drill through your app

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

I could probably even do some

Pick

Pick

magic so it only exposes router methods

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

Although looking at the code it exposes anything that

isValidMethod

isValidMethod

except for fetch

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

Yeah, I don’t think it would grab the internal itty-durable methods

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

constructor method?

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

I assume the types would refer to your own constructor, if you have one

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

I’m in the middle of a massive overhaul of itty-router, bringing CORS and extras into the main lib, so itty-durable is next for a full TS conversion at least where it matters)

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

Awesome!

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

I do wonder how the trpc approach differs. I do like that you're basically just writing functions that get passed the DO as ctx

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

And that the requests actually get validated using zod

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

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