Is there a simple way to use Cloudflare Durable Objects/Workflows/etc ATM?

[franciscohermida]

I know there's some work in progress at the moment, but it doesn't have to be perfect. Is there a vendor locked way to define the durable objects/workflow classes myself and have them work through the bindings event.context.cloudflare.env.MyServer, and only use Nitro to define the routes for the worker entrypoint?

I got it to a state that at least it starts without errors (using custom preset as suggested in the docs), but it doesn't support durable objects rpc calls and I'm also struggling with the websocket part.

I spent many hours trying to figure out how to do any of this, but got more confused as time passed.

I wanted to create a simple Nuxt PartyKit Starter, similar to what I have done with Vue here:
https://github.com/franciscohermida/partyvite-vue

Is this not possible at all even as a temporary hybrid thing?

[TheAlexLichter]

See #3048 and #2801 for the experimental preset

[franciscohermida]

I've seen that, but those are limited work-in-progress features that will be great once they're ready. There is no documentation or example showing how to implement a Workflow or create a Partykit server and things like that.

I'm looking for a way to have full access to cloudflare classes without nitro wrapping it with its own api. As if you could copy and paste code from the Cloudflare docs and have it work seamlessly in Nitro, with Nitro primarily handling routing. Maybe a configuration that let you define a path to your own file where you can define custom durable object classes, workflows, then you access via event.context.cloudflare.env... bypassing everything nitro related from this point.

Can you confirm that this isn't possible with Nitro at the moment? Not sure if it is a problem that would only be solved with nitro v3, h3 v2 etc using web standards.

I'm assuming that the complexity of achieving the setup I'm proposing would be less than the usual Unjs approach creating its own api to avoid vendor lock-in. It would go against the Unjs philosophy temporarily but at least it would allow people to have one foot in the Unjs ecosystem vs going elsewhere where this is supported.

This is not a negative criticism, I'm very new to nuxt/nitro/unjs ecosystem. I know things take time to do properly. A simple "no this is not possible at all in Nitro atm and there is no ETA" would be greatly appreciated so I can move on with my plans, instead of spending hours/days figuring out if it is possible to do by myself.

[pi0]

Is there a simple way to use Cloudflare Durable Objects/Workflows/etc ATM

YES. via the cloudflare-durable preset.

Nitro has a decent/zeroconfig integrated WebSocket API (via crossws) compatible with Durable Objects which is a replacement for partyserver, if you have any feedback about improving this layer, it is more than welcome.

In addition to WebSockets, #3048 (available in the nightly channel) enables Durable Objects to handle any route and access to class instance and Durable storage/db.

In the next steps, we plan to also expose an API to access custom durable object instances from the main server + ability to communicate with it via RPC to improve flexibility.

Since the output of each project is "one server bundle", there will be only one durable object class (with multiple instances) with the ability to communicated via RPC.

Usage of Durable Objects is different in Nitro (but much much much simpler + pluggable) than what cloudflare DX offers and I value your feedback about any limitations you might be facing (from this different API).

[franciscohermida]

Thanks for taking the time to explain this.

So, if I understand correctly, it's not possible to use PartyServer instead of crossws, or any other class extended from durable objects, right? This would also apply to Workflows and any potential new product, which would have to wait for a Nitro implementation before they can be used.

I know you're aiming for a better developer experience than what Cloudflare currently offers, but my concern is that in trying to avoid vendor-lock, we might inadvertently end up with a "vendor-block" instead. The volume of features from vendors to cover and the potential for breaking changes when designing APIs especially when so many frameworks (not only Nuxt) depend on them, makes this a tough challenge without enough manpower.

From a consumer perspective, without understanding all the complexities behind the scenes, why not allow someone to add their own classes to the entry file exported to Cloudflare? That way, you could access everything through bindings in a manner that works during both development and deployment. Aren't these just basic web-standard primitives? This approach would let us tap into any product and various durable object definitions, making it easier to use the available documentation from cloudflare. I could learn one approach and then, when Nitro catches up in terms of documentation and accessibility, have the option to port over to the Nitro way of doing things.

I wish the custom preset setup could be as straightforward as what I tried here:

nuxt.config.ts

export default defineNuxtConfig({
  compatibilityDate: "2025-02-14",
  devtools: { enabled: true },

  nitro: {
    preset: "./preset",
  },

  modules: ["nitro-cloudflare-dev"],
});

preset/nitro.config.ts

import type { NitroPreset } from "nitropack";
import { fileURLToPath } from "node:url";

export default <NitroPreset>{
  extends: "cloudflare_module",
  entry: fileURLToPath(new URL("./entry.mjs", import.meta.url)),
};

preset/entry.ts

import "#internal/nitro/virtual/polyfill";
// my own durable object class
export { MyServer } from "../worker/server";

const nitroApp = useNitroApp();

// ...

and then access like this:
server/api/hello.ts

export default defineEventHandler(async (event) => {
  const id = event.context.cloudflare.env.MyServer.idFromName("hello");
  const stub = event.context.cloudflare.env.MyServer.get(id)
  return await stub.hello();
});

Or even something added directly in the config:

nuxt.config.ts

{
  nitro: {
    preset: "./preset",
    cloudflare: {
      worker: {
        includePaths: ["worker/myDoPartyServer.ts"],
      }
    }
  }
}

Is it correct that this setup isn’t possible with Nitro at the moment?

[pi0]

But my concern is that in trying to avoid vendor-lock, we might inadvertently end up with a "vendor-block" instead

You shouldn't be concerned because as you already figured, you can create and set simple custom entry config (not even a preset is needed) and copy-paste one from here + add any modifications or exports copy-pasted from vendor. Users are not locked into anything, but we don't also advise anyone to do this because by doing this kind of ejection they are on their own. This is the opposite of DX and the stability Nitro aims to make.

Aren't these just basic web-standard primitives

No. DurableObjects and the way WebSocket works with them are not web standards. Layers like crossws are ecosystem standards and it is already fully available.

when Nitro catches up in terms of documentation and accessibility

Nitro already caught up for WebSocket support. your OG is asking about partyserver integration, it has a much better replacement.

Workflows and any potential new product
includePaths: ["worker/myDoPartyServer.ts"]

Actually, this kind of concern is one of the reasons we still have durable object support as experimental. See #2801 (comment)

We might introduce something like this as an advanced option/escape in the future when durable support becomes stable for Nitro.

[franciscohermida]

Not sure if this that I'm about to suggest makes sense, but the last option seems like it should have been the first priority. Having an escape option would have allowed access to most, if not all, of Cloudflare’s offerings by now instead of having support for these features pending/experimental.

You shouldn't be concerned because as you already figured, you can create and set simple custom entry config

I didn’t actually figure it out, I shared how far I got, but I still failed to make it work. If I had made it work, I wouldn’t be here distracting you from more important things which I appreciate that you are here and care🙏. I’m asking because I really like the vision and want to keep using unjs solutions while exploring Cloudflare products. So far it has been easier to understand things from the Cloudflare side than to understand from unjs side.

Users are not locked into anything

I said block not lock which is a bit different and seems to be the case ex: Workflow, RPC (not criticizing, just observing the current state)

your OG is asking about partyserver integration, it has a much better replacement.

Even if crossws is the better option, I’m still curious, why can’t PartyServer be used? Is it not supported?

You shouldn't be concerned
this kind of concern is one of the reasons...

It seems there are reasons for concern in this regard.

To be clear, I’m not demanding or pressuring anything, in fact I'm naively suggesting that perhaps the different prioritization would have allowed for less work/pressure to have more features available sooner even if on a less than ideal DX. I really appreciate you taking the time to answer my questions and correcting any wrong assumptions.