Matthew Prince, the CEO of Cloudflare, has hinted that some new DB features may come in the future https://community.cloudflare.com/t/memcached-a-in-memory-low-latency-distributed-storage-for-dynamic-changing-content/224439/7

ah but thats memcached

what if the 128MB limit is hit?

the original topic was about memcached yeah

but the tweets I quoted in that reply were about Cloudflare maybe offering a distributed database that's similar to DynamoDB

to which Matthew responded "Stay tuned"

wont hurt to give it a try, eh?

The goal is that you should be able to build a DBMS on top of Durable Objects. I would expect eventually to see many different types of DBMS -- SQL, KV, document, graph, etc. -- built on it. Maybe some of them will be written by Cloudflare, but my hope would be that many of them come from third parties, creating a rich ecosystem of options.

I certainly wouldn’t be able to build an entire DBMS by myself, it takes mutilple people and many smarter than me The closest I’ve done was some sort of DB were each element was something in the file system, and it used the file names as Primary Keys. On the bright side I DID manage to do it in S3 and use bucket replication

Of course, I'm not saying every app developer would need to build their own DBMS. But the hope is that a few different teams will build different kinds of databases and make them available (maybe open source, maybe for sale, etc.).

i don't suppose there's a workaround for being able to use the console to edit / run scheduled functions for workers deployed with the new module/metadata.json format? anything i deploy in that format ends up with a

workers.api.error.unknown (Code: 10013)

error on the

/workers/edit/{name}

page.

Unfortunately the dashboard UI and preview service do not understand modules at all yet.

Hi everyone! So i've made a simple durable objects webserver example that echos what you send it via websockets to all the other websocket subscribers. There is no storage involved. I then proceed to use it to send data but what happens is the socket just goes dead and nothing comes through anymore. It is pretty consistent behaviour and i'm wondering what I might be doing wrong. There are no errors given either on the client or on the cloudflare console. I have tried it with other websocket echo examples and they work fine so i'm sure its not a connection issue or antyhing like that

i've also made a sample gist of my code, hoping someone can help me out! https://gist.github.com/Tarang/d9706e7703b438254503b94a4d8b8719

Thanks a lot. This will surely be very helpful for my DO demo project. Tnx again for sharing!

It works but if you use the code on the bottom and basically have a lot of data getting sent through the websocket connection gets terminated from cloudflare's end and i'm really unsure why

anyone know of ideas i could do to fix it? am i hitting any undocumented limits?

I didn't see anything obviously wrong with the code at first glance, but I do notice that you have a `try`/`catch` block where the catch simply ignores the error. Maybe an exception is getting caught there and being thrown away? I would recommend sending an error message back to the WebSocket client.

If you're looking for Durable Objects example code, there is: https://github.com/cloudflare/workers-chat-demo

Thanks kenton let me see if changing that helps

i made this example from the chat demo, but i tried to strip it down to make it simpler

i think im still getting the issue. I just get disconnected if i send a lot of data in. Im testing sending level 2 streaming prices

im sure its related to the amount of data being sent, if for example i reduce the number of symbols it takes longer to get disconnected. If i have more the timeframe to get disconnected is shorter.

Did a couple of tests to try and figure out how much data is going through before i get disconnected: Attempt 1: Data Transferred: 1,465,731 bytes Time from start to end of connection: 1:36.224 (m:ss.mmm) Attempt 2: Data Transferred: 977,177 bytes Time from start to end of connection: 34.593s Attempt 3: Data Transferred: 1575205 bytes Time from start to end of connection: 1:26.059 (m:ss.mmm) Attempt 4: Data Transferred: 974879 bytes Time from start to end of connection: 30.617s

I've made it reproducible. Ive updated the gist (https://gist.github.com/Tarang/d9706e7703b438254503b94a4d8b8719) with code with a debugging hook to try and get any errors: 1. Publish the first script (mjs file) using (publish.sh) and get a url, make sure to enable the deployment (use edge-websocket as the script name) 2. Open a chrome window, it can be on any website & enter the js code on the 2nd - update the url to the one from 1 3. Watch the network tab, the websocket connects and be disconnected after a very short amount of time with no errors Optionally (Using wscat,

npm install wscat -g

) use

wscat -c <url from step 1>

to view messages come in, type

listen

and press enter to enable the debug hook where errors should come in if there are any - but none come in

I'm working on Durable Objects all day today ✨ Excuse the brain dump, but here are some notes from the experience: 1. I know wrangler support is inbound soon, but in the meantime, it wasn't clear from the workers-chat-demo

publish.sh

script or the documentation that I could send more than one MJS file in my upload, nor that the name of those files don't matter. Below is totally valid, but that wasn't obvious to me:

sh
# upload_script uploads our Worker code with the appropriate metadata.
upload_script() {
  curl_api https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/scripts/$SCRIPT_NAME \
      -X PUT \
      -F "metadata=@metadata.json;type=application/json" \
      -F "script=@index.mjs;type=application/javascript+module" \
      -F "datatable=@datatable.mjs;type=application/javascript+module" \ # More than one MJS file (name it anything)
      -F "icanputanythinghere=@index.html;type=application/octet-stream" > /dev/null
}

2. There's no way to delete a DO. If I have the ID of an existing DO, I might want to delete the DO and all of its storage. Right now, the best I can do is get the DO, and just iterate over the storage, deleting everything. The DO itself seemingly can't be deleted.

3. Constantly wrapping communication between the worker and DO with

JSON.stringify(data)

and

await response.json()

is a bit of a faff. I realize that it has to go through the Fetch API, but an

async json() {}

method (or similar) on the DO stub would remove an annoying bit of boilerplate I have to include in all my DOs. I realize you lose the routing side of things by doing this instead of using

fetch

, but I'd argue that something like Redux's patterns here are actually better:

js
await usersStub.json({
  type: "updateUser",
  data: {
    firstName: "Greg"
  }
})

versus

js
await usersStub.fetch('http://fakehost/user', {
  method: "POST",
  body: JSON.stringify({ firstName: "Greg" })
})

Better, not just because of the reduced overhead with

fetch

, but also because I would be able to (more easily) type the action with TypeScript. I could easily mandate that the

updateUser

type action has a body that has a

firstName

attribute. That's harder in with

fetch

if I'm splitting up my data between the request URL and the body. 4. Love the MJS support. It is beautiful <3. We just need support (from Cloudflare and from tooling such as bundlers) to catch up. cc @User

The way to delete an object is to delete all of its storage. An empty object ceases to exist once it is shut down (if it's ever requested again, it is implicitly recreated -- still empty). We are going to add a

storage.deleteAll()

method to help with this -- and document it better.

Ah, that makes sense. So once I delete the storage, I'm safe to just discard the ID of the object that I have saved somewhere and just forget about it. Cool!

yep