Aspects of Building a Node.js Application
engineering.gosquared.com
Aspects of Building a Node.js Application
1–10 of 22 posts
Re: Aspects of Building a Node.js Application
#2Can'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`
Re: Aspects of Building a Node.js Application
#3First 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 /users. Whenever you need to go back to a clean database (which is, often) you can run this script. And of course, every time you want to test all the APIs.
2. Automate everything in scripts. Script your compile, test and deploy steps. Script emailing. Script your database backups, tar your image folders.
3. Refactor every time you get a chance. It is like having a bath. You feel like working on your app, code feels fresh.
4. Optionally, try coffeescript. The language often promotes good, declarative programming. Once you get used to the shorthand, you won't go back. Don't discard it after spending a couple of days on it; it might take a little longer depending on your experience level. Another minor benefit, since there is a compile step some typos are picked up by the compiler.
5. One of the big benefits of Node is that you could move things like rendering from server to the client (or the other way round) relatively easily. But still it is cleaner to just have REST services on the server and handle rendering on the client (with say, Backbone).
Re: Aspects of Building a Node.js Application
#4Can'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.
Re: Aspects of Building a Node.js Application
#5First 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 of the code is imperative and easy to follow. I also felt uneasy about what code was actually executing at the other end of the transpiler.
Re: Aspects of Building a Node.js Application
#6Can'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.
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?
Re: Aspects of Building a Node.js Application
#7Why mention newrelic, doesn't even integrate into nodejs.
Re: Aspects of Building a Node.js Application
#8In 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.
Re: Aspects of Building a Node.js Application
#9Can'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.
We use a slightly modified version of deploy from visionmedia (https://github.com/visionmedia/deploy). Shell script, and works very well for us.
Of course, when doing releases that affect the database schema, we still have to login to the servers.
Re: Aspects of Building a Node.js Application
#10Earlier 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?
Over time, you will add features to that script and it'll grow and eventually become 'a more advanced tool'. Everything starts from somewhere.