Prefer web socket method DO vs Worker for sources

[Brayden]

Purpose

Originally all web socket communication was handled via the Durable Object and its hibernation API. Then with the introduction of external data sources we abstracted the web socket communication to live more ephemerally on the Worker and we removed the socket handler on DO's. Now... we're bringing it back!

Why?
Web socket connections on the durable object can handle state between requests. Allowing web sockets to be handled at this level will provide additional flexibility for developers interfacing via Starbase plugins to achieve their goals.

Should all web sockets move to Durable Objects?
TLDR; I don't believe so.
For externally connected databases we use web sockets via the Worker instead of the Durable Object. Could a case be made that handling state between multiple web socket messages makes sense for these data sources? Sure. But at the moment we would need to then also migrate all of our code of how we communicate with those data sources to being inside a DO and that comes with downside. The upside of communicating with an external data source via a Worker is the worker is on the edge and acts as a node en route to the destination. If we were to move it to a Durable Object, there are far fewer global nodes, less possibilities with throughput (RPS), and overall would likely slow down those responses overall.

Tasks

• Internal source /socket requests use Durable Objects web sockets
• External source /socket requests use Workers web sockets
• FIX: Issue where running executeTransaction in a DO was not returning results

Verify

Before

After

[Ehesp]

This has made me think... Currently we create an RPC session against the DO, which is billed as a single request - however does a session incur wall clock time if it's not actually calling any internal methods?

Duration is billed in wall-clock time as long as the Object is active

Does an RPC session keep the DO active?

In relation to this PR, I'm not 100% sure if having the WS handler inside of the DO adds any benefit (could be totally wrong):

Web socket connections on the durable object can handle state between requests. Allowing web sockets to be handled at this level will provide additional flexibility for developers interfacing via Starbase plugins to achieve their goals.

Since the plugins have access to the stub/RPC session, don't they have this ability already? The worker holds the WS connection and calls the RPC session.

[Brayden]

Does an RPC session keep the DO active?

I know it at the very least calls the constructor of the DO, but not sure if this accrues wall-time. From what I can tell it seems to add wall-time while web socket connections are actively held onto and being used (hence the hibernation API for those). When it comes to everything else related to it without web sockets it seems like if there is any wall time it's quite negligible.

Since the plugins have access to the stub/RPC session, don't they have this ability already? The worker holds the WS connection and calls the RPC session.

A Worker can initiate a web socket connection but it can't hold onto it forever (unless I'm wrong here) and this is where Durable Objects start to shine. Because DO's can maintain state, I can accomplish the following... which was the root of this pull request:

• Multiple clients establish a web socket connection between server <> client
• A plugin can enumerate through that list of connections and send messages on intervals or at specific events (e.g. when a DELETE event occurs in the database we can inform subscribers of that event)

It doesn't seem like Workers are a good use-case for that which is what prompted me to open the ability to support more ephemeral web socket connections in Workers, or longer-lasting more maintained connections via Durable Objects. But absolutely all ears on thinking through this problem through another lens! :)

cc: @Ehesp