Hello. Locally - I would like to have a module (A) with just a Durable Object (no Worker). Anot
Hello.
Locally - I would like to have a module (A) with just a Durable Object (no Worker). Another module (B) has a Worker (could also be a Durable Object). Can the Worker module (B) make an RPC call into DO module (A)? If i try this i get an error...
Locally - I would like to have a module (A) with just a Durable Object (no Worker). Another module (B) has a Worker (could also be a Durable Object). Can the Worker module (B) make an RPC call into DO module (A)? If i try this i get an error...
DataCloneError: Could not serialize object of type "JsRpcPromise".If i colocate the DO and Worker in the same module, then the call succeeds? Thanks.
13 Replies
what would be good examples of things to do with DO? the examples on the website are... not that great? I mean they're example of what you can do, but I'm interested in what people are building with it, what problems is it solving for you?
That's the thing, its a very extensible feature. Its left very open deliberately. If you read through some of the blog posts about new features on the developer platform, many of CloudFlare's underlying products are managed by DOs in some way in the background
Personally, I am looking to use it to fairly instantly manage data and state across a variety of clients and services. Some of the data is simply text chat, but there is other data that I need persisted to other platforms, and DOs seem to be a good way to do it. I could use 1 DO to manage a bunch of data and execute subrequests based on data received, or use multiple depending on the complexity of my workflows and processes
Thanks for the insights. But what can you do with DO that you couldn't (or it'd be harder) with a regular database? Like I'm wondering what are the most useful use cases for it. I know it's fast, and "local" (to a sense), so I'm wondering if just storing a bunch of local state/history for a specific thing would be a good idea for it. I need to store some text content (think user submitted content) and all the history for that particular submission (so we can have revisions history etc). so it feels like it should be a good option since I can just assume every submission is its own DO, so I get just get the list of history super easily etc. am I tripping? 😄
for me websockets are cool
Its not just storing the data, but immediately propagating that to connected clients immediately
Beforehand, I had a client app that would manually search for data every x seconds to see if there had been a change. Now I can avoid unnecessary calls to APIs and charges, whilst maintaining a better and more efficient data consistency across different clients
For example, I have an app that needs to take input from a user, immediately send that input to other connected clients, but at the same time, that input also needs to be sent to a couple other external services. Using Workers subrequests, I can ensure the data is sent as quickly as possible, regardless of what client sent it. This sort of system would also be serviced by using #queues which is directy built on DOs
Before, I was having to make requests every x seconds to pull data, then requests to push data on updates. Even just pulling data would take client resources, slowly down the system for the user. Now I can spend more time focusing on my backend processes, and less on ensuring smooth user feedback because I can always assume the data is correct and was sent immediately, and I'm also only making the requests that I actually need to
gotcha. yeah, websockets add another dimension that I wasn't really thinking about. instant propagation is very interesting. I'll play around with this idea to see where it goes. thanks!
Unknown User•6d ago
Message Not Public
Sign In & Join Server To View
I'm having some trouble with the idea of only using do sql storage for my new project. With a separate do for each user wouldn't you still need a central db to look up the correct id for the current user? You could use another do for that but then you run into the limit of request throughout for a single do. If you still need a central db why not just put the user data there as well?
If not using external auth that provides a stable id how can you get back the same do each time for every user without a central db?
Unknown User•6d ago
Message Not Public
Sign In & Join Server To View
How fast do WebSockets go into hibernation after no requests?
essentially immediately I think?
Unknown User•6d ago
Message Not Public
Sign In & Join Server To View
This is the closest thing I found in the docs:
If you prefer, use state.acceptWebSocket() instead, which will stop incurring duration charges once all event handlers finish runningSo at 3 requests per minute, each taking 3s to process, I will be charged 9 seconds for duration?
what are you sending via WebSockets that takes 3 seconds to process?
Are you talking 3sec of actual execution time?