2

A browser fetches some HTML via HTTP/HTTPS or a file, which may result in fetching a bunch of other resources, including some JavaScript, and then it runs it in a browser environment. I would describe this as a mechanism for delivering code to the browser.

Does a similar web-based delivery mechanism exist for Node.js apps? Is there a way to get everything that a node.js app needs to run via HTTP(S) and run in some kind of "node" environment? Sort of like a headless browser, but no HTML?

I'm asking this in the context of updating node.js apps. I really like how a server is in charge of the code that the browser is running. I think the same thing would be great for a certain class of node.js app. It would be great if a node.js could auto-update itself in a straightforward and secure way. This was the first thing that came to mind.

After thinking about this in detail, it seems necessary to containerize the application and use a mechanism like Docker to deliver the application in its entirety to the machine that will run the app. There just needs to be some supporting mechanism for ensuring that the app is always up to date. I know there are docker-compose and kubernetes, and things like Watchtower, but is this really the best way for just keeping the application up to date? During development it seems like the mechanism is copying code (like through git) and installing dependent packages (like via NPM). But this is a very developer-centric workflow. Internally, I guess it makes sense to use docker. But for web-delivery, I think a workflow for deploying a node.js-centric application and keeping it up to date would use some other mechanism. What is that mechanism? If docker is the way, then maybe I just need to refocus my question to find out how to auto-update docker containers. But I'm fairly certain that exposing the docker API directly isn't really a secure option for web-delivery. I also don't even know how node-based apps are typically delivered. The few that I have actually get installed via the OS's installer mechanism (Like an .msi on Windows) - and that seems very native. Surely there must be a more web-centric approach.

So, how should a Node application auto-update itself (or receive a push update) via the web? (like a browser-based app does)

1

I'm not aware of a project that provides that out of the box. For local development, it is common to have hot reload. If something at the file level changes, it restarts the server. That is somewhat related, as you could trigger the updates on the file system remotely. Installing libraries could also be simulated by directly updating the node_modules folder.

Beside that NodeJs itself provides ways to run arbitrary code without process restarts. One way is to use eval (as part of JavaScript). The other is to reload a file. Normally, require caches the file after it executed it, but you can purge this cache (require.cache), and require the file again. That is what the decache library does.

In theory, NodeJs provides all the tools to allow remote code being applied. Of course, from a security perspective, you open yourself to all kind of attacks. Make sure requests come from a trusted source.

But for web-delivery, I think a workflow for deploying a node.js-centric application and keeping it up to date would use some other mechanism. What is that mechanism? If docker is the way, then maybe I just need to refocus my question to find out how to auto-update docker containers

I would also see it less as a matter of updating a NodeJs application (driven by the application itself), but rather as of a good deployment pipeline (driven from outside). In the end, deployment is nothing else than pushing changes to production.

There are a variety of deployment approaches for NodeJs applications:

If you are not sure, the easiest to get started with are serverless deployments (supported on all major providers: AWS Lambdas, Google Cloud Functions, Azure Functions), or platform as a service solutions (e.g., Heroku). Kubernetes (as a popular framework for deploying Docker containers) is powerful, but has a steep learning curve.

| improve this answer | |
  • I agreed with everything you said except "deployment is nothing else than pushing changes to production". I'm more interested a certain kind of node.js app that is actually run by the consumer's own machine and the consumer gets value from running this software on their own machine, as opposed to a "production server" that gives the consumer value when they access it through a web API. Certainly its a more common use case for node.js apps to be servers, but there could also use cases for apps that run directly on consumer's machines - and I'm contemplating how one would deploy such apps. – Wyck Nov 26 '19 at 4:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.