MissS
MissS
Explore posts from servers
CDCloudflare Developers
Created by MissS on 11/10/2024 in #workers-help
Queue consumer from nextjs worker
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
2 replies
CDCloudflare Developers
Created by henrikhlind on 11/6/2024 in #workers-help
Nest.js as Worker
Decorators and stuff probably won't work. Feels very hacky
3 replies
CDCloudflare Developers
Created by MissS on 10/25/2024 in #workflows-beta
Oh also, is there a way to limit
There isn't subrequest limits for service bindings (as a whole), since a service binding doesn't count as a subrequest
7 replies
CDCloudflare Developers
Created by MissS on 10/25/2024 in #workflows-beta
Oh also, is there a way to limit
Oh, so if you use a service binding, it doesn't go over the internet and therefor doesn't get counted as a "subrequest". Therefor, you can stop & restart workflows forever
7 replies
CDCloudflare Developers
Created by MissS on 10/25/2024 in #workflows-beta
Oh also, is there a way to limit
Wait really? Workflows don't have subrequest limits?
7 replies
CDCloudflare Developers
Created by MissS on 10/25/2024 in #workflows-beta
Oh also, is there a way to limit
How would you ensure that there is always one and only one "Manager" workflow running at all times?
7 replies