jonhobbs jonhobbs - 2 months ago 18
AngularJS Question

Structuring a NodeJS and Angular JS app

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

The first thing I'm trying to get my head round 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/Angular app here....

... which suggests the following directory structure

app.js --> app config
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 app module
controllers.js --> application controllers
directives.js --> custom angular directives
filters.js --> custom angular filters
services.js --> custom angular services
lib/ --> angular and 3rd party JavaScript libraries
angular/
angular.js --> the latest angular js
angular.min.js --> the latest minified angular js
angular-*.js --> angular 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 app
layout.jade --> doctype, title, head boilerplate
partials/ --> angular 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 Angular from a CDN?

  3. Given that the server will only need to deliver one template (the main app 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 Angular Seed app 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.

As you can tell, I'm new to this. Any help would really be appreciated.

Answer

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.