cloudflare-pages-static with Functions

[pi0]

Reference: nuxt/framework#110

@warflash
Cloudflare pages for static assets + functions for ssr and dynamic content would be awesome!

[warflash]

Nice! Really looking forward to that.

Related discussions for easy future reference:
https://github.com/nuxt/framework/discussions/2471
https://github.com/nuxt/framework/discussions/1528
#110

@DaniFoldi 🎉

[DaniFoldi]

I'll look into implementing this sometime this week (I have a test repo that works), probably create a draft PR, would be very helpful if someone with more nitro knowledge could take a look

[DaniFoldi]

@warflash I've got nuxt/nuxt#10951 drafted, looking for feedback now

[warflash]

Awesome, great work!
I can't give much feedback on the preset itself but what I did notice is the use of _workers.js.
That reminded me of a conversation on the cloudflare discord I read:

Functions in particular has been interesting (to me, at least). SvelteKit opted for using _worker.js, whereas Remix and Qwik have opted for functions/[[all]].ts.
Plugins should technically work with the later two, but won’t (currently) with SvelteKit, because of that decision. Maybe we encourage SvelteKit to move to the functions folder, or maybe we offer some other way into the Plugins ecosystem. Haven’t quite worked that bit out yet.

That makes it sounds like functions/[[all]].ts is the recommended way forward. I haven't used plugins yet nor am I experienced with nitro presets so I'm not sure how big of a change that is. Figured I'd drop it here in case that's something that's required in the future or when there's people asking about it.

Again, nicely done 🚀

[AlexDicy]

Awesome, great work!
I can't give much feedback on the preset itself but what I did notice is the use of _workers.js.
[...]

Again, nicely done 🚀

I agree. I've also noticed that the code doesn't mention the filename to use when compiling the server.

With my implementation I had to rename the server file from index.mjs to _workers.js (and move it to /public), how is this handled in this PR?

[DaniFoldi]

Correct, should be functions/[[all]].ts for plugin compatibility. Bear in mind plugins are very new, and weren't a thing when I first started experimenting with this combo 😅

Note to future self: In that case we could also have functions/ as the server output directory

[warflash]

Oh actually something else to note on the _workers.js vs. functions/[[all]].ts topic, currently all static asset requests count as function invocations it seems. Though supposedly that will change once pages go out of beta (maybe we'll already see that with next weeks platform week). After beta only actual functions/[[all]].ts calls are billable whereas _workers.js still proxies every static asset. Atleast that's my understanding of the conversations I read.
Maybe @geelen has more insight on that one 🤞

[geelen]

Nah there'll be no difference in terms of billing for functions/[[all]].ts and _workers.js. The current plan is you'll emit a _routes.json as well which can include or exclude paths to run your Worker on. It's not the best api but it's the only way to give frameworks like Nuxt full control over the routing. There are some implementation decisions that are influencing the specifics, but this is the plan.

I think we'll try to bring Plugins into _worker.js builds in the future, since right now it's pretty awkward to use functions/[[all]].ts, except as a straight build output. If you have other files in the functions dir you want to .gitignore [[all.ts]], for example, and it's weird having out and input next to each other in a dir.

But Pages Plugins are new, cool, and it'd be nice to know if they're useful to Nuxt folks.

[DaniFoldi]

@geelen Is the API for this known (even if not yet implemented/available)? If so, would you mind sharing some more details so this PR can implement it properly?

[geelen]

It'll be quite similar to tsconfig include/exclude but the exact wildcard support is not finalised as we need to do some perf testing on a couple of options. Had to be paused while we were finishing off a few other things (https://blog.cloudflare.com/tag/cloudflare-pages/ top 3 links all landed this week).

For now, it's a super good idea if all/most of your assets are under a prefix like /static/* or all your dynamic routes are under a prefix like /api/*. The fewer lines in your _routes.json the better, but we're trying to make it fast enough so it's still good if static and dynamic routes are fully intermingled.

[DaniFoldi]

Quick update from my side, I have @danifoldi/nitropack published to npm for testing (do not use for anything other than a test, I intend to unpublish in a few months).

Check https://nitro-pages-functions.pages.dev/route for a nitro-rendered page and https://nitro-pages-functions.pages.dev/test for a Pages-served static asset. This repo also uses the overrided nitropack to allow some real-world tests.

There's probably something that still won't work, and there will be a bit more work once Functions are in GA and include/exclude system mentioned above can be used to pass static asset requests directly to Pages. Let me know if(when) you find any bug, or anything else that's missing.

[Rigo-m]

@DaniFoldi have you tried deploying nuxt3 by resolving nitropack to your npm repository and deploy it to cloudflare pages? I would like to try it

[DaniFoldi]

@Rigo-m I haven't tried nuxt yet, just a nitro page.

I want to add the documentation first, and we're still working with @danielroe on how to pass bindings to the handlers.