Hacker News Reader

Comment by jeffreyrogers | Hacker News Reader

This reminds me of how deployment used to be for simple things on the web. You'd develop locally then ftp it onto your servers.

View on HN

I understand what you are saying, but simple things still exist, and it is the same way as it used to be.

agreed. I make the same point about LEGO. whenever yet another person complains about all the big/special pieces that have become more common in recent years. Its like... do they realize we still have all the same basic rectangular bricks, plates and tiles we ever had? except in many more colors and variants and ponies and rainbows and BBQ etc etc etc.

The old web is still there for us, if we let it, just as the old LEGO is still. we simply have to choose them, and promote them, and build with them.

Its fully up to us.

Wait BBQ?

ssshhhhhh!

IIRC, this is exactly how prolific indie startup founder levelsio does it to this day.

Described here https://levels.io/deviance/ (Dec 10, 2020)

> I write my code in Sublime Text, then I test it on my laptop (I have NGINX locally, so I open nomadlist.test for ex), then if it works I upload it with Panic Transmit via SFTP.

My naive question is: what happens if one user (or more) is making a payment at the very exact moment the code uploading is happening? My naive answer is: I don’t know, it could crash (e.g., half the code base has been uploaded to the server but the other half is still being transmitted… but code in the first half references code in the second) or not.

Am I missing something? I imagine failures like this one are of no importance to the author (which is totally fine, trade offs I know).

The way it used to work was that the upload went into a copy of the website, ideally created on a COW (copy-on-write) filesystem to avoid copying files that hadn’t changed and then you would change an alias or hard link to point to the new upload after confirming it was all there. Existing transactions would continue using the PHP code or whatnot stored in a cache (e.g. xcache or apc cache, but the new code could be read in and then new incoming requests could switch over so the new code starts serving new incoming requests when the new page cache is primed. Fancy configurations might use sessions for this, if there was shared session state to migrate. That said… most of the time, most folks didn’t think much of the occasional 500 as something new deploys. After all, you refresh and it’s gone, most of the time. And your internet or computer or browser is often as much to blame for problems as the website deploy, if it affects very few users during infrequent deploys of changed pages. The more fun task was what to do about database migrations. The traditional approach is “just take the site down for a minute, nobody cares,” as I said…

Probably the third-party payment integration is available (that is not a single php uploaded manually :)). So either the api call goes through and it gets completed or it does not go through and no charges. As long as the whole payment is on a third-party (like Stripe) I do not think there would be an undefined state.

It's a single file app ;)

He's proof that techies overthink things... he's doing $1M+ yearly with nomadlist.

Not only that—it used to perform really well.

For years, a repeated (if, sadly, uncommon) experience for me has been:

"Holy shit, this web site/app is fast!"

Looks at URL bar, sees a '.php' at the end

Yeah, I remember I used to work at a perl webshop, and I was experimenting with PHP.... I actually lost a half hour or so trying to figure out how to get my site to refresh and rerender, and it turned out it was! But it was so much faster than Perl that I assumed nothing was happening. Hey, I was young, don't be too hard on me!

There's a web framework performance comparison project out there that makes HN from time to time, and IIRC the findings have been you basically can't reliably beat PHP performance at serving dynamic web sites without resorting to a compiled language—and even then, it's far from guaranteed.

I haven't written much PHP in a long time, but I'd believe it. There are some really slow programs in PHP (Wordpress...) but the language is damn fast. Its tendency to be only a thin wrapper over C or C++, such that one rarely spends much time in PHP itself, is probably the main reason.

I'd absolutely believe that. A bigger contributing factor was that our Perl site was launching a process that parsed some libraries and then served HTML. While the php site was using a server extension that kept a parent process running and just spawned a thread for page requests.

Again, don't judge me - I was very, very young. :-)

I remember those days. Before framework were popular for PHP sites and SQL injection was not just possible but expected for anything that ended in .PHP or .php3 …

SFTP live editing ftw!

under construction gifs abounded but the rough edges made things a bit more approachable.

For individual developers not working in teams this is still a pretty good approach.

Reply on news.ycombinator.com