Thanks for your precious involvement, I read and take great interest in your work
Thanks for your precious involvement, I read and take great interest in your work
LThat makes it all worth it.
LIt does. I included a mention of it in my reply but switching to Agents is a big commitment and I don't trust it since they let a security-relevant bug go unfixed for months
AYeah, I pulled the individual methods out instead of using the whole thing
LThere is Brayden's elegant Alarm class but it's not documented, and by default requires your DO extend the Actor base class unless you duplicate what that base class does manually.You actually don't need the Actor base class. I am a fan of toolkits personally, so we tried
See example in https://github.com/cloudflare/actors/blob/e910e86ac1567fe58e389d1938afbdf1e53750ff/examples/durable-objects/src/index.ts#L21
Same goes for the SQL Schema migrations, you can use them without the Actor base class, and retry utilities too.
LAnd yes, we need to document the whole package better. It's coming.
LHere are the docs. This is the one that shows you the same thing that Lambros just did, namely how to do without extending Actor, but it has API usage docs also: https://lumenize.com/docs/actors/alarms/plain-usage
This is the same thing but using the Actor class: https://lumenize.com/docs/actors/alarms/basic-usage
This is the same thing but using the Actor class: https://lumenize.com/docs/actors/alarms/basic-usage
LApologies for the doc-test format. I realize the testing foo sorta gets in the way of the key stuff. It's just the quickest way for me to write docs that I know are correct. I'll come back with more concise ones some time later.
LBTW, this was a fun exercise. I learned more about Actors and how it implements Alarms. I also learned that testing alarms is less than ideal in 's , so I spent the rest of the day adding alarm testing support to @lumenize/testing, which requires no manual triggering of alarms. I switched the docs linked above over to using it so there is about half the boilerplate that there was before.
PUnsure if this kind of topic is welcome here, but have you heard about Rivet, which presents itself like the "open source durable object" with many more features and platform agnostic ? Imagine durable object but no lock-in, no worker limitation (128Mb ram, V8 isolate, etc.), but with other features like local sync first, workflows, background jobs, rate limiting. This is not a 1:1 comparison, both have their own pros and cons, but this can be hosted anywhere, from personnal VPS to Cloudflare workers/do too. I believe (and mostly hope) this is the kind of new project that makes CF less unique and will trigger their fire team to work on missing features.
https://www.rivet.dev/
https://www.rivet.dev/
Rivet
Rivet is a library for long-lived processes with durable state, realtime, and scalability. Easily self-hostable and works with your infrastructure.
LHave you tried it, though? What worked better for you vs CF DOs, or worse?
PI haven't yet, I just started to follow the project few weeks ago. This surely is on my bucket list whenever I get a chance. They also provide a cloud hosted solution, this may be a simple start to play with it, while I do not know anything about the cloud providers and architecture behind (e.g. : is this local disk like DOs, etc).
PWhat I find interesting, out of the lock-in, is that I am not restreined to a middle-man worker and I could host actors on a dedicated servers with tons of CPU and RAM, where worker blocks me at 128Mb and reserves the right to share 2 instances on the same behind the scene.
LSelf-hosting is a different game though.
POf course, but they also offer a cloud solution or even using CloudFlare and Durable objects under the hood. At the end of the day, the portability is yours to chose.
PMy point is, in all respect, if what they promise is right and they succeed the way they are rushing right now, Cloudflare durable objects may become the blackberry of their iphone. 
JIts very rare that you see competition taking over in a sweep like it happened there, and this does not look like a paradigm shift, just some welcome competition in the space
Lusing CloudFlare and Durable objects under the hoodThe notion of "write once deploy anywhere" is appealing but it's extremely challenging from many dimensions (performance, DX, etc.). Think of it as a tradeoff between portability and avoiding leaky abstractions. This would be super-leaky and it would always lag DO features.
History is littered with these sort of things that sound great at first but get in the way more than help: The Serverless Framework, SDN (software-defined network), ORMs to a degree, Xamarin (although it pivoted and became .NET 2.x+), AWS Event Bridge, Azure Event Grid, etc.
I was a consultant for a huge project at Intuit to define their own least common denominator programming language that would compile down to Java or .NET. It took years and while they were trying to make it work well, they didn't release any new products and few new features because everyone was ordered to use this new programming language and it was always a few months from being ready. In the end, they gave up but they never got back those 2-3 years of wasted effort and near zero feature velocity.
That tamed my desire for portability, and I'm much happier because of it.
JAlso choosing a product goes beyond one specific feature. Trust for example (both in terms of cybersecurity and longevity of the product/company) can play a big role. One of the biggest reasons I like Cloudflare as a platform is because of the direction that it goes towards and the team behind it rather than one specific thing that I like or dislike, because I think this is more likely to provide consistent value over time
JIts very easy to make something better in a single dimension, but designing it to be great as a whole package is very hard
LI love the way you think
PAbsolutely — I agree with much of what’s been said. Cloudflare DOs bring strong advantages, such as automatic geo-routing to the nearest instance, security, infra, and more. Rivet, on the other hand, gives you the flexibility to stay within that ecosystem or branch out to other platforms to overcome limitations like tight resource caps or vendor lock-in.
What really stands out is Rivet’s clean API and documentation. It’s impressive, offering several capabilities Cloudflare doesn’t (at least not yet). Rivet won’t replace DOs anytime soon, but projects like this are healthy for the ecosystem. Brayden built Outerbase and it pushed the industry forward, to everyone’s benefit. While I don’t expect Rivet to follow the exact same trajectory, I do think it sends a strong message that should motivate the DO team to address current constraints and refine their trade-offs.
What really stands out is Rivet’s clean API and documentation. It’s impressive, offering several capabilities Cloudflare doesn’t (at least not yet). Rivet won’t replace DOs anytime soon, but projects like this are healthy for the ecosystem. Brayden built Outerbase and it pushed the industry forward, to everyone’s benefit. While I don’t expect Rivet to follow the exact same trajectory, I do think it sends a strong message that should motivate the DO team to address current constraints and refine their trade-offs.
PAlso, i see Rivet like Better-auth. This kind of project can be surprising despite being handled by few people. Great new projects take lessons from existing solutions and get the best out of them without dragging their debts.
BIdk about the trust tbh. With Cloudflare, it seems like you are just one failed payment away from having your account locked and getting stuck in support limbo.
AHow are people managing external DB connections in DO's... specifically, I'm really struggling to find a clean pattern of when/where to close db connections (for ex to Postgres)
Initially I thought I'd just get away with connecting at the start of a request/rpc, and disconnecting at the end. But this can get pretty messy (if there are a lot of early returns / throws, your code gets peppered with disconnect calls. Sure you can wrap in a parent fn, but still feels ugly).
Ideally I could use a pool, keep it open to serve multiple (possibly concurrent) requests, but I have no idea when to close it. This is where an eviction/hibernation hook would come in handy.
Anyone have any good patterns here?
Initially I thought I'd just get away with connecting at the start of a request/rpc, and disconnecting at the end. But this can get pretty messy (if there are a lot of early returns / throws, your code gets peppered with disconnect calls. Sure you can wrap in a parent fn, but still feels ugly).
Ideally I could use a pool, keep it open to serve multiple (possibly concurrent) requests, but I have no idea when to close it. This is where an eviction/hibernation hook would come in handy.
Anyone have any good patterns here?
HI would use Hyperdrive
Cloudflare Docs
Hyperdrive is a service that accelerates queries you make to existing databases, making it faster to access your data from across the globe from Cloudflare Workers, irrespective of your users' location.
AI am, but I don't see how this solves my issue. as far as my code is concerned, HD just gives me a connectionString. I still need to have the pg driver connect/disconnect, no?
Aunless you're saying with HD, I don't need to explicityly disconnect, which would be something.
HYeah, since the connection is within the runtime, IIRC the connection is just terminated automatically, and the pool doesn't disconnect
HNot sure if I worded that right, sec
HBasically, with Hyperdrive, you don't need to disconnect manually, since you are connected to the Hyperdrive pool, not directly to your Database.
AYes I understand the actual db is not involved here, I'm specifically talking about the connection from worker/do to Hyperdrive.
AAre there docs anywhere that say you don't need to disconnect a db driver from Hyperdrive?
HMaybe try in #hyperdrive
RI am getting a 500 when trying to use the data studio, the same sql works fine when I run it inside the DO "SELECT * FROM sqlite_master"
LRe set it in the constructor. That will get called next time it's accessed after the deploy.
JI want to publish an npm package for use in cloudflare projects that includes a pre-written durable object. End users would install the package, add a couple lines to their
I have 2 questions:
wrangler.jsoncI have 2 questions:
- This import
assumesimport { DurableObject } from "cloudflare:workers";
can be resolved, but of course that is only importable with a build tool like vite. Should I bundle cloudflare:workers as an internal dependency? What would the CF team recommend?cloudflare:workers - How does the
property of wrangler's config work? Can it resolve a class that is in a dependency?class_name
LTrue. I hadn't thought of that. What if you set the new alarm at the beginning of your handler for the current alarm instead of at the end?
Kcloudflare:workersworker-configuration.d.tsnpx wrangler typesthats where typescript gets it, but it has a concrete implementation too doesnt it?
KI don't know the details about the runtime but since class_name must be the name of the class I guess thats how they know it.
HYou should mark it as an external dependency. Treat it like imports to
node:Thanks, will do. As for the
class_nameIt's the name of the export in the Worker's
mainSuperDOok excellent. thank you for that clarification
JLast question (for now 
) is there any way to "extend" a
) is there any way to "extend" a wrangler.jsonctsconfig.jsonNo, there is not
1I just got the following warning in a Worker that creates a bunch of DO stubs in quick succession (and doesn't explicitly dispose of them). My understanding from reading the docs was that the disposal is technically optional as the runtime will do its best to dispose of them when necessary. Is there a certain limit I'm hitting where I need to start explicitly disposing?