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

The demise of the mildly dynamic website (2022)

devever.net

Post reply on HN
Print view View original

91–100 of 183 posts

Re: The demise of the mildly dynamic website (2022)

#91

Post by 1vuio0pswjnm7 »

"Or, suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn't need a framework - it's one SELECT query, that's it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn't too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it.... This example is fictitious but I believe it to be representative."

As an end user, I have seen this perplexing design pattern quite often. As soon as I see it, I just get the URL for the JSON file and I never look at the web page again. It is like there is so much bandwidth, memory and CPU available but the developer is not letting the user takes advantage of it. Instead the developer is usurping it for themselves. Maybe a user wants to download data. But the developer wants to run Javascript and keep _all_ users staring at a web page.

Why not just provide a hyperlink on the rendered search results page pointing to the JSON file, as an alternative to (not a replacement for) running Javascript. What are the reasons for not provding it.

On some US government websites, for example, a hyperlink for the the CSV/JSON file is provided in the rendered search results page.^1

That is why a non-commercial www is so useful, IMHO: the best non-commercial websites do not try to "hide the ball".

Perhaps they have no incentive to try to force users to enable Javascript, which is a practical prerequisite for advertising and tracking.

1. ecfr.gov and federalregister.gov are two examples

Re: The demise of the mildly dynamic website (2022)

#92

Post by MOARDONGZPLZ »

troupo wrote: post #78
derefr wrote: post #62

Earlier quoted context omitted.

Lambda is also distributed , though — while CGI scripts just live on the webserver itself. So if you're old like me and want a crisper mental model, the actual '90s equivalent of Lambda would be: • a cluster of "diskless" web-server (let's say Apache) machines with a round-robin load-balancer in front of them; • where these web servers are all using mod_userdir, pointing /~*/ at, let's say, "/wwwhome/*/www/" — and wi…

> Lambda is also distributed, though — while CGI scripts just live on the webserver itself. Most of the stuff people use lambdas for they could run from the cheapest Digital Ocean droplet or cheapest Hetzner server. You need "omg distributed" perhaps after your millionth user, and even then it's highly debatable.

I’m guilty of this sort of “kids these days” thinking as well. But really the AWS lambda free tier is very generous and I don’t get any sort of bill unless there’s a very large spike in usage. With DO or Hetzner I pay for the server to be up and get a monthly bill no matter what.

I would even somewhat reverse your assertion: use Lambda until you have a need for a real server infra and then upgrade to things like Hetzner.

Re: The demise of the mildly dynamic website (2022)

#93

Post by fpoling »

decasia wrote: post #14

I think the spirit of this article is correct, although some of the digs at modern web tech and SPAs seem to be beside the point. I used to have a "mildly dynamic website." It was a $5 digital ocean box. It ran nginx with php-fpm, mostly so it could have a Wordpress install in a subdirectory, and it had a unicorn setup for an experimental Rails app somewhere in there. Given that environment, the "mildly dynamic websi…

I am puzzled that your site required constant maintenance. I run a similar setup that I hardens using systemd service restrictions with nothing running as root. Then I subscribed to Debian and couple more mail lists with security announcements. It turned out I needed to spend like 20 minutes per month to maintain it.

I also find that PHP works much better than Go regarding maintenance efforts. With Debian I have automatic updates of all PHP dependencies that I need so security announcements is a nice single source of truth. But with Go I would need to setup monitoring of dependencies for updates myself and recompile/deploy the code as necessary.

Re: The demise of the mildly dynamic website (2022)

#94

Post by cutler »

josephcsible wrote: post #72
chasd00 wrote: post #8

Earlier quoted context omitted.

In a lot of these discussions the point gets raised about the work to maintain a self-hosted server. When i've done it I install the os (usually ubuntu server), turn off unused services, setup the firewall to only allow required ports, and then it just sort of sits there and does its thing. Uptimes have been measured in years in some cases and the server just sits there happily serving whatever html and connecting to…

Do you enable unattended upgrades and kernel live patching? If not, then that doesn't seem secure.

`dnf upgrade` or `apt update && apt upgrade` once a month isn't so much work. If either includes a kernel upgrade then it's `reboot now` and I'm done.

Re: The demise of the mildly dynamic website (2022)

#95

Post by solardev »

troupo wrote: post #85
solardev wrote: post #26

Earlier quoted context omitted.

(too long... here's part 2): 4) Serverless as "CGI but it's trendy, [with vendor lock-in and a more complex deployment process]" What vendor lock-in? Most of the code is just vanilla JS. There might be a different deployment procedure if you're using Cloudflare vs Lambda vs Vercel vs Serverless Framework, but those are typically still simpler than having to set up an SFTP connection or git repo in a remote folder. Wi…

> What vendor lock-in? Most of the code is just vanilla JS. That runs in a specific environment with vendor-specific IAM configurations, vendor-specific DNS configurations, vendor-specific network configurations, vendor-specific service integrations, vendor-specific runtimes and restrictions, vendor-specific...

That sounds like an AWS thing? There's a lot of frameworks that can deploy straight to Vercel, Cloudflare Pages, Netlify, etc. without all that.

And if you really want to manage all that, it would apply to both PHP sites and JS and anything else. That's really more of a discussion of fully vs partially managed cloud solutions, not PHP or JS or any framework in particular.

Re: The demise of the mildly dynamic website (2022)

#96

Post by derefr »

troupo wrote: post #90
derefr wrote: post #87

Earlier quoted context omitted.

You're thinking about the (rather few) advantages distribution confers for single-tenant scaling. But the distribution here is mainly for other reasons: • operational fault-tolerance: arbitrary servers in the cluster hosting the function can fail or be taken down for repair without any workloads going down. This allows the ops team that owns the cluster to freely keep the cluster's machines up to date with OS package…

You write a long wall of text that does boring to dispute what I wrote. The cheapest DO droplet is 4 dollars a month. It is more than capable of running "10 scripts", and will last your startup with three users indefinitely long. If you're concerned about that cost, lambdas will not save you

Maybe we write very different kinds of scripts. For my startup, such a "script" might be:

1. An hourly itemized invoicing batch job for incremental usage-based billing, that pulls billable users from an ERP DB, grabs their usage with a complex Snowflake query (= where our structured access logs get piped), then does a CQRS reduction over the credit-and-spend state from each user's existing invoice line-items for the month, to turn the discovered usage into new line-items to insert back into the same ERP DB.

2. A Twilio customer-service IVR webhook backend, that uses local speech-processing models to recognize keywords so you don't have to punch numbers.

3. An image/SVG/video thumbnailer that gets called when a new source asset (from a web-scraping agent) is dropped into one bucket; and which writes the thumbnail for said asset out into another bucket. (For the SVG use-case especially, this requires spinning up an entire headless Chrome context per image, mostly in order to get the fonts looking right. We actually handle that part of the pipeline with serverless containers, not serverless functions, because it needs a custom runtime environment.)

#1 is an example of a low-utilization "script" where we just don't want to pay for the infra required to run it when it's not running, since when it is running it "wants" better-than-cheapest resourcing to finish in a reasonable time (which, if you were deploying it to a VM, would mean paying for a more expensive VM, to sit mostly idle.) We do have a k8s cluster — and this was originally a CronJob resource on that, which made sense at first — but this is an example of a "grows over time" workload, and we're trying to avoid using k8s for those sort of workloads, because k8s expects workloads to have fixed resource quotas per pod, and can't cope well with growing workloads without a lot of node-pool finessing.

#2 and #3 are high-utilization (one in CPU and RAM, one in requiring a GPU with VRAM) "scripts", where only one or two concurrent executions of these would fit on a $4/mo DO droplet; and where ten or twenty of these on a more vertically-scaled VM or machine would start to strain the network throughput of even a 2.5Gbps link. Many cheap-ish machines, each with their resourcing (including their own network bandwidth), all instantaneously reserved and released at one machine per request is a perfect match for the demand profile of these use-cases.

Re: The demise of the mildly dynamic website (2022)

#97

Post by EGreg »

troupo wrote: post #81
EGreg wrote: post #70

Earlier quoted context omitted.

Lambda is like CloudFlare workers. They are deployed AT THE EDGE TO THE CDN, and therefore can handle requests without hitting your network and database. For example I recommend your servers sign all the session IDs they give out, so they can easily be discarded if the signature doesn’t match or if they’ve been blacklisted. Such decisions can be made without doing any I/O, or by checking a local cache that was built…

> where you might not build ANY back end at all, just use some sort of JAM stack. So, a backend > And now, CloudFlare Workers supports a key-value store and a SQL database So, a backend.

A back end with autoscaling on CDN.

Not a single server, like you'd set up.

Re: The demise of the mildly dynamic website (2022)

#98

Post by pixl97 »

graemep wrote: post #24
pixl97 wrote: post #22

Earlier quoted context omitted.

I mean, typically hosting a static site that's fine, but with the number of exploits these days and the ability for people to chain them together, maybe you don't even realize your box has been exploited? Uptimes in years means your box, especially without updates has something it could be targeted with.

Most of those that are find for a static site but not dynamic are those that are not fixed by just applying updates from the distro. You still need to update your app code even if you are using someone elses servers, so its the same either way.

Note that the parent said "uptimes measured in years", so they are either using a more complex system with multiple servers, or they are not doing security updates.

Re: The demise of the mildly dynamic website (2022)

#100

Post by hu3 »

spacebuffer wrote: post #99

Semi-related: what's the best place to learn the old school style of working with php, I already know laravel but it feels so far removed from normal php that I am not confident working with it on it's own.

I would try some "old style" php frameworks. Like CodeIgniter or Yii.

If you want even simpler, then maybe try Slim framework. You'll have to add your own data access lib.

If you want Grug brain PHP then there's https://github.com/bcosca/fatfree

You can also use composer package manager to build your framework with libs like routing, sql query builder, etc.

Post reply on HN