No post body was provided.
Cloudflare Pages: Best server tech since CGI-bin?
181–190 of 226 posts
Re: Cloudflare Pages: Best server tech since CGI-bin?
#182I am waiting for the time where we can host WordPress freely with static hosting and workers for admin ui/dynamic content. Otherwise static websites are only for devs.
Have you seen Strattic? It's a static hosting service for standard WordPress sites (i.e. monolithic WordPress as opposed to headless WordPress), so the time has arrived (unless you meant "freely" as in "free beer" and not "without limitation). https://www.strattic.com
Re: Cloudflare Pages: Best server tech since CGI-bin?
#183I am waiting for the time where we can host WordPress freely with static hosting and workers for admin ui/dynamic content. Otherwise static websites are only for devs.
This. I keep seeing these 'JAMstack' sites are the new hot thing when a static wordpress site is enough and easier to update than 'JAMstack' sites, in reality these sites are just glorified HTML under a CDN. I don't see the benefit of JAMstack when you can just place a static WP site under a CDN like Cloudflare and have all the benefits of WP and a CMS to edit content. At least with Cloudflare they are more than just…
Static WordPress is possible - you can generate a static replica of your WordPress site and deploy that via CDN. There are some plugins that help you do that (Simply Static, WP2Static) but you need to also configure your whole infrastructure when using them, and the build process can be long and painful.
There are also managed services for doing this that take care of everything for you, from the WP hosting env, to the static hosting and CDN, along with replicating certain types of dynamic functionality on the static site like forms and search.
One example of this type of managed static WordPress hosting service is Strattic: https://www.strattic.com.
Re: Cloudflare Pages: Best server tech since CGI-bin?
#184Earlier quoted context omitted.
Yes, it's great because static/static+some dynamic bits fits a lot of use cases and it's quite simple to deploy, manage and maintain. It's nothing that new though, Firebase (part of GCP) and Netlify have had that for years. CloudFlare just have the right combination of marketing, reputation, pricing and tech to make headlines with it again.
I have never seen an example where you land a JS file in a static website in git and it just runs as part of server side middleware. Seems legit novel but would like to know other examples.
Firebase Cloud Functions: https://firebase.google.com/docs/functions/get-started
You drop a file in the functions dir of your repository, edit the firebase.js(on? it's been a while) config file to say that function X maps to path Y (so you can have api.site.com or site.com/api or whatever you want as a redirect to your function), and run firebase deploy.
Re: Cloudflare Pages: Best server tech since CGI-bin?
#185Biggest 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 r…
I'm curious about cams, but I'm being greeted with "Your passphrase has expired" when I try to get it to "let me in"
Thanks for the heads up. There's nothing mind blowing on the demo page, but password has been unexpired if you still want to take a look.
Re: Cloudflare Pages: Best server tech since CGI-bin?
#186Earlier quoted context omitted.
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…
This sounds similar to the old Server Side Includes [1] . In the 90s I was using SSI to build dynamic, but static sites -- header -- -- hierarchal javscript menuing -- -- content -- -- footer -- -- tail -- [1] https://en.wikipedia.org/wiki/Server_Side_Includes
SSI was my first introduction to abstraction in programming. What a rush!
Re: Cloudflare Pages: Best server tech since CGI-bin?
#187Earlier quoted context omitted.
Yes, it's great because static/static+some dynamic bits fits a lot of use cases and it's quite simple to deploy, manage and maintain. It's nothing that new though, Firebase (part of GCP) and Netlify have had that for years. CloudFlare just have the right combination of marketing, reputation, pricing and tech to make headlines with it again.
> Yes, it's great because static/static+some dynamic bits fits a lot of use cases and it's quite simple to deploy, manage and maintain. Do you have some examples? I always get excited by this serverless stuff, but often the use-cases are quite limited if you think about it, or maybe I’m thinking wrong, especially if you take vendor lock into consideration.
Small Things I used it for:
Contact Form - Comments System - Authentication System - Image resizing (thumbnails) - GraphQL Gateway (working on this now) - Bypass CORS - Generate a random number on the server
I also built full apps on CloudFlare workers (and doing it now).
Only one caveat: They are heavily invested in marketing but their tooling is real cr*p. They are not investing in the Rust integration; or the more regular tools/integrations you are used to.
Re: Cloudflare Pages: Best server tech since CGI-bin?
#188Earlier quoted context omitted.
I have never seen an example where you land a JS file in a static website in git and it just runs as part of server side middleware. Seems legit novel but would like to know other examples.
It's similar to what I was doing 10 to 5 years ago but in Perl. Drop a file into a directory which is all or mostly static Markdown, HTML or CSS, but those files can contain markup to call other modules, as well as code files. The existence of a file is enough for its index code to be run (if it has any) and any URL-set and page components it makes available are available to other pages to be used, or served as they…
Cloudflare workers are distributed through hundreds of locations, and thousands of servers. Doing that with Perl would have been impossible. Also, remembering from my old CGI/PHP days, what usually happen is that the scripting language creep start getting bigger and bigger until it's unmanageable.
I'm not saying Cloudflare workers are a better proposition now. (their ecosystem is a complete shitshow) but the idea has lots of potential; and will probably be the future of computing[!].
!: That is, if the decentralized web fails to take off in the next 5 years.
Re: Cloudflare Pages: Best server tech since CGI-bin?
#189I 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? 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
[deleted]
Re: Cloudflare Pages: Best server tech since CGI-bin?
#190Earlier quoted context omitted.
> Plain old CGI doesn't scale beyond toy usage--it spawns a process per request. I'd be willing to bet the opposite: CGI is more than enough for 80% of workload, performance-wise. There are a few good reasons why CGI isn't the best today: the tooling doesn't exist, the security model is really bad, and you can cram fewer websites on a single machine, so for the same number of websites you need more machines, and that…
Speed is the only reason CGI doesn't fly. What do you think is the upper limit of requests per second, if your HTTP server does process-per-request? For simplicity, assume server class hardware, that each request does no work besides producing a response, and an upper bound of 10k unique remote addresses (i.e. no more than 10k concurrent connections in a different model). How do you think those metrics compare to oth…
> Speed is the only reason CGI doesn't fly.
It is indeed very very slow; mostly because it is not possible to pre-fork your CGI scripts (environment variables get set from the request, so each cgi program will have different values in the environment).
But, if you could pass HTTP data via some way other than environment variables, you could pre-fork the binaries and have acceptable speed[1].
[1] Pre-forking makes a large difference, and surprisingly is not too far off from other approaches to concurrent request handling. See https://unixism.net/2019/04/linux-applications-performance-i...