When using #next-on-pages, you have to use Next’s API routes, you can’t use Functions yourself
When using #next-on-pages, you have to use Next’s API routes, you can’t use Functions yourself
Di 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.
HOh, Nuxt
HOops, sorry
HWait, remind me again why you need Advanced Mode?
Di 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
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
this code works fine on local, but when I run it via Cloudflare, the response given back doesn't seem streamy. Contains
[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
HAm I missing something? That just says the Request context, not specifically Advanced Mode
Dthe 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...
without advanced mode it's /functions based routing which does not support streaming? idk...
IFunctions based routing is still inside a
fetchThey 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
Dthanks for the help, I managed to get it working with a server route! 
Jif I'm getting this error, what should I do?
I'm using Astro, if I add
I'm using Astro, if I add
crypto in my vite.ssr.externals, then it doesn't error on build but then says the export is missing when I try to use it.J
Sis rust more performant than js for pages functions?
JIt 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.
JFor 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.
PIs 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.
HAre you using #next-on-pages? If so, you need to use Nextjs's server actions thing
PYes, I am using @Cloudflare/next-on-pages with my project.
HYeah then you want to use https://nextjs.org/docs/pages/building-your-application/routing/api-routes
Next.js supports API Routes, which allow you to build your API without leaving your Next.js app. Learn how it works here.
PI am using App Router mode, so this is the reason that cause pages function not work?
HI 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
Pok, thank you for reply.
RHow 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?
Wwrangler.toml or dash
Rdoes the wrangler.toml sit in the root /functions dir ?
RI get an error :
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'WAs the error says, that's in the future
Wwrangler.toml sits in root (same as workers)
Rthe 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.
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.
WOr set the compat flag -
nodejs_compat_V2WThe compat date just changes the behaviour of
nodejs_compatcompatibility_date = "2024-09-17"
compatibility_flags = ["nodejs_compat_v2"]
That seemed to have done it. thanks.
compatibility_flags = ["nodejs_compat_v2"]
That seemed to have done it. thanks.
Rwoohoo jsonwebtoken now on cloudflare!
�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 ?
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 ?
Hddos protections run before your site and functions, so attacks are stopped before they even hit your service
Hsome requests will still get through ofc but the attacker will get blocked loooooong before 100m requests
�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
�But it's "only" 100k requests so idk if it's the same with a real attack
RHey 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
I uploaded my project on github for reference https://github.com/OptimizeAd/astro-cloudflare-functions
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 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
Contribute to OptimizeAd/astro-cloudflare-functions development by creating an account on GitHub.
HWhen using the Astro Adapter, you must use Astro’s Server Endpoints, not Functions
Rok so build out the API in src/pages/api instead?
AHey 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
Here's how I measure
Can't figure out where's the issue here. Is it the code, or network issues?
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 timing from the Worker is 284 ms while Waiting for server response from the DevTools is at 885 ms—more than 3 times slower.Here's how I measure
total:Can't figure out where's the issue here. Is it the code, or network issues?
NHey 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
Jthere'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/
(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/
AThanks! 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):
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.
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 - the baseline where the request started
eventTimestamp- from the CF logs, I view it as moment when CF has received the request
onRequest start- Worker started its execution
onRequest end- Worker done (the return statement is next line)
Fetch finished- the response got back to the client (total request time, aka TTFB)
- Worker done (the return statement is next line)
- Worker started its execution
- from the CF logs, I view it as moment when CF has received the request
= 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 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
Use Cloudflare Pages for hosting full-stack applications instead of Workers Sites. Do not use Workers Sites for new projects.
AHere's another test where I added a dummy fetch call before the end time measurement to make sure the time is accurate:
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?
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?
Wgot a url i can hit?
