Doesn't make all too much sense when the server actions are only being called client side though 🤔
Doesn't make all too much sense when the server actions are only being called client side though 
Zdoes edge runtime actuall work? All my page return 404 with edge runtime, It does not work with this simplest demo:
// src/app/page.tsx
export const runtime = "edge";
export default function Home() {
return <div>Hello from the edge!</div>;
}
// src/app/page.tsx
export const runtime = "edge";
export default function Home() {
return <div>Hello from the edge!</div>;
}
HI'm not sure I understand your point? Yes, they are invoked by something on the client, but they still run on the server, and thus must obey the size limits the server has
FI don't understand why they're being bundled together with the page, pushing it over the size limit. It's like if all my API routes got combined into one, and then also got combined with the pages in which they're used. It wouldn't make much sense, because they should all be independent and all have their own size limit.
I may be using them wrong but I'm using server actions as a replacement for my API routes(at least ones that mutate data), but it seems that just using them instead makes for a less efficient app because everythings bundled together like it wouldn't otherwise be?
(I do realize I can easily avoid this problem by just using API routes instead but that's much less convenient)
I may be using them wrong but I'm using server actions as a replacement for my API routes(at least ones that mutate data), but it seems that just using them instead makes for a less efficient app because everythings bundled together like it wouldn't otherwise be?
(I do realize I can easily avoid this problem by just using API routes instead but that's much less convenient)
HIt's not being bundled with the page. All things that happen on the server(SSR stuff, Server Actions, API Routes, the actual Router) are uploaded together, and if they go over the limit, then it throws that error
FSo that error means all my server code combined is too big?
HYes, though as Nob noted, the Paid Workers plan has larger Server size limits
FHow can I determine how big my site(or whatever is included in the size of a function) actually is then? I thought it might be
.vercel/output/static/_worker.js but that's only 27KB for meHDo you see any import statements within that file?
FI do but they're dynamic without exact paths.
Looks like maybe it's importing things in
That file though has the name of the route to my page I used the server actions on. The server actions are quite literally what my API routes were(and looking through old build logs the API routes totaled < 100KB).
I'm trying to convert back to API routes to see what happens. Could be maybe that compression or minimization is worse when everything is in one route?
Looks like maybe it's importing things in
__next-on-pages-dist__/functions/ in which case there is a file there that's over 1MB.That file though has the name of the route to my page I used the server actions on. The server actions are quite literally what my API routes were(and looking through old build logs the API routes totaled < 100KB).
I'm trying to convert back to API routes to see what happens. Could be maybe that compression or minimization is worse when everything is in one route?
HIt shouldn't be
FOk think I figured out my issue... My page was static before, but I forgot I switched it to the edge runtime to use actions... 
Knowing I can't use edge runtime without being over the max size, without paying I really am just going to have to stick to API routes?
Knowing I can't use edge runtime without being over the max size, without paying I really am just going to have to stick to API routes?
Nyou should be able to use server actions without paying
Nmaybe you use a lib thats too big
S`
When I try use cache keys in fetch request, I get "The 'cache' field on 'RequestInitializerDict' is not implemented." What is the correct way of caching this data with next-on-pages?
When I try use cache keys in fetch request, I get "The 'cache' field on 'RequestInitializerDict' is not implemented." What is the correct way of caching this data with next-on-pages?
SDocumentation(https://github.com/cloudflare/next-on-pages/blob/main/packages/next-on-pages/docs/caching.md) is very vague, it first says "Caching in Next.js applications (thus applications built using @Cloudflare/next-on-pages as well) is enabled by default." But then, it talks about two storage options. There is no sample for either option...
GitHub
CLI to build and develop Next.js apps for Cloudflare Pages - cloudflare/next-on-pages
SBy the way, If I leave this as it is data is not cached...
IThe
cache field doesn't work on workers runtime. You can try next.revalidate: false to force cacheISi did that, but it's not working either, maybe I am having the same issue with these guys: https://github.com/cloudflare/next-on-pages/issues/799
GitHub
next-on-pages environment related information System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 23.5.0: Wed May 1 20:17:33 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6031 CPU...
Si started using my own implementation
Sand it's working, so I guess something is broken with the library
JHi again. I've upgraded my cloudy repo to Next.js 14.2.4 but I'm not encountering this issue. Is there any specific logic happening on pages/routes where you're encountering it?
JCalling an action makes a HTTP request to the current page the action is being called from, so their code is included as part of the function for the page.
RCan I create an async queue consumer or is there any other way to perform an action in background/ response a for webhook
DI had a similar error, fixed with the edge runtime included in my server side component
WI have a server side component (/api) that does the connection between Resend and my app.
My question is, I have to do something on my Cloudflare Dashboard so that this works?
My question is, I have to do something on my Cloudflare Dashboard so that this works?
WBecause before I deployed my app it worked and after deploying it, it gives Internal Server Error
Jwhat is the error that it's logging
SDoes anyone know how to run a cronjob with next-on-pages, nextjs 14?
HPages doesn’t support Crons
NHey all 
I deployed a fresh nextjs app using pages + wrangler and its awesome!
I have an existing nextjs app that was not bootstrapped using
I'm wondering if its possible to opt-in after the fact and still be able to deploy to cloudflare?
I deployed a fresh nextjs app using pages + wrangler and its awesome!
I have an existing nextjs app that was not bootstrapped using
npx create cloudflare I'm wondering if its possible to opt-in after the fact and still be able to deploy to cloudflare?
NLooks like there's a good amount of trimming I'd need to do to get this project able to run on the edge
Nwas pretty easy for me
NSome of my configs rely on
node:url and node:fsNmaybe if you have some unsupported dependencies you might have to find workarounds
NHow do you find out which package is incompatible?
LHi! Does anyone have experience or a guide on how to migrate from Next on Pages to a barebones "Next on Workers" implementation? Logs and Cron requirements are making things a bit impossible to continue.
JNot sure I understand what you mean by 'next on workers'. Our CLI generates a worker which is deployed as part of your pages deployment. if you wanted, you could modify the worker we generate if that's the kind of thing you want to do?
NKV or Durable Objects seem good for that
NKV is very cheap
Nso it should not be that expensive just to check a value in kv
Nonce the guy exceeds the limit you don't have to write anymore
N5$/million is not that much
Nand cloudflare cdn already protects you before workers
