Queue consumer from nextjs worker

I'm trying to figure out what the project structure would look like if you're using the nextjs framework and you're deploying to workers. Supposedly, worker nextjs should support effectively all services (creating durable objects, workflows, service bindings). But where would all of those worker specific files be located? They wouldn't be in the app/api/[route] for nextjs backend routes. Do people just make a seperate folder at the root for all "worker functions"? Any examples people can point to?
1 Reply
MissS
MissSOP5w ago
Ah, so after some reading and asking perplexity, it seems like the following is the correct answer.
project-root/

├── next-app/
│ ├── pages/
│ │ ├── api/
│ │ │ └── user.js
│ │ ├── index.js
│ │ └── ...
│ ├── public/
│ ├── styles/
│ ├── components/
│ ├── next.config.js
│ ├── package.json
│ └── wrangler.toml

├── workers/
│ ├── auth-worker/
│ │ ├── src/
│ │ │ └── index.js
│ │ └── wrangler.toml
│ │
│ ├── user-worker/
│ │ ├── src/
│ │ │ └── index.js
│ │ └── wrangler.toml
│ │
│ └── data-worker/
│ ├── src/
│ │ └── index.js
│ └── wrangler.toml

└── README.md
project-root/

├── next-app/
│ ├── pages/
│ │ ├── api/
│ │ │ └── user.js
│ │ ├── index.js
│ │ └── ...
│ ├── public/
│ ├── styles/
│ ├── components/
│ ├── next.config.js
│ ├── package.json
│ └── wrangler.toml

├── workers/
│ ├── auth-worker/
│ │ ├── src/
│ │ │ └── index.js
│ │ └── wrangler.toml
│ │
│ ├── user-worker/
│ │ ├── src/
│ │ │ └── index.js
│ │ └── wrangler.toml
│ │
│ └── data-worker/
│ ├── src/
│ │ └── index.js
│ └── wrangler.toml

└── README.md
In this structure: 1. The next-app directory contains your Next.js application. 2. The workers directory contains separate directories for each Cloudflare Worker. 3. Each Worker has its own wrangler.toml file for configuration. 4. The Next.js app's wrangler.toml would include service bindings to the Workers. For example, in the Next.js app's wrangler.toml:
[[services]]
binding = "AUTH"
service = "auth-worker"

[[services]]
binding = "USER"
service = "user-worker"

[[services]]
binding = "DATA"
service = "data-worker"
[[services]]
binding = "AUTH"
service = "auth-worker"

[[services]]
binding = "USER"
service = "user-worker"

[[services]]
binding = "DATA"
service = "data-worker"
Then, in your Next.js API routes, you can use these service bindings. For example, in pages/api/user.js:
import { getRequestContext } from '@cloudflare/next-on-pages';

export default async function handler(req, res) {
const { env } = getRequestContext();

// Use the USER service binding
const userResponse = await env.USER.fetch(req);
const userData = await userResponse.json();

res.status(200).json(userData);
}
import { getRequestContext } from '@cloudflare/next-on-pages';

export default async function handler(req, res) {
const { env } = getRequestContext();

// Use the USER service binding
const userResponse = await env.USER.fetch(req);
const userData = await userResponse.json();

res.status(200).json(userData);
}
This structure allows you to separate concerns between your Next.js app and various Cloudflare Workers, while still enabling efficient communication between them through service bindings
Want results from more Discord servers?
Add your server