3 ms·

> 1. If a file upload failed your site was broken until you managed to upload it again. I don't think an scp ever went wrong for me. But maybe your lan network

> 1. If a file upload failed your site was broken until you managed to upload it again. I don't think an scp ever went wrong for me. But maybe your lan network is different. > 2. Deploying something that required a database migration had to be done out of hours, or the site had to be taken offline to do it. Does webpack handle db migrations too? I didn't know. I was talking about js/html/css assets. Not the backend. > 3. Recovering from a disaster was hard, and pretty much always resulted in significant data loss. I don't know your specifics, but recovering from a disaster in this case is getting up an other server (or serverS) and copy the files over. > 4. Moving a site from one server to another was awful, because it meant SSH'ing (or telnet'ing...) on to the box and compiling things from source. That's the nice thing about mod_pagespeed: you don't compile anything. > 5. If you worked on anything that ran on multiple servers you pretty much had to script it all anyway. What's wrong with scripting everything? I like automation.

onion2k 9y ago
I don't think an scp ever went wrong for me. But maybe your lan network is different. When I started doing web things rcp (or scp, or rsync, etc) access was quite unusual. You had FTP and that was it. It failed a lot. Does webpack handle db migrations too? I didn't know. I was talking about js/html/css assets. Not the backend. Fair enough. I don't really see the front end asset pipeline as being separate to the backend. It's all just stuff you build and deploy. That's the nice thing about mod_pagespeed: you don't compile anything. Well, you do, but you're happy just accepting the mod_pagespeed defaults are doing a great job (which they are). I want a bit more control over things, and I want to do things that mod_pagespeed can't do, which is why I use Webpack instead. A trivial example: mod_pagespeed doesn't do subresource integrity hashes. Webpack has webpack-subresource-integrity as a plugin that can automatically write hashes to your html. That's useful to me. It's good that there are different options for different things, and better that the industry is coalescing around small number of different tools so there aren't too many different ways of doing things. What's wrong with scripting everything? I like automation. Nothing at all. Automate all the things! My point is that back in the olden days of making web things we didn't automate things, so it was much, much harder. Today's tools (eg things like Webpack) make automating your build process pretty trivial. It's far better now.
- sli 9y ago
  There was also a risk, with things like mod_php and the like, that a user could hit your app in the middle of an upgrade. Commonly in those days (for many, not all), the app was tied rather tightly to the webserver. That is no longer the norm, it's more typical to reverse proxy to an app server or something like that. And sure, staging then copying everything would be faster and safer than deploying straight on top of the old version, but that's still a not-insignificant amount of time when the app is in a transient, partially-upgraded state. And that would only get worse as your app grew. I suppose to way around that would be to deploy twice and use a load balancer that you could temporarily disable, upgrade one deployment, point the load balancer only to there, upgrade the other one, then re-enable load balancing between them. Man, that's a lot of work, though. I'll agree that maybe it's a relatively minor complaint, because there are likely plenty of solutions I just never needed to find, but I really do like avoiding anything that can and should be avoided. I'd rather have a "Please wait while we upgrade" page than risking something going south due to some kind of race condition.
- Fnoord 9y ago
  The r-services were used a lot on and between Unices. FTP did fail a lot indeed. That is why scene (FTP / FXP) used .rar, .sfv and Usenet .rar, .par(2). Download clients had resuming support but did not attempt verification. That's why checking checksum is important (Sfv is just CRC32 and Par is Reed Solomon, other examples are MD5 and SHA1). Later on scene used so-called auto traders, which utilized FXP and automatically verifying checksums plus anticipating on errors (such as dupes). The I know was called Preee (Windows only, worked in Wine). Later protocols like BitTorrent implemented checksum verification within the protocol.

onion2k 9y ago

I don't think an scp ever went wrong for me. But maybe your lan network is different. When I started doing web things rcp (or scp, or rsync, etc) access was quite unusual. You had FTP and that was it. It failed a lot. Does webpack handle db migrations too? I didn't know. I was talking about js/html/css assets. Not the backend. Fair enough. I don't really see the front end asset pipeline as being separate to the backend. It's all just stuff you build and deploy. That's the nice thing about mod_pagespeed: you don't compile anything. Well, you do, but you're happy just accepting the mod_pagespeed defaults are doing a great job (which they are). I want a bit more control over things, and I want to do things that mod_pagespeed can't do, which is why I use Webpack instead. A trivial example: mod_pagespeed doesn't do subresource integrity hashes. Webpack has webpack-subresource-integrity as a plugin that can automatically write hashes to your html. That's useful to me. It's good that there are different options for different things, and better that the industry is coalescing around small number of different tools so there aren't too many different ways of doing things. What's wrong with scripting everything? I like automation. Nothing at all. Automate all the things! My point is that back in the olden days of making web things we didn't automate things, so it was much, much harder. Today's tools (eg things like Webpack) make automating your build process pretty trivial. It's far better now.

sli 9y ago
There was also a risk, with things like mod_php and the like, that a user could hit your app in the middle of an upgrade. Commonly in those days (for many, not all), the app was tied rather tightly to the webserver. That is no longer the norm, it's more typical to reverse proxy to an app server or something like that. And sure, staging then copying everything would be faster and safer than deploying straight on top of the old version, but that's still a not-insignificant amount of time when the app is in a transient, partially-upgraded state. And that would only get worse as your app grew. I suppose to way around that would be to deploy twice and use a load balancer that you could temporarily disable, upgrade one deployment, point the load balancer only to there, upgrade the other one, then re-enable load balancing between them. Man, that's a lot of work, though. I'll agree that maybe it's a relatively minor complaint, because there are likely plenty of solutions I just never needed to find, but I really do like avoiding anything that can and should be avoided. I'd rather have a "Please wait while we upgrade" page than risking something going south due to some kind of race condition.
Fnoord 9y ago
The r-services were used a lot on and between Unices. FTP did fail a lot indeed. That is why scene (FTP / FXP) used .rar, .sfv and Usenet .rar, .par(2). Download clients had resuming support but did not attempt verification. That's why checking checksum is important (Sfv is just CRC32 and Par is Reed Solomon, other examples are MD5 and SHA1). Later on scene used so-called auto traders, which utilized FXP and automatically verifying checksums plus anticipating on errors (such as dupes). The I know was called Preee (Windows only, worked in Wine). Later protocols like BitTorrent implemented checksum verification within the protocol.