👋 I have a NuxtJS project hosted on Cloudflare Pages. I have the need for an advanced mode Worker f

Ddatashaman 👋 I have a NuxtJS project hosted on Cloudflare Pages. I have the need for an ad...

H

Hello, I’m Allie!•9/1/24, 5:24 PM

When using #next-on-pages, you have to use Next’s API routes, you can’t use Functions yourself

HHello, I’m Allie!When using #next-on-pages, you have to use Next’s API routes, you can’t use Func...

D

datashamanOP•9/1/24, 5:43 PM

i went for a beer and realized that the nuxt adapter (or whatever) must be using _worker.js to do its work. I remember seeing a whole _worker.js/ folder being generated. So either I need an escape hatch in Nuxt, I need to change frameworks, or I must create a separate worker which does the dirty work. Thanks for the reply! I think I know how to proceed now.

H

Hello, I’m Allie!•9/1/24, 6:23 PM

Oh, Nuxt

H

Hello, I’m Allie!•9/1/24, 6:23 PM

Oops, sorry

Ddatashaman i went for a beer and realized that the nuxt adapter (or whatever) must be using...

H

Hello, I’m Allie!•9/1/24, 6:24 PM

Wait, remind me again why you need Advanced Mode?

HHello, I’m Allie!Wait, remind me again why you need Advanced Mode?

D

datashamanOP•9/1/24, 7:06 PM

i am streaming OpenAI responses from AssistantStream, reflecting them into a ReadableStream to give to the browser.
this code works fine on local, but when I run it via Cloudflare, the response given back doesn't seem streamy. Contains

[Object object]

[Object object]

[Object object]

[Object object] response instead of doing the SSE thing.
so i reckon something in the way nuxt works or in the marshalling of the events is not working correctly.
my read of the docs led to the mention of Stream API use in Page functions which mentions that it only works in Advanced Mode.
https://developers.cloudflare.com/workers/runtime-apis/streams/#common-issues

Ddatashaman i am streaming OpenAI responses from AssistantStream, reflecting them into a Re...

H

Hello, I’m Allie!•9/1/24, 7:20 PM

Am I missing something? That just says the Request context, not specifically Advanced Mode

HHello, I’m Allie!Am I missing something? That just says the Request context, not specifically Adv...

D

datashamanOP•9/1/24, 7:25 PM

the way i read it is it can only be run inside a fetch handler function, which you can only do in advanced mode.
without advanced mode it's /functions based routing which does not support streaming? idk...

Ddatashaman the way i read it is it can only be run inside a fetch handler function, which y...

I

Isaac McFadyen•9/2/24, 12:46 AM

Functions based routing is still inside a

fetch

fetch

handler.

I

Isaac McFadyen•9/2/24, 12:47 AM

They just say that to mean that you can't do it outside of the fetch handler, like in the global scope. But a Nuxt API route should be inside the

fetch

fetch

handler generated internally by Pages.

IIsaac McFadyen They just say that to mean that you can't do it *outside* of the fetch handler, ...

D

datashamanOP•9/2/24, 3:51 AM

thanks for the help, I managed to get it working with a server route!

J

jjjrmy•9/3/24, 9:26 PM

if I'm getting this error, what should I do?

Cannot bundle Node.js built-in "crypto" imported from "../node_modules/oauth/lib/oauth.js". Consider disabling ssr.noExternal or remove the built-in dependency.

Cannot bundle Node.js built-in "crypto" imported from "../node_modules/oauth/lib/oauth.js". Consider disabling ssr.noExternal or remove the built-in dependency.

Cannot bundle Node.js built-in "crypto" imported from "../node_modules/oauth/lib/oauth.js". Consider disabling ssr.noExternal or remove the built-in dependency.

Cannot bundle Node.js built-in "crypto" imported from "../node_modules/oauth/lib/oauth.js". Consider disabling ssr.noExternal or remove the built-in dependency.

I'm using Astro, if I add

crypto

crypto

crypto

crypto in my

vite.ssr.externals

vite.ssr.externals

vite.ssr.externals

vite.ssr.externals, then it doesn't error on build but then says the export is missing when I try to use it.

J

jjjrmy•9/9/24, 10:34 PM

[commonjs--resolver] [plugin vite:resolve] Cannot bundle Node.js built-in "util" imported from "../node_modules/knex/lib/dialects/sqlite3/index.js". Consider disabling ssr.noExternal or remove the built-in dependency.

[commonjs--resolver] [plugin vite:resolve] Cannot bundle Node.js built-in "util" imported from "../node_modules/knex/lib/dialects/sqlite3/index.js". Consider disabling ssr.noExternal or remove the built-in dependency.

[commonjs--resolver] [plugin vite:resolve] Cannot bundle Node.js built-in "util" imported from "../node_modules/knex/lib/dialects/sqlite3/index.js". Consider disabling ssr.noExternal or remove the built-in dependency.

[commonjs--resolver] [plugin vite:resolve] Cannot bundle Node.js built-in "util" imported from "../node_modules/knex/lib/dialects/sqlite3/index.js". Consider disabling ssr.noExternal or remove the built-in dependency.

J

jjjrmy•9/9/24, 10:34 PM

https://blog.cloudflare.com/more-npm-packages-on-cloudflare-workers-combining-polyfills-and-native-code/

S

Samantas5855•9/13/24, 5:11 PM

is rust more performant than js for pages functions?

J

James•9/14/24, 12:31 AM

It depends what kind of work you're doing, but generally not for most things, no. Workers (and therefore Pages) run V8, so there's always going to be some minor overhead when running anything other than JS.

J

James•9/14/24, 12:31 AM

For most things, that overhead will be minimal, and Rust can make some more CPU-heavy operations easier to manage. But for your average web request/response handling, I'd stick with JS unless you have a good reason to use Rust.

P

paulcq6173•9/16/24, 2:05 PM

Is cloudflare pages function work with Next.js? I set up /functions/api/test.ts at the root of my Next.js project, then use wrangler to preview, on router /api/test only got 404.

Ppaulcq6173 Is cloudflare pages function work with Next.js? I set up /functions/api/test.ts ...

H

Hard@Work•9/16/24, 2:07 PM

Are you using #next-on-pages? If so, you need to use Nextjs's server actions thing

P

paulcq6173•9/16/24, 2:09 PM

Yes, I am using @Cloudflare/next-on-pages with my project.

Ppaulcq6173 Yes, I am using @Cloudflare/next-on-pages with my project.

H

Hard@Work•9/16/24, 2:10 PM

Yeah then you want to use https://nextjs.org/docs/pages/building-your-application/routing/api-routes

Routing: API Routes | Next.js

Next.js supports API Routes, which allow you to build your API without leaving your Next.js app. Learn how it works here.

P

paulcq6173•9/16/24, 2:14 PM

I am using App Router mode, so this is the reason that cause pages function not work?

Ppaulcq6173 I am using App Router mode, so this is the reason that cause pages function not ...

H

Hard@Work•9/16/24, 2:15 PM

I don't think so. If you use SSR of any kind with Next, then you need to use Next's API system instead of Functions

P

paulcq6173•9/16/24, 2:17 PM

ok, thank you for reply.

R

Ricky U•9/17/24, 11:06 AM

How do enable the compatibility flag using pages functions so i can use jsonwebcrypto? And is it the same using wrangler pages dev ./dist in local env?

W

Walshy•9/17/24, 11:10 AM

wrangler.toml or dash

R

Ricky U•9/17/24, 11:15 AM

does the wrangler.toml sit in the root /functions dir ?

R

Ricky U•9/17/24, 11:16 AM

I get an error :

MiniflareCoreError [ERR_FUTURE_COMPATIBILITY_DATE]: Compatibility date "2024-09-23" is in the future and unsupported

MiniflareCoreError [ERR_FUTURE_COMPATIBILITY_DATE]: Compatibility date "2024-09-23" is in the future and unsupported

MiniflareCoreError [ERR_FUTURE_COMPATIBILITY_DATE]: Compatibility date "2024-09-23" is in the future and unsupported

MiniflareCoreError [ERR_FUTURE_COMPATIBILITY_DATE]: Compatibility date "2024-09-23" is in the future and unsupported when running 'npx wrangler pages dev ./dist --compatibility-date=2024-09-23'

W

Walshy•9/17/24, 11:19 AM

As the error says, that's in the future

W

Walshy•9/17/24, 11:19 AM

wrangler.toml sits in root (same as workers)

R

Ricky U•9/17/24, 11:20 AM

the docs : https://blog.cloudflare.com/more-npm-packages-on-cloudflare-workers-combining-polyfills-and-native-code/
say that in order top use new modules such as jsonwebtoken (which i am trying to do) i need a compat date of 2024-09-23 or later.

W

Walshy•9/17/24, 11:21 AM

Or set the compat flag -

nodejs_compat_V2

nodejs_compat_V2

nodejs_compat_V2

nodejs_compat_V2

W

Walshy•9/17/24, 11:21 AM

The compat date just changes the behaviour of

nodejs_compat

nodejs_compat

nodejs_compat

nodejs_compat flag

R

Ricky U•9/17/24, 11:24 AM

compatibility_date = "2024-09-17"
compatibility_flags = ["nodejs_compat_v2"]

That seemed to have done it. thanks.

R

Ricky U•9/17/24, 11:26 AM

woohoo jsonwebtoken now on cloudflare!

�

🍋 Pandeo 🍋•9/19/24, 2:09 PM

Hello, i have a nextjs app and i want to host using Cloudflares Pages and i was figuring that the SSR part is consuming pages functions resources. And that resources is limited to 10m requests per month (and after it's 0.5$/m requests).
In the case where someone try to http flood me and generate 100m requests in 10 minutes, did i will be billed for those requests ?
And if yes, how can i avoid this problem by caching the pages functions or doing something else ?

�🍋 Pandeo 🍋Hello, i have a nextjs app and i want to host using Cloudflares Pages and i was ...

H

hfcRed•9/20/24, 1:53 PM

ddos protections run before your site and functions, so attacks are stopped before they even hit your service

H

hfcRed•9/20/24, 1:53 PM

some requests will still get through ofc but the attacker will get blocked loooooong before 100m requests

�

🍋 Pandeo 🍋•9/20/24, 1:54 PM

kk. Because i have tested it with the free tier and after my 100k request i have stopped my test to not block me for 10 days

�

🍋 Pandeo 🍋•9/20/24, 1:54 PM

https://media.discordapp.net/attachments/1252404589861277842/1286357950725886148/image.png?ex=66ee4672&is=66ecf4f2&hm=f364dffb2bfb1d7fa395dd08e107e7565599f4f034da1f95a44be8f547d4fbd1&=&format=webp&quality=lossless

�

🍋 Pandeo 🍋•9/20/24, 1:55 PM

But it's "only" 100k requests so idk if it's the same with a real attack

R

Rennology•9/20/24, 11:12 PM

Hey guys, I've spent the last two days trying to figure this out and still scratching my head..

I setup a clean install of an astro site with wrangler. Enabled directory mode and added a simple endpoint in functions/api/index.js. When I run

npm run preview

npm run preview

npm run preview

npm run preview and I try to hit that endpoint using the server URL I just get a 404 error. Where am I going wrong here?

I uploaded my project on github for reference https://github.com/OptimizeAd/astro-cloudflare-functions

GitHub

GitHub - OptimizeAd/astro-cloudflare-functions

Contribute to OptimizeAd/astro-cloudflare-functions development by creating an account on GitHub.

RRennology Hey guys, I've spent the last two days trying to figure this out and still scrat...

H

Hello, I’m Allie!•9/20/24, 11:13 PM

When using the Astro Adapter, you must use Astro’s Server Endpoints, not Functions

R

Rennology•9/20/24, 11:16 PM

ok so build out the API in src/pages/api instead?

A

Andrei•9/21/24, 10:37 PM

Hey everyone! Anybody encountered slow functions response times?

Recently finished a migration to CF Pages of one of my Remix apps. The issue is that "Waiting for server response" timing is much slower than the whole duration of the function itself.

The

total

total

total

total timing from the Worker is 284 ms while

Waiting for server response

Waiting for server response

Waiting for server response

Waiting for server response from the DevTools is at 885 ms—more than 3 times slower.

Here's how I measure

total

total

total

total:

export async function onRequest(
  context: EventContext<unknown, string, unknown>,
) {
  const start = performance.now()
  const response = await createPagesFunctionHandler({ build, getLoadContext })(
    context,
  )
  const end = performance.now()
  response.headers.append("Server-Timing", `total;dur=${end - start}`)
  return response
}

export async function onRequest(
  context: EventContext<unknown, string, unknown>,
) {
  const start = performance.now()
  const response = await createPagesFunctionHandler({ build, getLoadContext })(
    context,
  )
  const end = performance.now()
  response.headers.append("Server-Timing", `total;dur=${end - start}`)
  return response
}

export async function onRequest(
  context: EventContext<unknown, string, unknown>,
) {
  const start = performance.now()
  const response = await createPagesFunctionHandler({ build, getLoadContext })(
    context,
  )
  const end = performance.now()
  response.headers.append("Server-Timing", `total;dur=${end - start}`)
  return response
}

export async function onRequest(
  context: EventContext<unknown, string, unknown>,
) {
  const start = performance.now()
  const response = await createPagesFunctionHandler({ build, getLoadContext })(
    context,
  )
  const end = performance.now()
  response.headers.append("Server-Timing", `total;dur=${end - start}`)
  return response
}

Can't figure out where's the issue here. Is it the code, or network issues?

AAndrei Hey everyone! Anybody encountered slow functions response times? Recently finis...

N

nahuelluca•9/23/24, 5:33 PM

Hey i have the same issue, using Remix with d1 the response for a request with size at 1.3kb is the 2 or 3 secons

J

juanferreras•9/23/24, 6:08 PM

there's a lot of factors that can be happening under each scenario – but one that I understand would usually apply to all is that the larger the total amount of gzipped code your CF Pages bundles, the more expensive the overall worker startup time becomes. There's upcoming work (a new module registry being developed in workerd runtime) which would break from this and lazily eval when using dynamic imports (which most adapters/etc already do) . https://github.com/cloudflare/workerd/issues/2372

(there might as well be other factors with D1, with Remix itself, general connectivity, etc. that I'm not particularly aware of)

EDIT: actually – one thing worth trying would be to enable Smart Placement and re-deploying to see if it significantly lowers those values https://developers.cloudflare.com/workers/configuration/smart-placement/

Jjuanferreras there's a lot of factors that can be happening under each scenario – but one tha...

A

Andrei•9/23/24, 10:01 PM

Thanks! I've quickly looked through this GH issue, some folks even suggested there's a difference between Pages Functions and Workers, which is very interesting. However, since I'm hosting a full-stack website Cloudflare itself doesn't recommend using Workers Sites for that and instead suggests CF Pages, which I'm using right now.

In any case, I've done some tests with manual requests and there's some interesting statistics. Here's the data on the screenshot (timeline-like, everything in ms):

Fetch started

Fetch started

Fetch started

Fetch started

the baseline where the request started
```
eventTimestamp
```
eventTimestamp
```
eventTimestamp
```
eventTimestamp
- from the CF logs, I view it as moment when CF has received the request
```
onRequest start
```
  onRequest start
```
onRequest start
```
  onRequest start
  - Worker started its execution
    onRequest end
    onRequest end
    onRequest end
    onRequest end
    - Worker done (the return statement is next line)
      Fetch finished
      Fetch finished
      Fetch finished
      Fetch finished
      - the response got back to the client (total request time, aka TTFB)

Client -> Cloudflare

 = simply

= simply

 = simply

= simply eventTimestamp

Worker execution

=

= onRequest start

-

- onRequest end

Cloudflare -> Client

=

= Fetch finished

-

- onRequest end



You can see that the most amount of time is actually spent on the way from the worker to the client.

There could be a mistake where the measured Worker end time is not correct since the



You can see that the most amount of time is actually spent on the way from the worker to the client.

There could be a mistake where the measured Worker end time is not correct since the



You can see that the most amount of time is actually spent on the way from the worker to the client.

There could be a mistake where the measured Worker end time is not correct since the



You can see that the most amount of time is actually spent on the way from the worker to the client.

There could be a mistake where the measured Worker end time is not correct since the

Date.now` only advances on I/O in workerd. I'll test this a bit later.

Another potential reason is that CF does some post-processing magic which is somehow more time consuming than the worker itself. This is also weird since I haven't turned on any CF features like WAF, cache rules, rewrites and etc.

Cloudflare Docs

Workers Sites | Cloudflare Workers docs

Use Cloudflare Pages for hosting full-stack applications instead of Workers Sites. Do not use Workers Sites for new projects.

A

Andrei•9/23/24, 10:11 PM

Here's another test where I added a dummy fetch call before the end time measurement to make sure the time is accurate:

export async function onRequest(
  context: EventContext<unknown, string, unknown>,
) {
  console.log("onRequest start", new Date().toISOString())
  
  const response = await createPagesFunctionHandler({ build, getLoadContext })(
    context,
  )
  
  await fetch("https://httpbin.org/get")
  console.log("onRequest end", new Date().toISOString())
  return response
}

export async function onRequest(
  context: EventContext<unknown, string, unknown>,
) {
  console.log("onRequest start", new Date().toISOString())
  
  const response = await createPagesFunctionHandler({ build, getLoadContext })(
    context,
  )
  
  await fetch("https://httpbin.org/get")
  console.log("onRequest end", new Date().toISOString())
  return response
}

export async function onRequest(
  context: EventContext<unknown, string, unknown>,
) {
  console.log("onRequest start", new Date().toISOString())
  
  const response = await createPagesFunctionHandler({ build, getLoadContext })(
    context,
  )
  
  await fetch("https://httpbin.org/get")
  console.log("onRequest end", new Date().toISOString())
  return response
}

export async function onRequest(
  context: EventContext<unknown, string, unknown>,
) {
  console.log("onRequest start", new Date().toISOString())
  
  const response = await createPagesFunctionHandler({ build, getLoadContext })(
    context,
  )
  
  await fetch("https://httpbin.org/get")
  console.log("onRequest end", new Date().toISOString())
  return response
}

The worker execution time is of course a bit longer due to this new fetch request. Yet the trend remains: a ton of time is spent after the worker is finished.

Do you have any ideas on what might be happening during that time?

👋 I have a NuxtJS project hosted on Cloudflare Pages. I have the need for an advanced mode Worker f

Similar Threads

Similar Threads

Similar Threads