json-rpc-mixin
Ummm, I am not sure about the lack of await just because of service bindings?
But yes, you can get back to the DO “address” either with fetch or non-callback Cloudflare native RPC.
As a side note, my “address” goes all of the way back to a particular browser using JSON RPC. I currently use HTTP between Cloudflare contexts but if I were building it today I would probably use Cloudflare native RPC between Cloudflare contexts. Regardless, it is WebSockets between DO and the browser using Partykit via the Agents DO base class and AgentClient in the browser.
Ignore the word "Agent". I'm not doing anything with LLM agents. I'm just using Agent and AgentClient because the Cloudflare acquisition of PartyKit showed up there and it provides robust WebSocket handling (reconnects, etc.). Plus the Agent scheduler has infinitely better DX than the DO native alarms.
I have open-source my RPC over WebSockets implementation here https://www.npmjs.com/package/json-rpc-mixin
npm
json-rpc-mixin
Expose the public methods of your class as JSON-RPC methods over HTTP or WebSockets. Latest version: 0.0.5, last published: a month ago. Start using json-rpc-mixin in your project by running
npm i json-rpc-mixin. There are no other projects in the npm registry using json-rpc-mixin.2 Replies
I think you mentioned it a few times but what is the benifits/differences of using the agents approach?
I'm not doing lower-case agent (LLM) stuff. I'm just using the Agent as a base class for all of my DOs. There is one big reason for this in my case. It upgrades WebSocket handling. Incoming connections are auto accepted but you still get a callback,
onConnect, to do things like serializeAttachment. It also comes with a browser-based AgentClient that does things like retries, timeouts, and most importantly, reconnects. Think of it as socket.io for Cloudflare hibernating WebSockets. The second reason you might want to use it is that it wraps the DO native alarm functionality with scheduling functionality that has much better DX. For instance, you can have as many scheduled taskes as you want with Agent, but only one with alarms.
The only real extra baggage that it comes with that I don't use is that it has auto-state-synchronization. I don't use it because it because it's designed for a medium to small amount of state per DO and I have fairly fat DOs. The auto-state-synchronization also doesn't utilize SQL. I'm building my own state synchronization right now that will use SQL and support per-entity subscriptions. The Agent state synchronization is all or nothing for DO state.
It's a bit unfortunate that they chose to put the PartyKit stuff under the name Agent, but it is what it is.