Using Yeoman with Grunt (as a build system and to run a server with livereload) was a refreshing developer experience when I first started. But Yeoman is limited to the client side, and so getting the full stack to work was not immediately clear to me. Here's my best attempt to capture everything I learned from building the app, from beginning to end. I'd be a fool not to take suggestions - please let me know your thoughts. (You can comment at:


Creating a Yeoman App Inside Express

express #so I created a new express app
cd public
yo angular --minsafe #and here's a Yeoman app in the public dir

So now, from my root directory, I have my main app.js file that runs the Node server and is initially set up with some routes pointing to some boilerplate views. And then I have the public/app directory in which my Yeoman development code lies, and if I run grunt build, then public/dist will be where my Yeoman production code lies.

Since Yeoman spits out a single page AngularJS app, all we really need is for the index.html to be served to the user. So I removed all of the routing and views that Express gave me, and set up app.js to point to public/app/index.html in development and then public/dist/index.html file in production (to take advantage of Grunt's build system):

app.configure('development', function(){
  app.use(express.static(path.join(__dirname, 'public/app')));

app.configure('production', function(){
  app.use(express.static(path.join(__dirname, 'public/dist')));

I later added back routing to support authentication and some RESTful type calls.

Running Express Server and Grunt Server Together

I really enjoy doing grunt server, but when your Yeoman app requires an underlying server, grunt server can't do everything.

I could do node app.js to run the server (which runs on port 3000 by default) and then do cd public; grunt server (which somehow detects that it should also run on port 3000 and not the Yeoman-configured default 9000). This seems to work a little bit, but is for some reason kinda unreliable - server calls seem to fail over time and I'm not sure why.

I modified the Gruntfile.js that Yeoman generates and, instead of running grunt server, I now run a new target called css-server to compile and minify Compass CSS and get a pseudo-livereload feel (I'm not using CoffeeScript, so I'm not worrying about that):

grunt.registerTask('server', [

grunt.registerTask('css-server', [

There were a few other mods to make this work - I had to create the cssmin:express app target (because I didn't want to run grunt build every time):

cssmin: {
  dist: {
    files: {
      '<%= yeoman.dist %>/styles/main.css': [
  expressapp: {
    files: {
      '<%= %>/styles/main.css': [

and I had to change the watch:Compass task to trigger that cssmin:express app target whenever a Compass file was changed:

compass: {
  files: ['<%= %>/styles/{,*/}*.{scss,sass}'],
  tasks: ['compass', 'cssmin:expressapp']

You can view source at:

Doing Authentication in Angular

Note: there are better articles out there for this - I pretty much just followed and

I decided to use Passport and Facebook as the only means to log in. So I set up the app as I normally would (see routes: and the Passport config:, using MongoDb with Mongoose as the back end.

Then, perhaps not the best, I wrote an Angular service (yo angular:service Auth) to make a GET request to /user, which returns a JSON object of the user (if a user is logged in) or a basically empty JSON object (if the user is not logged in). Every time a new Angular controller is run (i.e. any time ng-view does some kind of routing), Auth.isLoggedIn() gets run and redirects if necessary - if the user is not logged in, they should always end up back on the index page, and if they are logged in, they should be redirected to the main user page.

This logic could have arguably been contained in the $routeProvider config, which can run every time a route changes.

Here's the service: with a simple demonstration of $q for promises in Angular.

Then I wrote a bunch of code and finally got to the point where I could deploy.

Deploying to EC2, Nginx, and A Records

This might be better represented in bullet points - I didn't have an AMI that I knew would really fit (since I wanted nginx with Node), so I started from scratch:

Now to download and run the code:

git clone git://
cd am-i-down
npm install
cd public
npm install, because the Yeoman app had its own large set of NPM dependencies
bower install
grunt build, to populate public/dist
cd ../; npm install -g forever; forever start app.js, to start the Express server (and to do so "forever" -

When i go to my EC2 instance's public IP address, it only works if I connect to port 3000. For this, I'll modify the Nginx config to do a "proxyPass" from requests on port 80 (normal HTTP port) to 3000 (my Express app). I basically followed this:

I added:

upstream amidown {

then changed location / rule to be this:

location / {
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Host $http_host;
  proxy_set_header X-NginX-Proxy true;

  proxy_pass http://amidown/; #http://localhost:3000;
  proxy_redirect off;

then restarted nginx by running:

sudo /etc/init.d/nginx restart

Then, I wanted to point my own subdomain,, to that EC2 instance. So I created an Elastic IP for the instance, then created an A Record that points my subdomain to that elastic IP address. This worked for me.

Thanks for reading!