can you test a durable object locally without running workerd? perhaps just a plain JS implementatio
can you test a durable object locally without running workerd? perhaps just a plain JS implementation of the parent DurableObject class?
HYou can run Miniflare/wrangler yourself, but it still uses workerd under the hood
HMay I ask why specifically you want to avoid workerd?
Mim migrating to bun and normally tests run so fast you can enable save on keypress in vscode and watch your tests run as you're typing
Mbut you wouldn't want any external libs (workerd) spinning up on each keypress. i think the way i'll get around it is taking all the business logic out of the DO into a regular class and just test that
MHDepending on what parts of a DO you use, you may be able to get it to work?
HThough something like Synchronous SQLite probably isn’t stubable?
Mi do use alarms but I need to stub those anyway so im splitting the BL into a seperate class and then will create a DurableObjectStub that wraps the BL class for testing, and the traditional DO class will also pull in the same BL class
Mbun has an embedded sqlite too, so i'll use that in the test stub
HIs it synchronous though? Since that does provide a bit more significant challenge
HThe other thing too that Bun doesn’t/can’t mock is the supported API surface
HSo some APIs available in
workerd may be subtly different/present/not present in bun and vice versaHYour code may be able to compensate for that, but you would also need to make sure any dependencies you pull in also do so
MMi just migrated the first DO without any issue, but the other ones make use of more DO APIs so will have to just tackle them one by one and see if my stub can faithfully recreate a prod DO
Mincredible feeling getting immediate feedback on your tests 
Hlets say i want to connect more than 100k websockets with Hibernation.
since the limit is 32,768 WebSocket connections per Durable Object instance, i need some way monitor the count in every Durable Object instance, and create new objects and route requests to them? is it possible this way?
since the limit is 32,768 WebSocket connections per Durable Object instance, i need some way monitor the count in every Durable Object instance, and create new objects and route requests to them? is it possible this way?
Hthanks for the recommendation.
i also need to broadcast events to all sockets on all DO's.
how can i do it?
maybe a route on each DO's, that will do broadcast and then i will request all DO's with thier ids?
i also need to broadcast events to all sockets on all DO's.
how can i do it?
maybe a route on each DO's, that will do broadcast and then i will request all DO's with thier ids?
L@Matt , did you look into using the vitest DO integration for your testing?
LDO is just a special Workers, so still runs in V8 Isolate?
IYes, that's correct.
LSo when you connect a Worker to a DO (another Worker), if they were in the same region, would that also be 0 latency?
INot necessarily. If a DO is already running on a server (metal) then the request would hit that metal, and there are many metals in a region so it might need to be sent to a different machine.
LHow is it different:
Worker => DO + SQLite
Worker => Workers KV
Workers KV is a normal Worker, is it a DO? Or anothing thing?
Worker => DO + SQLite
Worker => Workers KV
Workers KV is a normal Worker, is it a DO? Or anothing thing?
HKV is a service running in the EU/US Core Datacenters + a datacenter-local cache
LSo it's not co-located with the Worker.
LIt's like a separate kv-store.
LKinda misleading that it's called Workers KV.
Linstead of Cloudflare KV
HThe data itself may be cached on the same metal, but that stored data is not treated as the source of truth, if that is what you mean
HNot sure what you mean? It's Workers KV because it is KV for Workers, not necessarily KV built on Workers
I^ in fact it is built on Workers now I believe, but that doesn't make it co-located with the Worker (even if the KV Worker was co-located the data is not - it's not realistic to replicate that much data to every metal/DC in the entire Cloudflare fleet)
LLBasically the same thing but for workerd instead of node?
IKind of? But each DO has it's own SQLite storage.
H- Some extra special sauce for Disaster-Recovery Replication / Point in Time Restores
HAt least AFAIK
node:sqlite doesn't do that out of the boxHYou can probably mod it to do it somehow...
L
LIt creates a sqlite db in memory.
LWhich I think is similar to what DO does since it says it lives in the same thread as the DO v8 isolate.
IThat's only that specific example.
IIt can operate on a disk based DB too.
Lonly thing is that maybe DO would have a specific amount of resources reserved for the SQLite, whereas with
node:sqlite you would need to be careful in not exceeding your memory/disk.HIIRC DO SQLite execution shares the memory of your code, so that is still a concern there
Lbut Cloudflare doesn't have any setting for specifying resources of your Worker/DO
Lyou don't even know how much you are using
IAll Workers/DOs get up to 128mb which may be shared with other invocations of the same Worker
Lah right
IAnd DO SQLite has a size limit of 1GB during beta.