4 ms·

One of the most exciting opportunities IMO that Deno opens up, compared to most traditional server-side frameworks, is the possibility for simple url-based live

One of the most exciting opportunities IMO that Deno opens up, compared to most traditional server-side frameworks, is the possibility for simple url-based live-reload workflows in production. I'd love to be able to develop backend services by pushing source code to some url as I develop, and then have the production instances of the service notified of the changes and reload themselves immediately for a super-tight feedback loop. In theory, building this kind of workflow in Deno should be very feasible, so I'm hoping to give it a shot in the not too distant future, but I'm wondering if anyone else has already tried it?

tlarkworthy 5y ago
I built this https://webcode.run/ https://webcode.run/
- aboutaaron 5y ago
  This looks super dope. I also love Observable and have wanted to find more ways to leverage it. This seems perfect!
tengbretson 5y ago
This is the biggest upside I see for Deno. I imagine a lot of fat could be trimmed in service orchestration with something that simply resembles a headless browser, and all it takes to deploy new code to your running service is giving it the equivalent of an `f5` and you're on your way. Heck lets get this headless browser running in Ring 0 and skip to the end of Gary Bernhardt's dream.
gavinray 5y ago
This is a really old concept with interpreted languages, Capistrano in Ruby came out in 2006 for this sort of workflow: https://en.wikipedia.org/wiki/Capistrano_(software) 10 year old gist for this exact thing: https://gist.github.com/rchampourlier/1281506/a22148264c457ebb69259261f117548569be6bef 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.
- eins1234 5y ago
  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.
- geofft 5y ago
  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.
- deleted 5y ago
  [deleted]
- kbenson 5y ago
  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.

tlarkworthy 5y ago

I built this https://webcode.run/ https://webcode.run/

aboutaaron 5y ago
This looks super dope. I also love Observable and have wanted to find more ways to leverage it. This seems perfect!

tengbretson 5y ago

This is the biggest upside I see for Deno. I imagine a lot of fat could be trimmed in service orchestration with something that simply resembles a headless browser, and all it takes to deploy new code to your running service is giving it the equivalent of an `f5` and you're on your way. Heck lets get this headless browser running in Ring 0 and skip to the end of Gary Bernhardt's dream.

gavinray 5y ago

This is a really old concept with interpreted languages, Capistrano in Ruby came out in 2006 for this sort of workflow: https://en.wikipedia.org/wiki/Capistrano_(software) 10 year old gist for this exact thing: https://gist.github.com/rchampourlier/1281506/a22148264c457ebb69259261f117548569be6bef 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.

eins1234 5y ago
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.
geofft 5y ago
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.
deleted 5y ago
[deleted]
kbenson 5y ago
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.