The Experience of Deploying Next.js Apps on Cloudflare
I don't wanna bash Vercel for building a React based framework and then making you suffer to use it elsewhere outside of "their cloud" because that would be unfair. I have experienced similarly to you using Cloudflare Workers AI. The documentation wasn't up to date and I also encountered Wrangler CLI issues as described in the article you wrote. There's no one to blame, but everyone honestly. And I feel this is the reason the dokku/self-hosting community hive mind is having such a strong comeback. Funnily enough there is a correlation between self hosting and old school framework like RoR Django and Laravel...
For my personal blog hosted on Cloudflare I am using Hexo.js - not as cool as Next but does the job and I can deploy it from gitlab using their Ci/Cd pipeline
This mostly seems the result of Cloudflare idiosyncrasies though. I don't recognise many of these commands (eg what is wrangler?), but we're running it as a regular Node app on a regular server, and it doesn't feel second-class at all.
What are you using it for?
I'm assuming you mean what Next.js features we're using? I think we're putting it properly through its paces, using the app router, server actions, image optimisation, middleware, etc. I don't think we've encountered anything we could do because of our setup.
Anything you could do? What do you mean by that? Did you mean you "couldn't do"?
Sorry yes, "couldn't do"! What an unfortunate mistake, completely changes the meaning.
I love cloudflare pages, but it is certainly not perfect. For me, the weakest point about cloudflare pages is logging. One would expect some minimum support for out of the box searchable logs, but there is none.
Using the Node ecosystem for frontend development feels riskier every day, but at least the attack surface there is limited to development machines and the browser sandbox. I can sort of live with that. But I have a hard time finding trust in using it for backend processes.
In, say, the JVM or .NET ecosystems one can limit their dependencies to a handful of libraries that come from reputable sources. What is keeping us from folding some of the basic JavaScript libraries into a few larger ones?
And even more importantly, what evolutional forces have brought us into this state? Is it that frontend developers are more extraverted and share their inferior creations more actively? Are frontend developers more obsessed with shiny new things because they work on the visible parts of software development? Would understanding this help with finding a nice way forward?
What's your main concern, the npm modules?
If you don't `npm config set ignore-scripts true` then you are basically executing random unknown code every time you do an `npm install`. Modules can change hands and become malicious, which is much more plausible when there are thousands of sub-dependencies in a pretty standard modern web app.
My main concern is the impossibility of finding trust in library dependencies. A typical React app has somewhere over 2,000 packages from almost as many different sources. It is impossible to check the reputability of each contributor.
I'm aware of things like "npm audit", but with the amount of false positives that spews out, it seems one just has to trust the entire ecosystem.
My intuition keeps telling me that this is a disaster waiting to happen, and I'm trying to understand how this can be so pervasive.
Your comparison isnt apples to apples. It seems to me like you are trying to compare a full node deployment on vercel serverless (as opposed to edge) with an edge runtime deployment on cloudflare. You would have this same problem of 3rd party module support (those which use the node APIs) using the edge runtime on vercel edge.
You even say cloudflare is using “nodejs isolates” which they aren’t - they are using v8 isolates, so your expectation of nodejs compatibility is the issue.
https://nextjs.org/docs/app/building-your-application/render...
OP Here.
I am actually comparing Edge deployments on both. I made a lot of points about the Cloudflare overall experience outside of the Edge bit. Obviously, in Vercel you can go with Edge or more regular Node.js, and that flexibility is quite nice.
Also, yes, I meant to say "v8 isolates", that was a typo. (Fixed now)
I've setup my static (hugo) blog on Cloudflare Pages and was very pleasantly surprised by the ease of setup and how fast they start build jobs after my github's commit. The fact that you can setup a custom domain and get SSL certs all for free with their vast CDN was a nice touch too.
I found them lacking in the department of logging and debug, my custom tailwind theme minification throws away used style classes even with Safelist specified in tailwind.config.js and I couldn't figure out why - it doesn't happen on my machine. In the end I left tailwind -minify flag out.
> I've setup my static (hugo) blog on Cloudflare Pages and was very pleasantly surprised by the ease of setup and how fast they start build jobs after my github's commit. The fact that you can setup a custom domain and get SSL certs all for free with their vast CDN was a nice touch too.
To be fair, those are the bare minimum. All of those have been normalised by the likes of Netlify, Vercel, Firebase Hosting (automatic builds are a bit trickier to setup with them, but considering that CI/CD is a free at small scale commodity, hardly a dealbreaker).
Had CloudFlare released a subpar offering it wouldn't have made much sense.
> I found them lacking in the department of logging and debug
Of the builds specifically? Do you know if you can use your own GitHub Action to build and just throw the static html, css and js at CloudFlare?
> Do you know if you can use your own GitHub Action to build and just throw the static html, css and js at CloudFlare?
I didn't know that, how cool, I'll try it this way, thanks!
I also had similar problems with Cloudflare workers + Next, although Astro + Cloudflare has been quite a sweet experience.
Even still, there are other Cloudflare products to speak of and altogether they are poorly documented and idiosyncratic. Your Cloudflare code will be very Cloudflare.
Building apps at work with Qwik and Cloudflare and has been smooth sailing.
Next.js on anything other than Vercel was always dicey.
The problem is with Next.js
As someone who worked heavily with Cloudflare offerings (being it Pages or Workers), I am surprised how much they have invested in the tech to make it work (V8 isolation) and then simply shipped a half-assed API/framework with little to no documentation. They are sitting on the revolution of serverless and wasting potential use cases because they keep chasing the next production to pump.
OP here — yes, I absolutely agree!
The "hard" work of creating the Workers technology and service is useless if they don't do the arguably easier (but more tedious) work of getting the ecosystem to play well with Workers. This means making a list of the Top 1000 most popular packages on Node.js, and finding ways to make as many of them work on Workers as possible. For the ones where it's too hard/impossible, there should be *well-documented* alternatives.
The rise of Bun, Deno, and other not-Node environments will help this out.
JSR also does a good job of indicating what packages work where—if it gains traction.
I had the same thought. I very strongly advise people not to start with workers with the state the documentation is in unless you have the time to go through the source code (which is c++).
Also, one thing that isn’t made clear in the documentation is that you cannot test in any real sense. They have buggy, toy PoC testing but there’s no way to do local testing for real world apps.
If you’re making anything more complicated than a blog it gets very painful very quickly.
I'd recommend going with Rust/Wasm since even though you can't live test, getting your code to compile gets you quite close to that.