Ok no problem, so there is no limit on websocket connection right?

RRahul gangotri Ok no problem, so there is no limit on websocket connection right?

K

kenton•1/22/25, 8:45 PM

there's just the memory limit and the fact that the DO is single-threaded. Each new connection presumably takes some memory and some CPU time to handle messages, but there's no explciit limit on number of connections.

R

Rahul gangotriOP•1/22/25, 8:46 PM

Btw here

https://pusher.com/

Pusher | Leader In Realtime Technologies

Simple, scalable and reliable. Hosted realtime APIs loved by developers and trusted by giants. Build live dashboards, notifications, geotracking, chat and more.

Kkenton there's just the memory limit and the fact that the DO is single-threaded. Each ...

R

Rahul gangotriOP•1/22/25, 8:46 PM

And whats the memory limit?

G

geg•1/22/25, 8:47 PM

We can read the docs for this!

R

Rahul gangotriOP•1/22/25, 8:48 PM

No need of alarms or ping pong when hibernation is used

G

geg•1/22/25, 8:49 PM

I encourage everyone to read docs! We can get more intricate responses from staff this way!

G

geg•1/22/25, 8:49 PM

That's all, bye

TTyveris Would love a quick sanity check on my planned architecture. Worker + DO w/ WS p...

R

Rahul gangotriOP•1/22/25, 8:53 PM

As mentioned in docs, You can create as many objects as needed, only limit is on namespaces per account

You can create unlimited durable objects in 1 namespace

Also there is a storage limit in each DO AND ACCOUNT LEVEL BOTH

BBahaa Is there a particular reason you find them not easy? My understanding is `wrangl...

H

Hard@Work•1/22/25, 9:47 PM

SvelteKit, at least afaik, doesn't have a way of allowing you to export a DO class in build, so you have to inject it manually

H

Hard@Work•1/22/25, 9:47 PM

In addition, the way SvelteKit does bindings when using their dev service also doesn't allow you to export a DO Class, which means you need a separate

wrangler dev

wrangler dev

process for it

J

James•1/22/25, 9:49 PM

I didn't know about the getPlatformProxy approach, but that would work too, I ended routing all svelkite DO requests to the local fetch handler of the DO whenever running locally, otherwise use the DO binding directly. Both return the same response signatures.

森

森@VerseLink (RW)•1/23/25, 12:39 AM

I’ve been thinking, the total account level limit for DO is 50GB, but D1 has limit of 250 GB; it was reasonable back when DO isn’t meant for database storage or as a self contained database, but now, using it as some sort of distributed database with great potential to be low latency and as near as the user as possible, does cloudflare consider:

Raising the limitations of per account DO storage
Any form of guarantee that we can always raise of said limitations; filling out this form to raise limitations seems like a weak promise, that we felt like if we do ever hit those limitations, we need to look for plan B as soon as possible in case no one replies to our limitation increase request
DO was more or less meant for “session” like behavior prior to SQLite backend, but now its also work as a distributed database, correct me if I’m wrong, but once a DO is created it cannot move location, are there plans to say either replicate the DO or hint it to initiate said instance to a different location next time it gets reinitiated (let’s say a user that has a DO db assigned to them travels between countries)
We have platform for workers, but what about platforms for DOs? It would definitely be an interesting aspect to create services on top of DO too and not just workers.

森森@VerseLink (RW)I’ve been thinking, the total account level limit for DO is 50GB, but D1 has lim...

J

James•1/23/25, 1:47 AM

You bring up some good points. I’d always assumed DO account level storage limits would scale up by a huge factor once the service is GA. Part of the reason I moved most of my storage to DO was to get around D1 limits for storage. 10Gb isn’t enough, and if I’m scaling horizontally, it made more sense to move to DO sql db tenants.

JJames You bring up some good points. I’d always assumed DO account level storage limit...

森

森@VerseLink (RW)•1/23/25, 2:09 AM

Agreed, I started to explore DO sql because of D1 limits (and also explored turso), but when I understood the potential of DO with SQL, I really want to work some new projects on it, my biggest concern now has been that DOs artificial limitations made sense with old DO, but with what it could do with SQL, I think the restrictions needs to be heavily revised

H

HowlOftheSun•1/23/25, 4:39 AM

Is that code in a shareable place? I'd be interested in seeing what you did

森森@VerseLink (RW)I’ve been thinking, the total account level limit for DO is 50GB, but D1 has lim...

L

lambrospetrou•1/23/25, 8:26 AM

The account storage limit for DOs is purely a soft limit. If you ask for a raise you will get a raise, assuming you are not doing something obviously phishy on the platform. I am guessing the team will raise it for everyone at some point in the future too, but for now you can ask for a raise of it once you are close to it.

Aalgads Pleasantly surprised this evening. I wanted to see if the outbox pattern could ...

L

lambrospetrou•1/23/25, 8:33 AM

Is there any documentation about what features in sqlite are available within the DO context? Is it safe to assume all the big ones like views, triggers, etc.?

Unfortunately, the docs are a bit spread now (we are fixing them gradually), but you can see D1's SQL docs and they are the same for DOs too.

https://developers.cloudflare.com/d1/sql-api/sql-statements/ (pragmas you can use)
https://developers.cloudflare.com/d1/sql-api/foreign-keys/ (foreign key relevant things)
https://developers.cloudflare.com/d1/sql-api/query-json/ JSON

As of today DOs use SQLite 3.47.

Aalgads Pleasantly surprised this evening. I wanted to see if the outbox pattern could ...

森

森@VerseLink (RW)•1/23/25, 9:38 AM

here's a another question: (maybe similarly applying to D1 too), how is trigger execution priced? is it priced the same rate as DO or likely no charge at all

森

森@VerseLink (RW)•1/23/25, 9:39 AM

(also ignore the question i just deleted, i brain farted)

森森@VerseLink (RW)here's a another question: (maybe similarly applying to D1 too), how is trigger ...

L

lambrospetrou•1/23/25, 10:08 AM

There isn't separate pricing. As long as your DO runs, you are charged as usual.

A

arbfay•1/23/25, 11:46 AM

Flash DX improvement idea:

instead of

const doid = env.MY_DO.idFromString(user_id)
const stub = env.MY_DO.get(doid)

const doid = env.MY_DO.idFromString(user_id)
const stub = env.MY_DO.get(doid)

const doid = env.MY_DO.idFromString(user_id)
const stub = env.MY_DO.get(doid)

const doid = env.MY_DO.idFromString(user_id)
const stub = env.MY_DO.get(doid)

let stubs be retrieved with just a string (to reduce boilerplate)

const stub = env.MY_DO.get(user_id) // ID
// or, for names
const stub = env.MY_DO.get(user_id, "name") // like KV's type

const stub = env.MY_DO.get(user_id) // ID
// or, for names
const stub = env.MY_DO.get(user_id, "name") // like KV's type

const stub = env.MY_DO.get(user_id) // ID
// or, for names
const stub = env.MY_DO.get(user_id, "name") // like KV's type

const stub = env.MY_DO.get(user_id) // ID
// or, for names
const stub = env.MY_DO.get(user_id, "name") // like KV's type

just one less line to work with DOs

Aarbfay Flash DX improvement idea: instead of ```js const doid = env.MY_DO.idFromStrin...

M

Max (@rozenmd)•1/23/25, 12:15 PM

When you get a network disconnect and want to recreate the stub, you don't want to recompute the ID though

E

elunesarrow•1/23/25, 12:19 PM

Hi, let's say I'm using DO only to rpc into its sqlite data, no websocket session, do I get charge for anything outside rpc (i.e. startup time & idle time post-rpc if any?)

MMax (@rozenmd)When you get a network disconnect and want to recreate the stub, you don't want ...

A

arbfay•1/23/25, 12:20 PM

is it an expensive operation? and why should that be the developer's concern and not the binding/platform's concern?

Aarbfay is it an expensive operation? and why should that be the developer's concern and...

L

lambrospetrou•1/23/25, 12:34 PM

In reality most real-world applications do not expose directly the raw DO IDs as their own application IDs, so you anyway will have to do some conversion/validation/parsing before passing it to the

get(...)

get(...)

method. So, it's 1 extra line among tens/hundreds.

I do usually end up creating a helper function though that wraps my applications logic and achieves what you suggest above. 1 line to create DO stubs, but based on my apps parsing logic.

K

KWAC•1/23/25, 1:53 PM

why it closes connection when i send message to server?

// Global list to store all active WebSocket connections
const clients = new Set();

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const upgradeHeader = request.headers.get('Upgrade');
  if (!upgradeHeader || upgradeHeader !== 'websocket') {
    return new Response('Expected Upgrade: websocket', { status: 426 });
  }

  const webSocketPair = new WebSocketPair();
  const [client, server] = Object.values(webSocketPair);

  // Add the new connection to the global list
  clients.add(server);
  server.accept();

  // Handle incoming messages
  server.addEventListener('message', event => {
    console.log('Message received from client:', event.data);

    // Broadcast the message to all connected clients
    clients.forEach(client => {
      if (client !== server && client.readyState === WebSocket.OPEN) {
        client.send(`Broadcast: ${event.data}`);
      }
    });
  });

  // Handle connection close
  server.addEventListener('close', () => {
    console.log('Client disconnected');
    // Remove the connection from the global list
    clients.delete(server);
  });

  return new Response(null, {
    status: 101,
    webSocket: client,
  });
}

// Global list to store all active WebSocket connections
const clients = new Set();

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const upgradeHeader = request.headers.get('Upgrade');
  if (!upgradeHeader || upgradeHeader !== 'websocket') {
    return new Response('Expected Upgrade: websocket', { status: 426 });
  }

  const webSocketPair = new WebSocketPair();
  const [client, server] = Object.values(webSocketPair);

  // Add the new connection to the global list
  clients.add(server);
  server.accept();

  // Handle incoming messages
  server.addEventListener('message', event => {
    console.log('Message received from client:', event.data);

    // Broadcast the message to all connected clients
    clients.forEach(client => {
      if (client !== server && client.readyState === WebSocket.OPEN) {
        client.send(`Broadcast: ${event.data}`);
      }
    });
  });

  // Handle connection close
  server.addEventListener('close', () => {
    console.log('Client disconnected');
    // Remove the connection from the global list
    clients.delete(server);
  });

  return new Response(null, {
    status: 101,
    webSocket: client,
  });
}

// Global list to store all active WebSocket connections
const clients = new Set();

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const upgradeHeader = request.headers.get('Upgrade');
  if (!upgradeHeader || upgradeHeader !== 'websocket') {
    return new Response('Expected Upgrade: websocket', { status: 426 });
  }

  const webSocketPair = new WebSocketPair();
  const [client, server] = Object.values(webSocketPair);

  // Add the new connection to the global list
  clients.add(server);
  server.accept();

  // Handle incoming messages
  server.addEventListener('message', event => {
    console.log('Message received from client:', event.data);

    // Broadcast the message to all connected clients
    clients.forEach(client => {
      if (client !== server && client.readyState === WebSocket.OPEN) {
        client.send(`Broadcast: ${event.data}`);
      }
    });
  });

  // Handle connection close
  server.addEventListener('close', () => {
    console.log('Client disconnected');
    // Remove the connection from the global list
    clients.delete(server);
  });

  return new Response(null, {
    status: 101,
    webSocket: client,
  });
}

// Global list to store all active WebSocket connections
const clients = new Set();

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const upgradeHeader = request.headers.get('Upgrade');
  if (!upgradeHeader || upgradeHeader !== 'websocket') {
    return new Response('Expected Upgrade: websocket', { status: 426 });
  }

  const webSocketPair = new WebSocketPair();
  const [client, server] = Object.values(webSocketPair);

  // Add the new connection to the global list
  clients.add(server);
  server.accept();

  // Handle incoming messages
  server.addEventListener('message', event => {
    console.log('Message received from client:', event.data);

    // Broadcast the message to all connected clients
    clients.forEach(client => {
      if (client !== server && client.readyState === WebSocket.OPEN) {
        client.send(`Broadcast: ${event.data}`);
      }
    });
  });

  // Handle connection close
  server.addEventListener('close', () => {
    console.log('Client disconnected');
    // Remove the connection from the global list
    clients.delete(server);
  });

  return new Response(null, {
    status: 101,
    webSocket: client,
  });
}

Aalgads Pleasantly surprised this evening. I wanted to see if the outbox pattern could ...

J

James•1/23/25, 3:02 PM

Id work to ensure heavy compute takes place away from the DO due to cost. You pay for wall time on a DO but not a worker, so api calls are much cheaper outside a DO. You could adjust your logic to still use triggers on the DO but offload to a worker once the alarm kicks off.

Aalgads Here is sample code that should give a good idea of what I am trying to do: http...

H

HowlOftheSun•1/23/25, 3:32 PM

Thanks!

J

James•1/23/25, 4:08 PM

@algads , caveat is that you lose the synchronicity of a single threaded DO once you offload to a worker, events may push to your API out of order

Aalgads @Ahz thinking about this some more though, since the DO is single threaded and t...

J

James•1/23/25, 5:00 PM

not if downstream workers are delayed or blocked, req1 to API hangs, req2 5 seconds later finishes first.

J

James•1/23/25, 5:14 PM

it could fire again, but the DO will be busy on its current thread, but if you await anywhere in the DO, then you're open to losing synch

and if you fire the alarm and offload to a worker, well thats all async and anything goes

JJames it could fire again, but the DO will be busy on its current thread, but if you a...

L

lambrospetrou•1/23/25, 5:53 PM

That's not how it would work. Each time you set the alarm you schedule one execution. And you setup a new alarm in that invocation, so until you set a new alarm time, there won't be a new alarm invocation.

J

James•1/23/25, 6:09 PM

are you sure we're talking about the same thing?

alarm 1 fires, has async tasks and takes 10 seconds with some async sprinkled throughout
during the execution context switching, other things can happen on the DO

I know only one alarm can be set at a time, but in this case the alarm already fired, and its up to the developer to manage the data flow from there, especially if these tasks run async

Ok no problem, so there is no limit on websocket connection right?

Similar Threads

Similar Threads

Similar Threads