Hacker News Reader

Comment by omgitsabird | Hacker News Reader

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

It's a single file app ;)

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.

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…

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

Reply on news.ycombinator.com