3 ms·

You nailed it. Three major things I care about for my application: - Logging - Metrics/Instrumentation/Tracing (memory usage, transactional performance monito

You nailed it. Three major things I care about for my application: - Logging - Metrics/Instrumentation/Tracing (memory usage, transactional performance monitoring, etc) - Surviving exceptions All of these are either very immature in Node or simply so far behind they may as well not exist. By nature of running in an application server, you do get a lot of benefits right off the bat for all of those, but even if you're running an executable jar instead of deploying to Tomcat stray exceptions will in almost no cases cause your application to simply die for all requests. Also, say what you want about the verbose try/catch Exception model, but at least you can count on it. Am I getting an Error in this callback or is an exception going to get thrown? Oh, they leaked an exception when I was prepared to handle an Error and now my entire server is down. Does your process automatically restart? Not likely unless you spent a lot of time hand crafting your service to be daemonized, which is generally FAR beyond the scope of most developers I've met in any language (which also upsets me).

JdeBP 10y ago
If one is spending any time hand-crafting the program to daemonize itself on a Unix or a Unix-alike, one is doing things wrongly. On those operating systems, since the advent of the System Resource Controller in 1992 the right way to write a program that runs under a service manager is to write a program that runs in the normal way. No "daemonization" needed. * http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.ht... * http://jdebp.eu./FGA/systemd-house-of-horror/ http://jdebp.eu./FGA/systemd-house-of-horror/
NoInkling 10y ago
Promises and now async/await go a long way to remedy the discrepancy between synchronous exceptions and asynchronous errors, by helping ensure that they both end up as promise rejections (as long as promises/async functions are your de facto async abstraction) while also being handleable with try/catch. The Koa framework (and in the future Express I believe) is designed around this concept, so middleware-level promise rejections can be handled in a single place, and by default simply produce an HTTP error response. It is a shame that it's going to take a while for the Node stdlib to catch up, however. Also I thought something like PM2 (https://github.com/Unitech/pm2 https://github.com/Unitech/pm2) or Forever (https://github.com/foreverjs/forever https://github.com/foreverjs/forever) was pretty much standard for production Node apps?
- nogbit 10y ago
  Spot on! And with node version 8, due out any week, we no longer needs babel on the server when doing async/await/import. It will all be there natively. We use PM2 in production for web apps, long running processes (console apps with rethinkdb change feeds) and cron to spin up command line apps for data transformations, SaaS integrations, bots and more. Most of us use VS Code now (I still use Vim)...so yes, having done enterprise work with a full blown IDE and tooling can be very helpful as the Node debugging and profiling experience is not great (but getting a ton better). In the past we had a ton of C#/.net in production, then Ruby and now JS for the indefinite future. We build things that end up in production for 10 years or more, so having that talent pool to pull from in the future will be great.

JdeBP 10y ago

If one is spending any time hand-crafting the program to daemonize itself on a Unix or a Unix-alike, one is doing things wrongly. On those operating systems, since the advent of the System Resource Controller in 1992 the right way to write a program that runs under a service manager is to write a program that runs in the normal way. No "daemonization" needed. * http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.ht... * http://jdebp.eu./FGA/systemd-house-of-horror/ http://jdebp.eu./FGA/systemd-house-of-horror/

NoInkling 10y ago

Promises and now async/await go a long way to remedy the discrepancy between synchronous exceptions and asynchronous errors, by helping ensure that they both end up as promise rejections (as long as promises/async functions are your de facto async abstraction) while also being handleable with try/catch. The Koa framework (and in the future Express I believe) is designed around this concept, so middleware-level promise rejections can be handled in a single place, and by default simply produce an HTTP error response. It is a shame that it's going to take a while for the Node stdlib to catch up, however. Also I thought something like PM2 (https://github.com/Unitech/pm2 https://github.com/Unitech/pm2) or Forever (https://github.com/foreverjs/forever https://github.com/foreverjs/forever) was pretty much standard for production Node apps?

nogbit 10y ago
Spot on! And with node version 8, due out any week, we no longer needs babel on the server when doing async/await/import. It will all be there natively. We use PM2 in production for web apps, long running processes (console apps with rethinkdb change feeds) and cron to spin up command line apps for data transformations, SaaS integrations, bots and more. Most of us use VS Code now (I still use Vim)...so yes, having done enterprise work with a full blown IDE and tooling can be very helpful as the Node debugging and profiling experience is not great (but getting a ton better). In the past we had a ton of C#/.net in production, then Ruby and now JS for the indefinite future. We build things that end up in production for 10 years or more, so having that talent pool to pull from in the future will be great.