Live data from Hacker News

Cloudflare Pages: Best server tech since CGI-bin?

taras.glek.net

131–140 of 226 posts

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

#131

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. Oh, right, vendor lock-in.

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

> 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's an ecological aberration. But there is no problem about CGI being too slow.

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

#132
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?

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

#133

Earlier quoted context omitted.

You can pretty easily change from Cloudflare to any other Jamstack host. 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.

> It's so much nicer to be able to git push... And that's it. Done. Can you elaborate? My CGI-based website is deployed with `git push` as well, not sure what the difference is there.

How's your hosting stack set up? The Jamstack vendors are zero config or maintenance

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

#134
post #131

Earlier quoted context omitted.

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

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

Sure but developers don't want to bifurcate their service code and releases into a simple version using CGI and a dedicated app server version for when CGI doesn't scale for them or their users. They just want to write one python web app and run it everywhere.

There's no way a CGI app can reach a million requests a second on the same hardware that a nodejs (single thread, worker loop) would take to do 1M RPS. Processes have a lot of overhead. Almost no one needs 1M RPS but it cannot be waived away that CGI is perfect for everything.

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

#135

Earlier quoted context omitted.

You can pretty easily change from Cloudflare to any other Jamstack host. 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.

Forgive my digression but for years I’ve seen small efforts here and there to elevate the concept of a “stack” and promote it as the level abstraction to use when discussing web apps and the like. What’s up with that? Grab any 3 commonly used pieces of technology whose names can be used to form a fun initialism, append stack to the end, and soon there will be experts speaking at conferences dedicated to it. JamStack…

What else would you call the well, stack, of technologies used to host a website? It's not a marketing term, just a way to describe the multiple layers. From hardware to network routing to DNS to tcp/up to http to https to HTML to JS to workers, and also Linux and PHP and a web server like Apache or nginx and a database like Maria or Postgres and maybe a cache like Redis or memcached and maybe squid and Varnish in front of it... that's a stack.

Jamstack is just a particular configuration where vendors take care of all of that and you can push up frontend code that auto deploys and that's that. I used to have to manage the whole stack and now can work purely in HTML CSS and JS and it is a DREAM. That's the magic of the Jamstack. Less devops and network infrastructure, more time to focus on UX and DX.

As for vendors, there's Vercel, Netlify, Gatsby, maybe a few others. Cloudflare, Deno, and Fly, Render and a few others have similar variations.

It's a really nice way to work...

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

#136

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

Using Fly.io myself, behind Cloudflare. Free container hosting and free Postgres instance both big enough for my needs.

Fly.io is weird about overages:

https://github.com/superfly/docs/issues/382

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

#138
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.

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.

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

#139

Earlier quoted context omitted.

Can you explain how Cloudflare Workers factor into hosting static pages on Cloudflare Pages vs hosting a React SPA on pages that talks to any other API? Like are the workers just serving as your backend at that point? Or are they doing something more or different as well?

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.

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

#140
post #27

Earlier quoted context omitted.

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

It was removed explicitly for SEO and having a single canonical URL for a resource _for all of time forever_. Right now we use HTML for web pages but who knows what the internet 20, 50, 100, etc. years from now will use--maybe .Super-Awesome-Mega-HTML is all the rage. If over time you are changing your site and its URLs are changing then you're breaking that canonical URL and search indexes, caches, way back machine,…

The benefits aren’t just SEO. I’d much rather have /about than /about.{htm,html,php,asp,etc}. I don’t see how the latter is preferable for routing to pages.
Post reply on HN