Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloudflare Pages: Best server tech since CGI-bin?

taras.glek.net

Post reply on HN
Print view View original

211–220 of 226 posts

Re: Cloudflare Pages: Best server tech since CGI-bin?

#211

Post by Paradigm2020 »

bluocms wrote: post #191
cj wrote: post #4

Earlier 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 is exactly how we built Bluo: dynamic cms just like wordpress that deploys static assets (html,css,js,images) to cf workers. Benefits are obvious: high reliability and speed to serve the static files. In addition, if the cms server is down for whatever reason, your website is still live and working fully (not just cached pages, all of them) just fine. Actually you can think of it like a pre-built cache that it’s…

Went to the website and there is no pricing, no signup/login whatever ?

Re: Cloudflare Pages: Best server tech since CGI-bin?

#212

Post by bluocms »

Paradigm2020 wrote: post #211
bluocms wrote: post #191

Earlier quoted context omitted.

This is exactly how we built Bluo: dynamic cms just like wordpress that deploys static assets (html,css,js,images) to cf workers. Benefits are obvious: high reliability and speed to serve the static files. In addition, if the cms server is down for whatever reason, your website is still live and working fully (not just cached pages, all of them) just fine. Actually you can think of it like a pre-built cache that it’s…

Went to the website and there is no pricing, no signup/login whatever ?

You can contact us by email if interested.

Re: Cloudflare Pages: Best server tech since CGI-bin?

#213

Post by gfodor »

sofixa wrote: post #184
gfodor wrote: post #64

Earlier 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.

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.

That's FaaS, not middleware for the static contents of your site.

Re: Cloudflare Pages: Best server tech since CGI-bin?

#214

Post by whimsicalism »

pythonaut_16 wrote: post #139
whimsicalism wrote: post #99

Earlier quoted context omitted.

the workers are regenerating the static site on postgres push

Ah, so still fully static vs. a SPA that uses REST or GraphQL. So then clients interact with it as static HTML/JS rather than hydrating it via Javascript.

yes exactly

Re: Cloudflare Pages: Best server tech since CGI-bin?

#215

Post by jlokier »

csomar wrote: post #188
jlokier wrote: post #166

Earlier quoted context omitted.

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 ha…

> Cloudflare workers are distributed through hundreds of locations, and thousands of servers. Doing that with Perl would have been impossible.

No, it wouldn't, that's a misconception. The Perl system I described ran fine on however many servers you wanted to run it on, like any horizontal scaling system. Pretty much anything that runs in a container and isn't required to communicate with a central database does. The design based around indexing files and caching calculations is effectively stateless; it scales without limit if you have the servers.

Any specific points of global data consistency require communication with a shared data store of some kind, but that's also true in Cloudflare workers, where there's a separate Durable Objects system for that. Cloudflare's Durable Objects is pretty good as those things go, but that's not what your comment was about.

What's impossible for most is paying the cost of hundreds of locations. And if you really want to do it well, anycast IP blocks. But if you have the servers, and don't need every request to fetch from a central database (or can use an eventually consistent distributed one), there's no problem deploying as many instances as you want with something that's effectively stateless, even if it's Perl, Python or PHP.

> what usually happen is that the scripting language creep start getting bigger and bigger until it's unmanageable.

Probably right, but I'm curious why you think there won't be equivalent JavaScript creep in sites using CloudFlare Workers.

Re: Cloudflare Pages: Best server tech since CGI-bin?

#216

Post by jlokier »

csomar wrote: post #188
jlokier wrote: post #166

Earlier quoted context omitted.

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 ha…

> will probably be the future of computing

I think you're right, but I think the key part of the tech is economic: their ability to deploy hundreds or thousands of instances safely shared by large numbers of replicated sites and applications belonging to different site owners.

Individual site owners can't afford that level of infrastructure for each site separately. Actually deploying it isn't that difficult, it's just expensive and unjustifiable.

(I nearly started a business doing what Cloudflare Workers is doing now, about 10 years ago (and not with JS/Node), so I know a fair bit about building out this sort of distributed edge system, including the WebSockets and anycast part. But life took a turn and IPv4 blocks for anycast were starting to look a bit beyond what I could justify for the development, even back then. In retrospect it would have been a good thing to build.)

> That is, if the decentralized web fails to take off in the next 5 years.

You have given me an idea :-)

(For a side project I'm working on zero-knowledge proofs of execution, which allows nodes to execute code on behalf of other nodes without the latter having to trust the former. Performance is far too slow to run things like websites at the moment, but there are many tricks for speeding it up, including hardware acceleration.)

Re: Cloudflare Pages: Best server tech since CGI-bin?

#218

Post by neongreen »

gfodor wrote: post #138
neongreen wrote: post #106

Earlier quoted context omitted.

Vercel serverless functions: https://vercel.com/docs/concepts/functions/serverless-functi...

That's not middleware, is it? It's cool, but sits between what is discussed here and something like a FaaS. My understanding is that this post is about actually deploying middleware that runs during the serve of the static pages.

They have this kind of middleware as well: https://vercel.com/docs/concepts/functions/edge-middleware

Don’t know if it’s as powerful, though — haven’t personally used it.

Re: Cloudflare Pages: Best server tech since CGI-bin?

#219

Post by darkerside »

ethbr0 wrote: post #208
darkerside wrote: post #104

Earlier quoted context omitted.

It's funny, the simplicity really reminds me of server size scripting languages like ASP and PHP.

It's amazing how far I got down in the comments before there was a "This is like X", where X=PHP. PHP, getting shit done since '95.

Put it on a tshirt

Re: Cloudflare Pages: Best server tech since CGI-bin?

#220

Post by preseinger »

rakoo wrote: post #206
preseinger wrote: post #179

Earlier quoted context omitted.

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…

> What do you think is the upper limit of requests per second, if your HTTP server does process-per-request ? In the hundreds, which is absolutely enough for most use cases. If CGI is enough for sqlite.org displaying dynamic content (such as in https://www.sqlite.org/cgi/src/timeline ), it is enough for 80% of websites. You are not bigger than sqlite. > How do you think those metrics compare to other designs The impo…

> The important question is not "is it better or worse than alternatives" but "is it enough for me". Yes, it is.

All good! But if you're OK with O(100) RPS out of a server, then I guess basically every possible option is on the table. I bet `nc` spawning background `bash` scripts to handle requests would get to 1k RPS, even! ;)

> HTTP/2 doesn't change anything.

I guess that would work, as long as the fronting server managed all of the connection management details, stream demuxing, etc. But I wonder how you'd do that in a single thread?

Post reply on HN