I feel like there's a large class of tools in this space now (Vercel, Netlify) that do all of this and more, and this post is less about Cloudflare Pages and more about the (really good) state of static hosting these days?
Static hosting combined with server-side dynamic content modification using postgres was the interesting part for me.
Static hosting has historically been seen as exactly that, static and immutable.
Things like Cloudflare functions/workers can turn static hosting into dynamic content delivery while maintaining (most of) the benefits of static hosting.
Granted, this can be done whether the underlying content is hosted on Cloudflare, AWS, or a server in your garage so long as it’s proxied/CDN’d by a service like Cloudflare or Cloudfront+Lambda@edge, etc.
No it’s pointing out the server side scripting part which was new to me. do analogs exist in those other hosting options? This seems like a really nice facility - closest analog client side wise is a service worker or something that adjusts fetch.
Author here. I actually thought about using this library. In my case re-rending as svg was too complex. Much more practical to upload screenshots of DOM, share those via functions/middleware.
I’m happily using CloudFlare pages. The reason I haven’t tried Netlify is that after the free tier everything seems a little overpriced. I didn’t go for Vercel because I don’t want to use Next.js and I’m afraid I’ll run across some limitation because of this. I was already using Cloudflare as a CDN for S3 and GitHub pages, and their offerings seem to be growing quickly and wanting to compete with Amazon rather than the static hosting companies.
What is really annoying is that Cloudflare pages will strip the file extension off of your html pages, and perform permanent redirects to those new URLs. Now if you're intending on moving to a new hosting service that doesn't do that (cgi-bin), all Google search results to your site will 404.
Github pages and likely others also supports this format, so moving between those two services doesn't exhibit this problem. Moving to cgi-bin will.
I'd suggest Cloudflare shouldn't try to establish their scheme as canonical url and rather implement github pages behavior, but what do I know... I'm just hosting an old fashioned blog, not a JAMstack/SPA/whatever thing
Having .html file extensions is very old school, and its removal is one of the popular/default redirects on all http servers that support it. Site generators also hide it through various methods (e.g. having a folder with the path name with just an index.html where a dynamic redirect isn't possible).
I exactly ran into this issue when migrating from a different provider to CF pages.
I preferred to strip away the .html extensions anyway, so it was okay in my case. CF should trigger a HTTP 308 for older .html to the new urls automatically.
You can use the more barebones Worker Sites and retain file extensions. Pages has nicer UX (automatic PR preview sites!) but the old school Worker Sites setup is dead simple and does exactly what you want - it's just a template setup to load assets from KV storage.
Maybe I'm misunderstanding, but Apache httpd has performed URL rewriting such as adding a .html suffix after mapping URLs to file names where appropriate, and other transformations such as content negotiation for languages, spelling correction, etc. for ages.
In 10 years time when cloudflare goes bankrupt/withdraws the free offering, will you be able to redeploy to another platform or will you start having to delve into 10 year old code and porting it to a new API?
Is there at least an nginx-cloudflare module that lets you self-host this stuff?
Why not just make it CGI (or FastCGI) compatible so you can test it locally or run it in other environments? At least for things that are actually generating responses rather than acting as middleware.
We did not create our own engine to create "lock-in". On the contrary, it would be a huge win for us if we could simply run FastCGI or Node or whatever applications unmodified. We'd be able to onboard a lot more customers more quickly that way! Our product is our physical network (with hundreds of locations around the world), not our specific development environment.
But none of that tech scales well enough that we could run every app in every one of our locations at an affordable price. Meeting that goal required new tech. The best we could do is base it on open standard APIs (browser APIs, mostly), so a lot of code designed for browsers ports over nicely.
(I'm the lead engineer for Workers. These were my design choices, originally.)
Because V8's low-overhead tenant isolation is fundamental to how Cloudflare Workers works[1], and without it it would be a completely different product with worse performance. This means it can only support JavaScript and WebAssembly.
You can run it locally[2], and efforts are underway to standardize much of it so that the same code can run on Workers, Node.js, and Deno[3]. The Workers runtime is also open source[4], although in practice this is likely to be less useful for most use cases than just using one of the other JavaScript runtimes if you're self-hosting.
For better or worse fast CGI never took off much beyond PHP. Python, node, ruby, etc. all do their own thing with their own app servers and protocols. I mean sure something like python can use fast CGI but no one in that community uses it that way, everyone uses uWSGI, gunicorn, etc.
Plain old CGI doesn't scale beyond toy usage--it spawns a process per request.
So there really isn't a good single option for Cloudflare to use.
Cloudflare Pages and Workers (and similar products) are indeed great but I recently switched over to a plain old free tier Oracle Cloud VM with FastAPI behind Nginx (Docker containers). I use Cloudflare as a proxy for HTTPS/certs. I don't have to think about Cloudflare Worker limitations, can host a Postgres instance, and simply deploy through `git pull` and `docker-compose up`.
> As a shortcut, I used GPT-3 to generate a basic typescript function for me. This let me look at TS type definitions and get a better idea of what’s available so I could get developing.
As a long time programmer, I keep trying to maintain my skepticism of AI/ML techniques for program authoring. Comments like this are dissolving my
objections by the minute...
I don't know which GPT-3 tooling they were using, but Github Copilot can be _exceptional_ at generating rubbish. Autocomplete, at least for me, was seldom even syntactically correct, and never semantically correct.
Biggest advantage I find is pre-scoped request-level control over everything. When someone loads your page, every single asset request hits your worker. It's both extremely simple and exceptionally powerful. Choose which responses to modify, authenticate, proxy, redirect, or let through. All in a single file with a few dozen LOC. No complex pre-app devops, middleware or routing policies required (i.e. oh sorry that route is proxied by a lambda, or you should check the cloudflare dash there's a worker sitting in front of that).
Yes, there are a bunch of limitations - but in practice I quite appreciate the boundaries and the reasoning. There's also the portability question, but we're talking about PaaS. As someone who was using Firebase for many years, and static AWS + lambda prior to that I find this evolution entirely refreshing.
I've pushed 5 personal projects on pages since Jan and working on more. Most recently https://thesom.au/gh/cvms
Author here, went through your github. Cloudflare should post your code as reference architecture. Answered so many questions re proper app structure on CF. Really appreciate the amount of effort your examples will save me in future.
How does using GPT-3 make the types more visible? Feels futuristic but also incomprehensible to me.
> As a shortcut, I used GPT-3 to generate a basic typescript function for me. This let me look at TS type definitions and get a better idea of what’s available so I could get developing.
I have been working on servers whether professionally as a software engineer or as a pre-teen making a The Simpsons fan website for a couple decades now. I have never once used that `cgi-bin`, never opened it, and still have no idea wtf it is.
In my experience it's this thing exclusively used in offensive security training/CTFs. Not really sure what the intended use is, but it sure gets owned a lot
To write functioning code, you need to know how to write functioning code.
The biggest issue with Copilot is that, to use it well, you need to know:
- How to write functioning code.
- How to quickly review other people's code for correctness.
- How to write good comments.
- How to tweak the ordering in which you write code such that it's easier for Copilot to understand.
- How Copilot and other GANs work, in general. An awareness that Copilot is built on GPT-3, familiarity with what that implies, and so on.
And if you don't, that results in the AI seemingly not working as well, which makes it easy to make the assumption that it isn't an incredibly useful tool. It is, it just has a learning curve measured in weeks.
I believe this is why we constantly have arguments on whether or not it's helpful.
The Cloudflare cloud experience is "being sold short by subpar documentation" right now because important elements of their ecosystem are being ramped up from beta status. They also have internal docs which aren't kept up to date with their actual product. I'd check back in a few months because their beta experience can be very touch-and-go.
The rest of the industry haven't even started figuring out what Cloudflare Pages Functions + Durable Objects can do. Workers can also send emails for free, and soon you will be able to process them as well with Email Workers. Cloudflare also doesn't charge you for egress either.
> The rest of the industry haven't even started figuring out what Cloudflare Pages Functions + Durable Objects can do
I was very excited when both of these technologies were first announced (years ago).
I tried them, immediately, then (during the initial beta). They were clunky, half-baked, and don't even get me started on the DX of developing against them. Literally missing from cloudflare's own CLI - the official docs described how to manually deploy via CURLing endpoints. It felt like manually FTPing files onto a server, like in the 90s.
Ok fine, this is an early beta, let's let this bake longer.
So a few months ago, I started a new greenfield project and once again decided to give Functions + Durable Objects a shot... and was astounded to find the exact same half-baked experience, where different "beta" versions of the CLI had to be installed in order to support the different endpoints, and these were in fact mutually-exclusive.
Cloudflare has some cool ideas, but they seem to like rolling out 70% of a cool idea and then moving into the next shiny thing without ever making the first thing actually polished and reliable. After wasting many hours with Cloudflare's DX, I decided to never waste more time with them as a development platform (vs an optimization layer / CDN / etc).
> Workers can also send emails for free, and soon you will be able to process them as well with Email Workers.
There's got to be some limitations to that and I don't like it when they're not well defined. Looking at the MailChannels pricing, it looks like it's roughly 40x more expensive than AWS SES on the low end and 4x on the biggest plan before negotiating a custom deal.
I can send 500k emails and have a dedicated IP on SES for the same cost as 40k emails from MailChannels. Since their big value add seems to be scanning emails to prevent spam from user generated content, I just don't see it if that's not functionality you need because it's all wasted resources / unnecessary cost in those cases.
I assume there's a point where it's no longer free and I'm guessing the cost once you get there will be high.
Plus, am I sharing IPs with people who are sending such low-quality mail it requires outbound spam filtering? That seems like a huge negative on the deliverability side of things.
[I work at Firebase]
Hi folks, I've seen some notable mentions of Firebase in this thread.
Last week, during the Firebase Summit we launched preview support for Web Frameworks like NextJS and Angular Universal: https://firebase.google.com/docs/hosting/frameworks-overview
Support during this early preview includes the following functionality:
- Deploy Web apps comprised of static web content
- Deploy Web apps that use pre-rendering / Static Site Generation (SSG)
- Deploy Web apps that use server-side Rendering (SSR)—full server rendering on demand
This page inspired me to actually convert as well. I have just recently been forced out of the AWS free tier and for some reason my insistence on using terraform and preserving a dynamic lockable state was somehow costing me $20 a month in DynamoDB costs.
Anyways, the pages import to take an existing git repository with a slew of CMS systems (mine being Hugo) supported, and the ability to just publish it to a custom domain in a series of clicks was actually really simple.
I think I dedicated 30 minutes of entire work and just saved ~$20/month because of it.
We're working on the documentation, I agree it can certainly be thin (or just not understandable). Please do file an issue for any improvements you'd like to see: https://github.com/cloudflare/cloudflare-docs/issues
[+] [-] gkoberger|3 years ago|reply
One thing that stuck out was the comment about "Twitter cards", since Vercel/Next now has this built in: https://twitter.com/vercel/status/1579561293069316096
[+] [-] cj|3 years ago|reply
Static hosting has historically been seen as exactly that, static and immutable.
Things like Cloudflare functions/workers can turn static hosting into dynamic content delivery while maintaining (most of) the benefits of static hosting.
Granted, this can be done whether the underlying content is hosted on Cloudflare, AWS, or a server in your garage so long as it’s proxied/CDN’d by a service like Cloudflare or Cloudfront+Lambda@edge, etc.
[+] [-] gfodor|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] tarasglek|3 years ago|reply
[+] [-] elondaits|3 years ago|reply
[+] [-] untitaker_|3 years ago|reply
Github pages and likely others also supports this format, so moving between those two services doesn't exhibit this problem. Moving to cgi-bin will.
I'd suggest Cloudflare shouldn't try to establish their scheme as canonical url and rather implement github pages behavior, but what do I know... I'm just hosting an old fashioned blog, not a JAMstack/SPA/whatever thing
[+] [-] sofixa|3 years ago|reply
[+] [-] kc10|3 years ago|reply
I preferred to strip away the .html extensions anyway, so it was okay in my case. CF should trigger a HTTP 308 for older .html to the new urls automatically.
[+] [-] mhensley|3 years ago|reply
https://developers.cloudflare.com/workers/platform/sites/
[+] [-] tannhaeuser|3 years ago|reply
[+] [-] slig|3 years ago|reply
[+] [-] londons_explore|3 years ago|reply
Is there at least an nginx-cloudflare module that lets you self-host this stuff?
[+] [-] jasonhansel|3 years ago|reply
Oh, right, vendor lock-in.
[+] [-] kentonv|3 years ago|reply
We did not create our own engine to create "lock-in". On the contrary, it would be a huge win for us if we could simply run FastCGI or Node or whatever applications unmodified. We'd be able to onboard a lot more customers more quickly that way! Our product is our physical network (with hundreds of locations around the world), not our specific development environment.
But none of that tech scales well enough that we could run every app in every one of our locations at an affordable price. Meeting that goal required new tech. The best we could do is base it on open standard APIs (browser APIs, mostly), so a lot of code designed for browsers ports over nicely.
(I'm the lead engineer for Workers. These were my design choices, originally.)
[+] [-] ameliaquining|3 years ago|reply
You can run it locally[2], and efforts are underway to standardize much of it so that the same code can run on Workers, Node.js, and Deno[3]. The Workers runtime is also open source[4], although in practice this is likely to be less useful for most use cases than just using one of the other JavaScript runtimes if you're self-hosting.
[1] https://developers.cloudflare.com/workers/learning/how-worke... [2] https://developers.cloudflare.com/pages/platform/functions#d... [3] https://wintercg.org/ [4] https://github.com/cloudflare/workerd
[+] [-] qbasic_forever|3 years ago|reply
Plain old CGI doesn't scale beyond toy usage--it spawns a process per request.
So there really isn't a good single option for Cloudflare to use.
[+] [-] solardev|3 years ago|reply
Cgi just isn't necessary anymore and would be more baggage than anything at this point.
The old web stacks are just time sinks. It's so much nicer to be able to git push... And that's it. Done.
[+] [-] mfer|3 years ago|reply
For example you have security. CGI with multitenants is hard if not impossible. At least for the tenants that will want to use this.
Then there is scaling, resource consumption, and predictability (for planning).
[+] [-] pjkundert|3 years ago|reply
[+] [-] harwoodjp|3 years ago|reply
[+] [-] sramam|3 years ago|reply
> As a shortcut, I used GPT-3 to generate a basic typescript function for me. This let me look at TS type definitions and get a better idea of what’s available so I could get developing.
As a long time programmer, I keep trying to maintain my skepticism of AI/ML techniques for program authoring. Comments like this are dissolving my objections by the minute...
[+] [-] mceachen|3 years ago|reply
[+] [-] tarasglek|3 years ago|reply
[+] [-] jacooper|3 years ago|reply
Otherwise static websites are only for devs.
[+] [-] somishere|3 years ago|reply
Yes, there are a bunch of limitations - but in practice I quite appreciate the boundaries and the reasoning. There's also the portability question, but we're talking about PaaS. As someone who was using Firebase for many years, and static AWS + lambda prior to that I find this evolution entirely refreshing.
I've pushed 5 personal projects on pages since Jan and working on more. Most recently https://thesom.au/gh/cvms
[+] [-] tarasglek|3 years ago|reply
[+] [-] superdug|3 years ago|reply
[+] [-] pantojax45|3 years ago|reply
> As a shortcut, I used GPT-3 to generate a basic typescript function for me. This let me look at TS type definitions and get a better idea of what’s available so I could get developing.
[+] [-] andirk|3 years ago|reply
[+] [-] broodbucket|3 years ago|reply
[+] [-] xenospn|3 years ago|reply
[+] [-] Cthulhu_|3 years ago|reply
As people smarter than me have said, if a video or in this case article asks a question, the answer is usually "no".
[+] [-] schwartzworld|3 years ago|reply
I'd love to see a more detailed post about that. I don't know any TS devs using that kind of workflow.
[+] [-] Filligree|3 years ago|reply
The biggest issue with Copilot is that, to use it well, you need to know:
- How to write functioning code.
- How to quickly review other people's code for correctness.
- How to write good comments.
- How to tweak the ordering in which you write code such that it's easier for Copilot to understand.
- How Copilot and other GANs work, in general. An awareness that Copilot is built on GPT-3, familiarity with what that implies, and so on.
And if you don't, that results in the AI seemingly not working as well, which makes it easy to make the assumption that it isn't an incredibly useful tool. It is, it just has a learning curve measured in weeks.
I believe this is why we constantly have arguments on whether or not it's helpful.
[+] [-] threatofrain|3 years ago|reply
[+] [-] Comevius|3 years ago|reply
[+] [-] strix_varius|3 years ago|reply
I was very excited when both of these technologies were first announced (years ago).
I tried them, immediately, then (during the initial beta). They were clunky, half-baked, and don't even get me started on the DX of developing against them. Literally missing from cloudflare's own CLI - the official docs described how to manually deploy via CURLing endpoints. It felt like manually FTPing files onto a server, like in the 90s.
Ok fine, this is an early beta, let's let this bake longer.
So a few months ago, I started a new greenfield project and once again decided to give Functions + Durable Objects a shot... and was astounded to find the exact same half-baked experience, where different "beta" versions of the CLI had to be installed in order to support the different endpoints, and these were in fact mutually-exclusive.
Cloudflare has some cool ideas, but they seem to like rolling out 70% of a cool idea and then moving into the next shiny thing without ever making the first thing actually polished and reliable. After wasting many hours with Cloudflare's DX, I decided to never waste more time with them as a development platform (vs an optimization layer / CDN / etc).
[+] [-] matthews2|3 years ago|reply
[+] [-] quickthrower2|3 years ago|reply
[+] [-] donmcronald|3 years ago|reply
> Workers can also send emails for free, and soon you will be able to process them as well with Email Workers.
There's got to be some limitations to that and I don't like it when they're not well defined. Looking at the MailChannels pricing, it looks like it's roughly 40x more expensive than AWS SES on the low end and 4x on the biggest plan before negotiating a custom deal.
I can send 500k emails and have a dedicated IP on SES for the same cost as 40k emails from MailChannels. Since their big value add seems to be scanning emails to prevent spam from user generated content, I just don't see it if that's not functionality you need because it's all wasted resources / unnecessary cost in those cases.
I assume there's a point where it's no longer free and I'm guessing the cost once you get there will be high.
Plus, am I sharing IPs with people who are sending such low-quality mail it requires outbound spam filtering? That seems like a huge negative on the deliverability side of things.
[+] [-] jgrahamc|3 years ago|reply
[+] [-] tambourine_man|3 years ago|reply
In practice, no one is running workerd at their VMs, so it seems weird for me to compare the two.
Cloudflare Pages is better than [insert your favorite hosting service] would make more sense. Still, very cool tech.
[+] [-] sebag1507|3 years ago|reply
Support during this early preview includes the following functionality: - Deploy Web apps comprised of static web content - Deploy Web apps that use pre-rendering / Static Site Generation (SSG) - Deploy Web apps that use server-side Rendering (SSR)—full server rendering on demand
Cheers,
[+] [-] superdug|3 years ago|reply
Anyways, the pages import to take an existing git repository with a slew of CMS systems (mine being Hugo) supported, and the ability to just publish it to a custom domain in a series of clicks was actually really simple.
I think I dedicated 30 minutes of entire work and just saved ~$20/month because of it.
[+] [-] iot_devs|3 years ago|reply
When somebody hit my webserver for the first time, how long are they gonna wait for the page to be loaded?
Assuming a noop in the functions part.
[+] [-] ianbutler|3 years ago|reply
https://blog.cloudflare.com/introducing-workers-durable-obje...
[+] [-] andrewstuart|3 years ago|reply
Cloudflare services are awesome.
Their documentation tends to be OK but thin. Certainly not great.
[+] [-] Walshy|3 years ago|reply
[+] [-] ZephyrBlu|3 years ago|reply