CODEWITHSUNDEEP
node.jsexpresssails.js
Markus
Markus

Reputation: 1214

Server latest assets/views automatically

I am running SailsJS in production with forever and the development has been working great so far. But coming from a PHP background there seem to be a few things still not working as smoothly in production. One of the biggest pains we had recently, is when you update an asset or a view (in our case an ejs file) the server has to be restarted to serve the latest files.

One solution I could use with sails is run a grunt watchtask in production or use forever -w, but both seem a bit unnatural, having to 'watch' for filechanges, rather than just displaying the latest.

Not sure if that is an issue purely with Sails but I would guess this is more of a general problem with Express and Node. So is there any way to have a Sails/Express/Node server always display the newest assets/files/views without having to explicitly watch for them?

Upvotes: 0

Views: 115

Answers (1)

Bobby
Bobby

Reputation: 1482

Express should render the template on the fly--maybe I'm missing something with the SailsJS setup though. If that is the case, this question might help: Sails.js application not refreshing files from assets after start.

As for the other things in this realm that might not be "working as smoothly":

In a typical setup, possibly unlike you might in PHP, you would deploy the entire site as opposed to just one file. This is mostly to do with the fact that you are running Node.JS as a stand-alone service, and you want everything that pertains to that instance to be packaged together in each deployment. Not to mention, you probably don't want to ever have to worry about the incurred overhead with monitoring the file system for changes, so this behavior is most useful in a dev environment.

That means too that if you're serving static files, you should probably setup your web server to serve them from the file system directly, as opposed to letting your node application serve them. In fact, that alone could reduce your asset download time by a factor of 5 to 10.

A setup that I commonly use for my applications is this: git to deploy your application (using the post-receive hook) and daemontools to make sure that the service stays up. This would give you a slick deployment setup similar to Heroku or Nodejitsu.

I believe this is a common setup for production Node.JS systems. And, after my own research into what was available out there about a year ago, there really wasn't anything that I would consider solid and reliable (including Forever) in terms of what years of the *nix community has already accomplished.

daemontools is far superior to even a lot of other *nix service managers, but it's not commonly employed because its author, DJB, believes that software shouldn't concern itself with things like being a service. This is exactly what makes it ideal for Node.JS applications, though a little bit less ideal for a lot of Unix applications that are still built as stand-alone services (though a lot of software can work with daemontools by allowing for a non-daemon mode, not all software will, which means that distributions need to develop their own solutions).

With that, you can't always guarantee that the service won't crash with node, and that those crashes won't pollute the server's resources, even if you're able to "catch" them. It almost works better to capture exceptions into a log or email, let the service fail, bail, and cleanup, and then have daemontools kick it back off automatically. You can read more about error handling in Node.JS here: http://nodejs.org/api/domain.html

Upvotes: 1

Related Questions