77

I'm about to attempt my first AngularJS project, and it makes sense to use Node.js for the back end, even though it means learning both AngularJS and Node.js from scratch at the same time.

The first thing I'm trying to get my head around is a good file structure. So far my pure HTML/CSS template has the following directory structure...

_site/
Fonts/
Javascript/
SASS/
Stylesheets/
Index.html

( _site is a working directory for PSDs, etc.)

I found an example directory structure for a Node.js/AngularJS app here....

... which suggests the following directory structure.

app.js              --> Application configuration
package.json        --> For npm
public/             --> All of the files to be used in on the client side
  css/              --> CSS files
    app.css         --> Default stylesheet
  img/              --> Image files
  js/               --> JavaScript files
    app.js          --> Declare top-level application module
    controllers.js  --> Application controllers
    directives.js   --> Custom AngularJS directives
    filters.js      --> Custom AngularJS  filters
    services.js     --> Custom AngularJS services
    lib/            --> AngularJS  and third-party JavaScript libraries
      angular/
        angular.js            --> The latest AngularJS
        angular.min.js        --> The latest minified AngularJS
        angular-*.js          --> AngularJS add-on modules
        version.txt           --> Version number
routes/
  api.js            --> Route for serving JSON
  index.js          --> Route for serving HTML pages and partials
views/
  index.jade        --> Main page for the application
  layout.jade       --> Doctype, title, head boilerplate
  partials/         --> AngularJS view partials (partial jade templates)
    partial1.jade
    partial2.jade

So, this looks quite good to me (except for the fact that I wouldn't use Jade).

I still have the following questions...

  1. I want to keep all front-end and back-end files separate. This solution puts all the front-end files in the public/ directory which kind of makes sense because most need to be public, but does it make sense to put the SASS and _site folders here? I could just keep them there, but not upload them when I put them into production, but it seems wrong because they shouldn't be public. They also don't belong at root level with all the back-end stuff.

  2. Wouldn't it be better to load AngularJS from a CDN?

  3. Given that the server will only need to deliver one template (the main application template) and all other HTML will be constructed on the front-end wouldn't it make more sense to keep the index.html file static, delete the views folder and create a partials/ folder under public/ like the original AngularJS Seed application does?

I realize that this is all a matter of opinion, and I could technically put them wherever I want, but I'm hoping somebody more experienced than me could advise me of the pitfalls of various directory structures.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
jonhobbs
  • 26,684
  • 35
  • 115
  • 170
  • You may find this link useful [Angular Project Structure](http://stackoverflow.com/q/20802798/1959948) – Dalorzo May 26 '14 at 01:41

6 Answers6

36

Things are getting easier as time goes on. I've used Yeoman for the AngularJS front-end, and it makes life much easier: http://yeoman.io/

Option 1, MEAN.io

MEAN is an awesome acronym! I prefer the MEAN stack directory structure. Let's use convention people! Just use the directory structure from mean.io. MEAN is handy too because it throws in all the goodies like Grunt, Bower, etc.

Enter image description here

Option 2, Angular-seed + Express.js

I've searched GitHub for Node.js/AngularJS projects (probably not hard enough) and not seen anything really great for a starting directory structure. So I've merged the Node.js Express.js (running Express.js from the command line using neither EJS nor Jade/Pug) skeleton with the angular-seed project (clone it from GitHub). Then I moved a ton of stuff around. Here's what I came up with:

  • developer - stuff only the developer(s) will use. Does not need to be deployed.
    • config - karma configuration files and others.
    • scripts - developer scripts (build, test, and deploy)
    • test - e2e and unit tests.
  • logs
  • node_modules - this Stack Overflow answer recommended to put this in Git. However this may now be obsolete.
  • public - This comes almost straight from the angular-seed app folder.
    • css, img, js, lib, partials - pretty obvious and nice and short.
  • routes - Node.js routes.
  • server - server-side "shebang" Node.js programs, daemons, cron programs, whatever.
  • server.js - renamed from app.js just to make it more obvious this is server side.

Enter image description here

Community
  • 1
  • 1
Jess
  • 23,901
  • 21
  • 124
  • 145
  • 1
    This is where I like Rails. Convention is an excellent idea. – Jess Sep 24 '13 at 16:03
  • Let's make this as Wizard for Nodeclipse Node.js. Where are sources for this template? – Paul Verest Nov 19 '13 at 06:42
  • Hi @PaulVerest, I don't have any source per se. I took the angular-seed project and a basic express generated node.js project and merged them together. For express, see this page: http://expressjs.com/guide.html, search for **Using express(1) to generate an app**. For angular, I downloaded https://github.com/angular/angular-seed.git – Jess Nov 19 '13 at 13:58
  • I see, I hoped there was sources we could use as Template in Nodeclipse. We already have Wizard for Express, adding Angular will be still manual. – Paul Verest Nov 20 '13 at 08:45
  • Shoot, now I have another option. Use sails.js! Then there is always yeoman... :S – Jess Feb 01 '14 at 03:43
  • Any opinion on where to put interfaces? Like put them in same class, or maybe a top level /models/IModels.ts (then have a top level model interface, and an interface for all sub-model objects) or would you put the sub-model objects interfaces in the same file as the model? Like WidgetModel.activeWidgetCollection:IWidgetCollection .... then define IWidgetCollection inside the same model file or in the "root" one? – FlavorScape Jan 07 '16 at 18:48
  • I've never used TypeScript, but it seems to me that Interfaces (like in C#/Java) are typically in a different file from what I have seen. – Jess Jan 07 '16 at 19:43
  • @codePlusPlus sorry no, but the one I used for Angular with a non-node.js backend was quite good. `npm install -g generator-angular` – Jess Mar 21 '16 at 20:50
  • Can you link to the SO post saying node modules should be in git? Sounds crazy to me – Ben Taliadoros Oct 05 '16 at 23:51
  • 1
    @BenTaliadoros - you are right. Things must have changed over time and npm got better. I linked the SO question and edited my answer. Thank you. – Jess Oct 06 '16 at 12:25
20

1) It usually does make some sense to make saas/less files public as you may want to use client-side less->css conversion when debugging (less.js does that). Not sure what your _site contains however (btw you should use lowercase folder for your project, especially for the public stuff).

2) It is usually a good practice to load AngularJS from Google CDN when in production, using only a local version for development, you could have two separate layouts depending on your environment.

3) Even if client-side rendering is the way to go, you may keep server side layout/views rendering, you will probably need it at some point (admin access, email rendering, etc.). However It can be helpful to use the partials name from AngularJS in the public folder to help avoid confusion between server-side views & client-side partials.

You should clearly go for what seems the most logical thing to do at the current time, you will probably move things around as you get familiar with express.

You should check existing express framework to see how they structure their app. For instance, TowerJS has a pretty clean config folder, however they mix up server-side & client-side code which I personally do not like.

Check this comparaison of NodeJS MVC frameworks to see how others do stuff. However, I would clearly start with vanilla express code in order to be in full control & to understand how things work before over-committing on any of theses frameworks.

Olivier
  • 3,431
  • 5
  • 39
  • 56
  • 2
    #2 surprised me. Do you really recommend a CDN for prod? Why? – Jess Mar 22 '13 at 02:12
  • 12
    because a CDN hosted resource will be loaded way faster (geographic spread of hosts) & has great chances of already being cached by your browser (thus responding with instant 304 Not Modified) since there is a lot of other websites that already uses them. You should still build a single js file of your own code (excluding cdn-libs) – Olivier Mar 22 '13 at 14:53
  • Wow. It's great to learn. Good summary. Here's more info: http://stackoverflow.com/questions/2180391/why-should-i-use-googles-cdn-for-jquery/2180401#2180401 and http://stackoverflow.com/questions/547384/where-do-you-include-the-jquery-library-from-google-jsapi-cdn – Jess Mar 22 '13 at 15:18
  • How do you create "separate layouts depending on your environment"? Anyone know of a project that demonstrates this? Also is the main advantage of this to debug .js files in development but serve .min.js files in production? – rob May 16 '13 at 20:37
  • 2
    I question that CDN hosted resources are quicker. A production webapp will typically concatenate all vendor-files into one file. The client thereby only has to perform one http request to get all vendor js-files. Hosted JS-files require one http request per file - cached or not, they will be taking a hole lot more time than your one file. – Spock Jun 24 '14 at 17:09
5

As suggested it mostly comes down to personal preference and what works for the project you are working on at the time. Everyone you speak to you will have different ideas, and each project has it's own design - what works for one may not work for the other. I expect you'll try quite a few different structures and will soon find one that is the most comfortable - but this will still evolve over time.

I've found the Angular Seed structure to be the cleanest, but again that's personal preference (though, it helps that it's designed by the Angular team.)

You might also consider looking at Yeoman for generating project skeletons.

Yeoman is a robust and opinionated set of tools, libraries, and a workflow that can help developers quickly build beautiful, compelling web apps.

It's a great tool for bootstrapping and managing projects (similar to the way Rails does) and will create a directory structure and skeleton files for you to build upon. Brian Ford wrote an excellent post on using Yeoman with Angular.

I also suggest watching the Angular meetup recordings on their YouTube channel. I recently attended a meetup in Mountain View where these questions came up. Miško recommended Angular Seed and Yeoman (at least as a good starting point.)

To answer your individual questions:

  1. Any files that are compiled server-side should be kept outside of your public folder. I would suggest not keeping the likes of master PSDs, mockups, or any other files that are not meant for public consumption (either by browser or user) inside public folders.

  2. It is always good to serve static assets (JS, images, CSS) from a CDN if you expect a high amount of traffic. It's not so important for lesser visited sites, but still a good idea. I would start by serving the files locally for initial development. Leave the asset optimization for when you are nearing your live date. When this time does come you'll also want to get your caching set up right. Yeoman, for example, presents a good way of versioning your assets. This gives you the advantage of long lived caches but allowing you to push updates of the files to the clients.

  3. If you're index file doesn't require any server-side rendering, serve it statically. I like to keep my backend decoupled from the backend as much as possible with Angular apps. It helps maintain separation of concern; when developing the client files, you don't need to think about the backend at all (Angular is great for this.)

Really, you just need to play around; try different things out, read blog posts, get ideas from others, ask questions (as you have done here, and on the Angular Google+ community page), watch videos and, if you can, attend meetups - Meetups really are great for this.

Berry Phillips
  • 51
  • 2
2

I don't agree with all the previous posts. They are either pasted from another place or didn't have their own mind. From my experiences, it's better to flatten your client-side codes. I mean the code inside your client directory should be in your root directory.

Why do I suggest this way? Because if you want to change your full-stack JavaScript project to the one without backend, but only include the frontend, it's much easier. I mean most projects written with JavaScript are focused on the frontend.

It's better to put your backend code in a directory like "server" in the same folder level as like "css", "image"... The advantage of it is that when you need or don't need a backend, just add or delete the "server" directory, and it wouldn't affect the origin project structure.

Like this:

Enter image description here

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
胡亚雄
  • 2,161
  • 1
  • 19
  • 21
0

I was investigating the very same thing.

My initial thoughts were directed towards using Express Generator and Angular Seed.

Then I found a much nicer solution:

One of the most popular yeoman generators provides you with a structure to Node.js and AngularJS applications.

I believe in power of standardisation and new people joining the project will appreciate the unified structure.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Mars Robertson
  • 12,673
  • 11
  • 68
  • 89
  • As always when downvoting - please provide feedback - in my naive understanding - starter projects are here to enforce best practices in terms of code structure - what am I missing here? – Mars Robertson May 20 '16 at 07:13
0

See this skeleton

https://github.com/Giancarlo1974/SailsAngular

It's integrates Angular 4 + Bootstrap 4 for the client and Node Sails JS for the server

One of the strong points of this solution is: 1) Task Automation 2) Database Agnosticism

Janka
  • 1,908
  • 5
  • 20
  • 41