Same exists in Node, using PM2 process monitor via rsync/ssh:
https://pm2.keymetrics.io/docs/usage/deployment/
Run a command, new code is pushed to server files, you have a file-watcher daemon monitoring the directory and stopping + restarting the app, or you run stop/start as part of the deploy command.
Arguably, this is the model of CGI, which is about a decade older. Every time you hit a page on a CGI-powered service, it starts up a new process that runs your script. So you just edit a shell/Perl/PHP/Python/etc. file in place (or edit it locally, and FTP/SCP/etc. it to the remote host) and immediately on the next page load you see the impact of your change.
It was kind of the original "serverless" - you'd often host it on a shared (multitenant) server with other users, with someone operating the web server for you and providing you with storage space. And it was a great development experience for small sites, especially for people new to web programming, and I miss it a lot.
For performance reasons people built "FastCGI" where you have a long-running process that handles multiple requests, and for software engineering scaling reasons people moved away from the model of one file on disk per URL (and URLs mostly mapping to file paths on disk), and then eventually we got the setup we have now.
Thanks for sharing! I have to admit that I am probably very ignorant of backend dev paradigms in general since I got my start in frontend dev. Definitely cool to see that I'm not anywhere close to the first one to find this kind of workflow compelling.
IMO the possibility for an air-tight feedback loop is _the_ killer feature for interpreted languages vs compiled ones. I can always feel my productivity plummet whenever I work in an environment that takes that away from me. I wish more people would try to take advantage of it.
Some frameworks will offer this as part of the development process with a development server. Mojolicious (Perl) for example ships with Morbo as a development webserver, and Hypnotoad as a more enterprise ready one. One of the major differences is that morbo will take a path and auto-reload if any file in it updates, while hypnotoad offers zero downtime reloads, but you have to manually tell it to restart.
Arguably a delineation like this is better, even if just a single flag separating the behavior in the server, since it allows production to not worry about some file copies/changes forcing lots of reloads that aren't needed, which isn't really a problem in most development environments.
Comments
This is a really old concept with interpreted languages, Capistrano in Ruby came out in 2006 for this sort of workflow:
10 year old gist for this exact thing: Same exists in Node, using PM2 process monitor via rsync/ssh: Run a command, new code is pushed to server files, you have a file-watcher daemon monitoring the directory and stopping + restarting the app, or you run stop/start as part of the deploy command.Arguably, this is the model of CGI, which is about a decade older. Every time you hit a page on a CGI-powered service, it starts up a new process that runs your script. So you just edit a shell/Perl/PHP/Python/etc. file in place (or edit it locally, and FTP/SCP/etc. it to the remote host) and immediately on the next page load you see the impact of your change.
It was kind of the original "serverless" - you'd often host it on a shared (multitenant) server with other users, with someone operating the web server for you and providing you with storage space. And it was a great development experience for small sites, especially for people new to web programming, and I miss it a lot.
For performance reasons people built "FastCGI" where you have a long-running process that handles multiple requests, and for software engineering scaling reasons people moved away from the model of one file on disk per URL (and URLs mostly mapping to file paths on disk), and then eventually we got the setup we have now.
Thanks for sharing! I have to admit that I am probably very ignorant of backend dev paradigms in general since I got my start in frontend dev. Definitely cool to see that I'm not anywhere close to the first one to find this kind of workflow compelling.
IMO the possibility for an air-tight feedback loop is _the_ killer feature for interpreted languages vs compiled ones. I can always feel my productivity plummet whenever I work in an environment that takes that away from me. I wish more people would try to take advantage of it.
Some frameworks will offer this as part of the development process with a development server. Mojolicious (Perl) for example ships with Morbo as a development webserver, and Hypnotoad as a more enterprise ready one. One of the major differences is that morbo will take a path and auto-reload if any file in it updates, while hypnotoad offers zero downtime reloads, but you have to manually tell it to restart.
Arguably a delineation like this is better, even if just a single flag separating the behavior in the server, since it allows production to not worry about some file copies/changes forcing lots of reloads that aren't needed, which isn't really a problem in most development environments.