Hey everyone! I have a C++ application, that creates its own sqlite database for its internals. I w

Hey everyone!

I have a C++ application, that creates its own sqlite database for its internals. I want to use it in a Cloudflare Durable Object. I recompiled to Webassembly, created Emscripten bindings, so now I can trigger the creation of the aforementioned database from JS, in a Durable Object class.
Question:

is this setup taking advantage of the Durable Object setup ?
or in other words, do I have to feed my query strings to
this.sql.exec(...)
or is the db created by my C++/WASM code is just as fast?

The answer seems to me that I have to use this.sql.exec(...) from the Durable Object API, but I'd like to double check before I get to coding!
https://developers.cloudflare.com/durable-objects/api/storage-api/#sql-api

Thanks

Cloudflare Docs

Durable Object Storage

The Durable Object Storage API allows Durable Objects to access transactional and strongly consistent storage. A Durable Object's attached storage is private to its unique instance and cannot be accessed by other objects.

Fformatc2013 Hey everyone! I have a C++ application, that creates its own sqlite database fo...

lambrospetrou•5/5/25, 8:11 AM

Your WASM database will definitely be slower. And unless you use the DO storage I don't see how your changes will be durably persisted if you only do them inside WASM.

veeque•5/5/25, 8:28 AM

when adding

limit

limit

offset

offset

keys to my queries what's the upper practical limit i should use?

Vveeque when adding `limit`/`offset` keys to my queries what's the upper practical limit...

lambrospetrou•5/5/25, 8:32 AM

Depends on your queries, we have folks doing hundreds of thousands of rows read per second, and we have seen a few low millions too. It depends how many of these queries you have in parallel since your DO will be blocked for that amount of time per request.
A few low/single-digit thousands should be a good ballpark to start with to still stay within a few milliseconds.

Original message was deleted

veeque•5/5/25, 9:21 AM

yes i was planning on doing that but i thought saying limit/offset would get my point across better

JJan Wilmake this is cool! i wonder how you would interface with actual storage though, is th...

formatc2013OP•5/5/25, 12:25 PM

i have singleton pubsub in cpp

I use emscripten::val to call js from c++

using QueryCallback = std::function<void(const std::string &)>;

c++ publishes and I in my bindings I subscribe with a function that calls into JS, and passes query string

val jsFunc = val::global("printName");
QueryCallback cb = [&jsFunc](const std::string &query) { jsFunc(query); };
pubsub_singleton.addListener(cb);

formatc2013OP•5/5/25, 12:39 PM

i'd be a lot nicer with a C++ API

ac•5/5/25, 4:15 PM

Why is there no ability to list the DO instances (or at least the number of them) on the web dashboard? I get that it is accessible via the REST API, but it seems like something that should be on the dashboard... (unless I am missing something)

Fernando Barroso•5/5/25, 9:39 PM

Has anyone built a sharding library for DOs to grow dynamically once req/s or storage limits are hit? I remember seeing something like that at some point in this chat

Avi•5/5/25, 9:43 PM

how much time after the last user disconnects will a DO spin down?

Avi•5/5/25, 9:43 PM

i need to know because we have some long-running async tasks to run

Avi•5/5/25, 9:44 PM

wondering if we need e.g.

waitUntil()

waitUntil()

in a DO

AAvi wondering if we need e.g. `waitUntil()` in a DO

Hard@Work•5/5/25, 9:44 PM

IIRC

waitUntil

waitUntil

doesn't give you more time in a DO

Hard@Work•5/5/25, 9:45 PM

The request context for a Durable Objects extends at least 60 seconds after the last client disconnects. So waitUntil is not necessary. It remains part of the DurableObjectState interface to remain compatible with Workers Runtime APIs.

FFernando Barroso Has anyone built a sharding library for DOs to grow dynamically once req/s or st...

lambrospetrou•5/5/25, 9:46 PM

I have that in progress for my own library (

durable-utils

durable-utils

), but not ready yet for any external use. I haven't seen any other library providing that though already.

HHard@Work IIRC `waitUntil` doesn't give you more time in a DO

Avi•5/5/25, 9:48 PM

oh interesting. that makes me nervous though... i have some DO code that essentially works like a regular HTTP router and i'm using waitUntil for good measure

Avi•5/5/25, 9:48 PM

why even expose that if it's truly a no-op?

AAvi why even expose that if it's truly a no-op? 🤔

Hard@Work•5/5/25, 9:49 PM

It remains part of the DurableObjectState interface to remain compatible with Workers Runtime APIs.

Hard@Work•5/5/25, 9:49 PM

IIRC because many things built for Workers expect

ExecutionContext

ExecutionContext

to exist

AAvi i need to know because we have some long-running async tasks to run

lambrospetrou•5/5/25, 9:52 PM

Your DO will stay active after the last request up to 1-2 minutes if you have some

setTimeout/setInterval

setTimeout/setInterval

scheduled, otherwise it will be evicted after 10 seconds.
If you want to keep it running for longer you can schedule an alarm to run every few seconds doing nothing other than checking if your long running tasks are done and rescheduling itself if not yet. Alarms count as normal requests so they reset the timer for eviction.

Llambrospetrou Your DO will stay active after the last request up to 1-2 minutes if you have so...

Avi•5/5/25, 9:53 PM

what about a pending promise?

stochastic•5/6/25, 5:10 AM

How do you export a DurableObject in a Next.js app using OpenNext on Workers?

TTyveris With hibernation, do you pay for those 1-2 min?

lambrospetrou•5/6/25, 8:49 AM

If you refer to websocket hibernation, then no, you do not pay for duration once the DO is hibernated.
Note that if you use

setTimeout/setInterval

setTimeout/setInterval

your DO will NOT hibernate regardles if you are using websocket hibernation, hence you will be charged for duration in that case.

Tero•5/6/25, 7:48 PM

are there any disturbances with durable objects? One of objects started throwing errors when opening websockets at 18:30 UTC and it still continues. Other instances work fine. All calls to open a websocket end in a error with some internal code, for example:

internal error; reference = keblnpj3s5njtsgrk5tjitk3

internal error; reference = keblnpj3s5njtsgrk5tjitk3

jcheese•5/6/25, 9:34 PM

Somehow DO alarms get called everytime i refresh the static page

Jjcheese Somehow DO alarms get called everytime i refresh the static page

Milan•5/6/25, 9:45 PM

Hmm, are you maybe setting the alarm to run in the constructor? Alternatively, are you calling the

alarm()

alarm()

handler directly somewhere in your DO code?

Original message was deleted

Hard@Work•5/6/25, 11:48 PM

Not natively, though you should be able to dump the SQL manually

plgingras88•5/6/25, 11:55 PM

I must admit I am still amazed this is not the #1 priority and next feature for DO (I mean native backup/restore procedures through a R2 integration or else).

Pplgingras88 I must admit I am still amazed this is not the #1 priority and next feature for ...

gruntlord6•5/7/25, 2:53 AM

you can use this at least
durable-objects

gruntlord6•5/7/25, 2:54 AM

otherwise you could have it write to d1 and use d1s dump feature

Alex•5/7/25, 8:46 AM

I get DO's that get stuck in an

alarm

alarm

loop. https://screen.bouma.link/r7vljp4v2bMkNb5vJjlT
This has been reported long time ago and marked as resolved but it doesn't look resolved for me: https://github.com/cloudflare/workerd/issues/2993#issuecomment-2801468494

I have tried emptying the

alarm

alarm

handler and wrapping all it's code in a try/catch. But I don't think I am going to get to the bottom of this without some help

Silvan•5/7/25, 3:14 PM

my assumption is still that the outerbase people are cooking something cool in regards of DO storage

Sstochastic How do you export a DurableObject in a Next.js app using OpenNext on Workers?

stochastic•5/7/25, 3:22 PM

Is this just impossible?

ac•5/7/25, 3:29 PM

Is this still an issue that's somehow hidden now? I don't have Smart placement turned on (it's on "default") but I am still getting this

RPC receiver does not implement the method [x]

RPC receiver does not implement the method [x]

error when I should not be. https://community.cloudflare.com/t/smart-placement-breaks-durable-object-rpc/654797

Sstochastic Is this just impossible?

Silvan•5/7/25, 4:05 PM

not impossible but not recommended anyway workers-and-pages-discussions

Silvan•5/7/25, 4:06 PM

but it would require you to change the built code

SSilvan but it would require you to change the built code

stochastic•5/7/25, 4:54 PM

Thanks! Makes sense.

formatc2013OP•5/7/25, 5:55 PM

Hi

In WSL open devtools does not pop up anything, other commands work fine.
Did anyone run into this?

Sstochastic Thanks! Makes sense.

gruntlord6•5/7/25, 6:04 PM

I use Durable Objects in remix and I made it so there is a backend worker handling the Durable Object for each customer (they get a unique instance each), and the remix app uses RPC to interface with the worker

Ggruntlord6 I use Durable Objects in remix and I made it so there is a backend worker handli...

Silvan•5/7/25, 7:50 PM

out of curiosity. can you use

using

using

or Symbol.dipose in remix to dispose the rpc stub?

SSilvan out of curiosity. can you use `using` or [Symbol.dipose]() in remix to dispose t...

gruntlord6•5/7/25, 7:52 PM

dispose the stub?

Ggruntlord6 dispose the stub?

Silvan•5/7/25, 7:54 PM

https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle/#explicit-resource-management

Cloudflare Docs

Lifecycle

Memory management, resource management, and the lifecycle of RPC stubs.

gruntlord6•5/7/25, 7:54 PM

I don't explicitly manage it because the durable object runs on alarms until it completes the queued work

gruntlord6•5/7/25, 7:55 PM

generally it could be as few as one task to tens of thousands, and remix is not designed for managing that nor would it really make sense given the context

Silvan•5/7/25, 9:07 PM

well its still good practice and sadly dosent really work in that environment

SSilvan well its still good practice and sadly dosent really work in that environment

gruntlord6•5/8/25, 1:14 AM

likely, but we only use the RPC to initiate the worker so we end the context very quickly and the documentation says that automatically disposes of it