Unable to use Cloudflare's Durable Objects with Remix when using Cloudflare Pages

[davidbarratt]

Currently the only way to use Durable Objects when using Cloudflare Pages is by having a completely separate Worker and communicating with it from Remix.

This is because there is no way to export the Durable Object class from a Pages Function.

However, this can be done in Advanced Mode.

Since Remix takes over all paths anyways (i.e. functions/[[path]].js), why not use _worker.js instead? This would allow the user to modify it at the top level which is more what I would have expected from using Pages with Remix anyways.

There is a (somewhat hacky) workaround.

// server.ts
import { createPagesFunctionHandler } from "@remix-run/cloudflare-pages";
import * as build from "@remix-run/dev/server-build";

const handleRequest = createPagesFunctionHandler({
  build,
  mode: process.env.NODE_ENV,
  getLoadContext: (context) => context.env,
});

interface Env {
  LEAD: DurableObjectNamespace
}

const handler: ExportedHandler<Env> = {
  async fetch(request, env, ctx) {
    return handleRequest({
      request: new Request(request),
      env,
      waitUntil: ctx.waitUntil,
      params: {},
      data: undefined,
      next: () => {
        throw new Error('next() called in Worker')
      }
    });
  }
};

export default handler;

// Durable Object
export { Lead } from '~/do/lead';

// remix.config.js
/**
 * @type {import('@remix-run/dev').AppConfig}
 */
module.exports = {
  serverBuildTarget: "cloudflare-pages",
  server: "./server.ts",
  devServerBroadcastDelay: 1000,
  ignoredRouteFiles: [".*"],
  // appDirectory: "app",
  // assetsBuildDirectory: "public/build",
  serverBuildPath: "public/_worker.js",
  // publicPath: "/build/",
};

This works, but it's not the cleanest implementation.

I think Remix should provide a handler for Pages Functions in "Advanced" mode rather than the simple mode. This would allow you to do more advanced things like working with Durable Objects, etc.

[tom-sherman]

You can define your own worker in the functions/ directory, I think it needs to be in a subfolder though.

Example: tom-sherman/remix-cloudflare-pages-demo#1

[rodbs]

@tom-sherman I don't see the subfolder you mention.

[rodbs]

@davidbarratt I'm suffering the same thing. Is this _worker.js the only workaround to make it work? Still not solution from Remix?

[tom-sherman]

Inside functions/api

[aaronadamsCA]

Another reason for Remix to use _worker.js instead of functions/[[path]].js would be improved flexibility in the following scenarios:

• Compatibility with drag-and-drop deployments, which don't currently support a functions/ directory.
• Better compatibility with the GitHub Action for Cloudflare Pages, which doesn't currently support functions from a monorepo.
  • This is especially important because direct upload is currently the only method to deploy from a monorepo to Cloudflare Pages.

Right now, it seems our only option to deploy a Remix app from a monorepo to Cloudflare Pages using GitHub Actions is to write our own JS workflow. Granted, improvements to Cloudflare Pages would resolve this; but so would Remix using _worker.js, FWIW.

[aaronadamsCA]

NP. That PR is merged, now we just need cloudflare/pages-action#56 merged and it should be functionally equal to the fork.

[ChristianJacobsen]

Perfect! That and a new release, and we should be good to go 🎉 Thanks for the amazing work!

[hiendaovinh]

Hi, do we have any updates on this?

[praneybehl]

Yeah looking for the same, did it ever make it out?

[aaronadamsCA]

If we're talking about the OP issue, no, I am pretty sure functions/[[path]].ts remains the only way to use Remix with Cloudflare Pages.

If we're talking about the specific fixes to the Cloudflare Pages action to support monorepos, yes, those changes went out long ago—although if I were implementing from scratch, I would strongly suggest using the Wrangler action instead, since the Pages action is of really poor quality.

[candidia]

Has anything changed, especially with vite now?