(Also this only matters if your package project is built with a bundler)
(Also this only matters if your package project is built with a bundler)
1This fixed it thank you, now I definitely need to go through and add 
using
LAhh, that makes sense. I use tsc now to prep for publishing to npmjs.com
NWow Larry you put in a lot of work. As for the rquestion. The DO is like the controller and optimistic state which is called from a normal worker. So the functions have to return so that the worker can return back to the user.
One example is if old data needs to be purged to make room for new data. I simply save which data that is, set the alarm and then return back to the user. Some time later the alarm will fire and delete the data. At the same time the DO is meant to only be optimistic state so after inactivity or no longer relevant data it should just self destruct.
One example is if old data needs to be purged to make room for new data. I simply save which data that is, set the alarm and then return back to the user. Some time later the alarm will fire and delete the data. At the same time the DO is meant to only be optimistic state so after inactivity or no longer relevant data it should just self destruct.
NI'll give these a go
LWow Larry you put in a lot of workTrue, but a lot of what I'm doing right now is cleaning up and open-sourcing stuff we already use. It still requires cleanup, more tests, and documentation. As a side effect, we've fixed some bugs, improved the internal DX, and made it easier for our devs to work.
JAbout the 6 simultaneous outgoing connections limit, are there any plans to make it easier to work around it? I remember reading somewhere that 6 was chosen as the limit because its the default for some browsers, but acting as a server there are some real-world scenarios where we would benefit from having a higher limit.
Right now the options seem to be calling a worker through HTTP (so they don't share the resources and limits) or spawning a new DO instance, which is what I'm doing currently. Both sound very inefficient and can add unnecessary complexity for such a simple thing.
Right now the options seem to be calling a worker through HTTP (so they don't share the resources and limits) or spawning a new DO instance, which is what I'm doing currently. Both sound very inefficient and can add unnecessary complexity for such a simple thing.
JThis is a very noticeable bottleneck when dealing with Queues, for example
NWe have automatic geo-routing at Rivet too. Additionally – a lot of folks run RivetKit on Durable Objects since Cloudflare provides unique features or run a hybrid of Cloudflare for managed & Rivet on-prem. Happy to chat in our Discord if you have any further questions to keep this channel on topic!
Khey folks, was poking around @Brayden 's actors library and thought it would be worth asking here.
suppose i have a UserDO where i want to store event logs per user. the id would be the user ID, so there would be a SQLite table representing every user event. i liked what the actors framework was doing, where you could have a dedicated "tracker" instance that would update on create / delete of every DO so that you can scan the other DOs.
i was also thinking that it could be helpful to:
suppose i have a UserDO where i want to store event logs per user. the id would be the user ID, so there would be a SQLite table representing every user event. i liked what the actors framework was doing, where you could have a dedicated "tracker" instance that would update on create / delete of every DO so that you can scan the other DOs.
i was also thinking that it could be helpful to:
- support partitioning so that the users are collocated on the same tracker (e.g. if it's a b2b saas application, maybe you want the users to be partitioned by org so each tracker's ID would be org+tracker suffix; or maybe you want to collocate the tracker DO by geo)
- add columns to the tracker's users (e.g. if a user has properties like age, createdAt, etc.), so that you could query them later
- support repartitioning so that if the durable object for one tracker runs out of memory, it could fan out with a master-slave architecture.
JJust found the post where I read this: https://community.cloudflare.com/t/2019-9-19-workers-runtime-release-notes-concurrent-subrequest-limit/115546
NAm getting
when running
the alarm seems to still work actually. Not sure what the setName function is for since it's not in any of the examples. (https://github.com/cloudflare/actors/blob/e910e86ac1567fe58e389d1938afbdf1e53750ff/examples/durable-objects/src/index.ts)
error setting identifier TypeError: this.parent.setName is not a functionwhen running
the alarm seems to still work actually. Not sure what the setName function is for since it's not in any of the examples. (https://github.com/cloudflare/actors/blob/e910e86ac1567fe58e389d1938afbdf1e53750ff/examples/durable-objects/src/index.ts)
GitHub
An easier way to build with Cloudflare Durable Objects - cloudflare/actors
1Assuming that the DO is not processing any other requests in between, will a 1second alarm interval always execute as close to 1000 milliseconds as possible (also assuming everything else in the universe works as expected)? Has anyone benchmarked performance here? I have a counting timer that I want to synchronize between clients, my current process tells all clients when to start counting (providing a datetime ground truth), then each client handles their own timeouts to manage counting up. I would prefer to sync over WS but only if I can keep the interval as close to 1000ms as possible. The timer is used for tracking state in sports matches, so if each tick is more than 10ms out of sync then it'll add up very quickly
PI would prefer to sync over WS
No idea about the timer precision (I'd imagine there is some variability there), but websocket jitter would be more then 10ms, right?
1I'll be lucky to have more than 5 clients connected at a time, in my experience sending simple WS messages can be completed in single millisecond timeframes. I can also do an interval of under 1second (say 975ms) if I know I'm going to have a semi predictable delay with each tick (I do this currently with awful accuracy lmao)
LI don't know the numbers off my head, but I can easily see it breaching the 1s throughout the day. Also, keep in mind that a single retry starts with a 2s exponential backoff, so you already are way ahead of your limit there. That is if there is a possibility your handler will fail.
LIs this a troublesome use case for Alarms? Just by listening to people talk about on here, including you, I'm getting the feeling that anything less than a minute, might be troublesome?
LI know many users do Alarms with such low frequencies, I do a few seconds myself too, but requiring every second accuracy seems a very easy thing to go wrong, in my opinion.
At that rate the DO is always active anyway, so probably using a larger alarm and then setTimeout could give you more accuracy. The alarm would only be for making sure you get external retries in case of a crash.
At least that's my current approach for few things. But, as always it depends on the use-case. I don't know if there is a hard guarantee on alarm invocation time at the tens of milliseconds level.
At that rate the DO is always active anyway, so probably using a larger alarm and then setTimeout could give you more accuracy. The alarm would only be for making sure you get external retries in case of a crash.
At least that's my current approach for few things. But, as always it depends on the use-case. I don't know if there is a hard guarantee on alarm invocation time at the tens of milliseconds level.
Nany idea about this?
Gin general you need to be careful with alarms. Its very easy to accidentally have them loop with short timers or by having a memory error in something tied to an alarm. I generally do every 10 seconds if being in memory already would benefit the task or 30+ seconds if it doesn't or if I don't want to have a huge rush of requests
GI also use them all the time since its an extremly usefull way to handle long running tasks entirely in code, but its a double edged sword and can add complexity if not properly setup
GI haven't tried it yet, but if anyone is trying to do a lot with durable objects then its probably worth looking into using lumenize to have workers handle the actual fetch etc to be more efficient and save on billing https://lumenize.com/docs/proxy-fetch/
Offload Requests to a Worker and/or a Durable Object and have it execute a handler when the fetch is done
P(I think your link is malformed)
Gyou don't visit the .com root every day? Thanks
1Appreciate the discussion on this. My use case only needs to stay within a few seconds for around 30 minutes at a time. I'm also not fussed about forcing the DO active as it will only be for a few hours a week per DO (maybe 20 DO instances total) so not any decent scale. Sounds like I need to not stress so much about syncing every second, will have a bit of a think about it
1does the durable object jurisdiction param only matter upon creation
1i.e. create the DO with the eu jurisdiction param (once), then omit the param forever afterwards
1knowing this will either be a few or many lines of change
HI would just keep it, there isn't really a reason not to send it
1im just wondering if its redundant
HIt shouldn't be? Though actually, it might error if you don't provide it?
1
1so it isnt redundant
HYeah
1thanks
BIf you generate and query by name, you have to supply the jurisdiction. If you use durable object IDs, the jurisdiction is embedded in the ID so you don't have to limit the namespace. This has been my experience
Chey folks, supposing I wanted to bind a sandbox to an internal service (separate DO), is that possible? I was digging around the docs and didn't find anything too promising, but wanted to double check here.
basically I want to be able to do something like:
worker → create sandbox, execute commands in a loop → sandbox-backend (handles things like auth)
feel free to also redirect me if there's a better channel
basically I want to be able to do something like:
worker → create sandbox, execute commands in a loop → sandbox-backend (handles things like auth)
feel free to also redirect me if there's a better channel
H?crossposting
SPlease do not post your question in multiple channels/post it multiple times per the rules at #
welcome-and-rules. It creates confusion for people trying to help you and doesn't get your issue or question solved any faster.
welcome-and-rules. It creates confusion for people trying to help you and doesn't get your issue or question solved any faster.LThe Worker to DO pattern is the norm, but I'm uncertain what you mean by "sandbox". Is it untrusted code?
1Probably the CF Sandbox SDK https://developers.cloudflare.com/sandbox/ which is basically containers with a wrapper
LAhh, makes sense. I'm unfamiliar with that product, although I think it would be cool to get my AI Coding Agent to run in one of them. Just not sure how I'd see the output.
1Stream it back via WebSockets
LWould need something like that. I'm sure someone has already built that or will soon.
MRequest/Question:
I was wondering if there’s a way to perform a cross join between data stored in different Durable Object tables — similar to how PostgreSQL uses foreign data wrappers (FDWs). It would be game changer.
I was wondering if there’s a way to perform a cross join between data stored in different Durable Object tables — similar to how PostgreSQL uses foreign data wrappers (FDWs). It would be game changer.
LThat would be a neat trick, but I've never heard of anything like that, and I probably would have if it existed.
AIt's built in, you can open a ws to anything insider your sandbox
https://developers.cloudflare.com/sandbox/guides/websocket-connections/
https://developers.cloudflare.com/sandbox/guides/websocket-connections/
LIt's good to know that the WebSocket part is already built in. Do you know anyone who is using it as a remote AI coding platform? I'd love to hear more about the setup.
ANo I just recently found out about this myself. Looks like a killer offering tho... docker container, with DO-like ergonomics
ADoes anyone happen to know, if you call a DurableObject via RPC, does that implicitly also wake up its associated Worker?
To ask differently. Do I get billed more if I do:
CallerA -> WorkerB.rpc() -> DO-B.rpc()
vs
CallerA -> DO-B.rpc()
To ask differently. Do I get billed more if I do:
CallerA -> WorkerB.rpc() -> DO-B.rpc()
vs
CallerA -> DO-B.rpc()
LWhat is CallerA? Is it client-side (browser or app)? Workers RPC is between Workers, DOs, and RpcTargets. If you want all the way to the client, you need something like Cap'n Web or Lumenize RPC. If you are just using Workers RPC, the called DO is accessed directly without the involvement of the Worker in the module where that DO is defined.