Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Aspects of Building a Node.js Application

engineering.gosquared.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Aspects of Building a Node.js Application

#11

Post by gnw »

crazygringo wrote: post #6
simontabor wrote: post #4

Earlier quoted context omitted.

As said in the post, Capistrano is a good option but we found we much preferred deliver, it was easier to setup and meant we didn't need ruby dependencies on node.js apps. We also used to SSH into our servers and do everything manually. Crazy times.

Genuine question (since I'm doing the same with AWS right now) -- I wrote a script which makes an API call to Amazon to find the name of each of my instances, then SSH's into them automatically to do the equivalent of a git clone or update. Seems to work so far -- any reason why I might want to be using a more advanced tool instead?

If it works for you for now then no real need to change it. A proper deployment tool usually makes it easier to deploy apps of different types and languages using a consistent set of tools.

What I do when working with SSH'ing to AWS instances is to give them a readable name (like nginx-1, nginx-2) tag, and then place those names as hostnames in my /etc/hosts, so I can then just run ssh nginx-1. I use a script around https://github.com/bjeanes/ghost to automate this.

Re: Aspects of Building a Node.js Application

#13

Post by latchkey »

gnw wrote: post #5
jeswin wrote: post #3

First of all, nodejs is a great choice. Having to worry about just one programming language helps a lot. I'll add a few things I found out along my ongoing experiment. 1. Tests are essential in any project using a dynamic language; but don't write regular unit tests. Instead write a setup script. A script that sets up basic data in the store by calling various APIs. For example, setup your test users POSTing to /user…

Great pointers, setup scripts and automating project chores are essential for creating a good workflow, saving time, and saving colleagues some hair when they get started with the app. I've tried coffeescript but it didn't catch on with me. Perhaps I didn't give it enough time, but I got the feeling that it could get quite semantically ambiguous at times whereas if you stick to JS' native C-style form, the structure…

a) You can always see the source output and it is easily readable. b) CS really doesn't do anything magic in the output.

Give it more time, the gains for CS are worth any negatives you can conjure up. do ->, classes, simple for loops, equality, etc.

Re: Aspects of Building a Node.js Application

#15

Post by latchkey »

gnw wrote: post #14
latchkey wrote: post #8

In working with my app, I've found that Domains http://nodejs.org/api/domain.html are crucial for wrapping 3rd party async code that can crash on errors.

Absolutely, although Domains are a new feature in 0.8 and will need some time for maturity.

When your nodejs instances are crashing several times an hour due to facebook randomly returning html instead of json and the 3rd party library crashing as a result, who has time for maturity? =)

Re: Aspects of Building a Node.js Application

#16

Post by mnutt »

gnw wrote: post #11
crazygringo wrote: post #6

Earlier quoted context omitted.

Genuine question (since I'm doing the same with AWS right now) -- I wrote a script which makes an API call to Amazon to find the name of each of my instances, then SSH's into them automatically to do the equivalent of a git clone or update. Seems to work so far -- any reason why I might want to be using a more advanced tool instead?

If it works for you for now then no real need to change it. A proper deployment tool usually makes it easier to deploy apps of different types and languages using a consistent set of tools. What I do when working with SSH'ing to AWS instances is to give them a readable name (like nginx-1, nginx-2) tag, and then place those names as hostnames in my /etc/hosts, so I can then just run ssh nginx-1. I use a script around…

The script looks nice, though if you don't want to have to use sudo to update /etc/hosts you can also just add entries in ~/.ssh/config. Downsides are that it only works for ssh-based activities.

Re: Aspects of Building a Node.js Application

#17

Post by doomslice »

latchkey wrote: post #15
gnw wrote: post #14

Earlier quoted context omitted.

Absolutely, although Domains are a new feature in 0.8 and will need some time for maturity.

When your nodejs instances are crashing several times an hour due to facebook randomly returning html instead of json and the 3rd party library crashing as a result, who has time for maturity? =)

Wouldn't a simple uncaughtException handler be sufficient to prevent most crashes?

    process.on('uncaughtException', function (err) {
      // log it
    });

Re: Aspects of Building a Node.js Application

#18

Post by ajacksified »

jeswin wrote: post #3

First of all, nodejs is a great choice. Having to worry about just one programming language helps a lot. I'll add a few things I found out along my ongoing experiment. 1. Tests are essential in any project using a dynamic language; but don't write regular unit tests. Instead write a setup script. A script that sets up basic data in the store by calling various APIs. For example, setup your test users POSTing to /user…

I agree with most of this - great tips. However, for almost all applications, you'll want to render on the server, and bootstrap data on the client so that the client can take over and begin rendering using something like Backbone. This can be done by dropping a big json object on the page for the client to read as it initializes it's Backbone (or any framework) application.

This will solve the issues you'll run into later such as

* SEO - search engines won't read empty pages (you can get around this with some hacks) * Performance - loading a full page is always much, much faster than loading half a page, downloading javascript, parsing javascript, sending off multiple ajax requests for data, and then finally rendering the first page * Accessibility - a version of your site that works without javascript is not only easy to build, but is easier for machine reading * Development cleanliness - building your site in layers (html / http only, layer on css, layer on more advanced css, layer on javascript) keeps your code from becoming too tightly coupled and is much easier to work with. Plus, this makes it much easier to work with less advanced browsers

It's actually quite simple to do, especially with node, where you can share functions to format data, or even run the same framework on both side if you decouple your code (Backbone's latest change to help abstract Ajax seems like a step in this direction.)

Re: Aspects of Building a Node.js Application

#19

Post by aroman »

latchkey wrote: post #8

In working with my app, I've found that Domains http://nodejs.org/api/domain.html are crucial for wrapping 3rd party async code that can crash on errors.

I've had a similar need in my app, which has been in use since 0.6. I ended up basically abusing child_process.fork() -- every call to a certain rather long-running, possibly exploding async function is made not from the main node.js process, but is actually spawned as a separate process from node. So if it explodes, the core app instance isn't affected. Of course I do some intelligent things such as kill these "worker forks" if they take longer than 30 seconds, and I check for various UNIX signals to watch if they die and react appropriately.

I also tie the worker PID to each user's session, so they can't spawn an infinite number of workers and cause serious strain on the server -- the server just kills the previous worker and spawns a new one if it's asked to run the function again.

I was actually thinking about opensourcing this, but I guess it's pointless now that domains basically do what I hacked together.

Re: Aspects of Building a Node.js Application

#20

Post by mscdex »

simontabor wrote: post #4
hackerboos wrote: post #2

Can't you just use Fabric or Capistrano for deployment? I can't believe I used to SSH into my server to restart an app when I can now just run `cap unicorn_APPNAME:restart`

As said in the post, Capistrano is a good option but we found we much preferred deliver, it was easier to setup and meant we didn't need ruby dependencies on node.js apps. We also used to SSH into our servers and do everything manually. Crazy times.

I generally use a node script (sometimes a CLI script like [1]) with the ssh2 module [2] for most deployment tasks.

[1] https://gist.github.com/4281277 [2] https://github.com/mscdex/ssh2

Post reply on HN