Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

1–10 of 365 posts

Re: Hard-won lessons: Five years with Node.js

#2
The biggest hard lessons I've had with Node.js have been around handling errors - when I first deployed https://www.findlectures.com, I was shocked to realize that uncaught errors could take down the whole site. Not handling error callbacks is also a big problem - TypeScript has been an awesome solution though, because it can show compilation errors if you screw up function arguments.

Re: Hard-won lessons: Five years with Node.js

#3
Something I found surprising was the 1.5 GB limit per process when used on Heroku (https://devcenter.heroku.com/articles/node-concurrency), which afaik can be circumvented elsewhere (https://futurestud.io/tutorials/node-js-increase-the-memory-...).

This can be problematic at times if you need to open a very large number of concurrent connections (crawlers, slack connections etc), and can force you to organize a "cluster" of processes before you really want it.

Re: Hard-won lessons: Five years with Node.js

#4

The biggest hard lessons I've had with Node.js have been around handling errors - when I first deployed https://www.findlectures.com , I was shocked to realize that uncaught errors could take down the whole site. Not handling error callbacks is also a big problem - TypeScript has been an awesome solution though, because it can show compilation errors if you screw up function arguments.

That's not Node.js. That's Express or a similar abstraction.

You can execute everything inside a promise like with Koa, which amounts to something like:

    http.createServer((req, res) => {
      handle(req)
        .then((response) => res.send(response))
        .catch(() => res.send(500))
    })
    
Where `handle` is an async function and thus all your application logic is in async/await space.

Re: Hard-won lessons: Five years with Node.js

#5

The biggest hard lessons I've had with Node.js have been around handling errors - when I first deployed https://www.findlectures.com , I was shocked to realize that uncaught errors could take down the whole site. Not handling error callbacks is also a big problem - TypeScript has been an awesome solution though, because it can show compilation errors if you screw up function arguments.

That's not Node.js. That's Express or a similar abstraction. You can execute everything inside a promise like with Koa, which amounts to something like: http.createServer((req, res) => { handle(req) .then((response) => res.send(response)) .catch(() => res.send(500)) }) Where `handle` is an async function and thus all your application logic is in async/await space.

But you're still error handling with `.catch()`. Without that, you'd have an uncaught Promise rejection, which could take down your Node process.

Re: Hard-won lessons: Five years with Node.js

#7

Earlier quoted context omitted.

That's not Node.js. That's Express or a similar abstraction. You can execute everything inside a promise like with Koa, which amounts to something like: http.createServer((req, res) => { handle(req) .then((response) => res.send(response)) .catch(() => res.send(500)) }) Where `handle` is an async function and thus all your application logic is in async/await space.

But you're still error handling with `.catch()`. Without that, you'd have an uncaught Promise rejection, which could take down your Node process.

It's common for people to complain about something like a syntax error taking down their whole process, so that's how I read it -- that you're trying to do "too much" catching.

Re: Hard-won lessons: Five years with Node.js

#9

Earlier quoted context omitted.

But you're still error handling with `.catch()`. Without that, you'd have an uncaught Promise rejection, which could take down your Node process.

It's common for people to complain about something like a syntax error taking down their whole process, so that's how I read it -- that you're trying to do "too much" catching.

I'm not an expert with​ deploying application servers but shouldn't part of handling lifecycle include the ability for a service to crash and be respawned?

Ie. Be okay if a syntax error crashes your server.

Re: Hard-won lessons: Five years with Node.js

#10

Earlier quoted context omitted.

It's common for people to complain about something like a syntax error taking down their whole process, so that's how I read it -- that you're trying to do "too much" catching.

I'm not an expert with​ deploying application servers but shouldn't part of handling lifecycle include the ability for a service to crash and be respawned? Ie. Be okay if a syntax error crashes your server.

Yes you should be using a process manager like PM2.
Post reply on HN