Large Angular Project Design Guide

An example of a large angular project folder and file structure
An example of a large angular project folder and file structure

Are you about to start developing a large angular project? Have you mastered the basics but not sure how to structure a huge app with more than just a few screens? Then you need to read the Large Angular Project Design Guide.  Most design guides, or examples to get you started, are for really small projects that put all the views and controllers in separate files. But when building large applications it is best to organize files by feature.  When you open our app/account folder for example you know all these files are dealing with a users account. Much easier then making a change to the accounts view file then having to open a different folder containing controllers, and then having to guess what the controller is called. Same for searching for the account css file, or even worse combing one big css file for its classes. Following this guide and implementing your own standards can make developing with a team so much easier.

The Large Angular Project Design Guide

Folders and FilesWhen creating folders and files it is good practice to keep them all in lower case. Windows is not case sensitive but Linux is.  To keep things simple snake_case is a good option.  To help make a file’s function more clear, if not obvious, we added an extra file type dot extension. Such as file_name.view.html.  The .view lets us know this is a complete view or screen to be seen by a user and not a partial included elsewhere in another view. Another important one we used is .module so it can easily be found among all other javascript controllers and services.  Few more possible extensions are .controller, .service, .factory, and .fragment. But since they should be obvious based on the file structure we have opted not to make the file names longer and redundant.

When creating a new controller, service, or directive it is best to place that code in its own file.  That way if it needs to be changed or used elsewhere it can easily be found.  For example, if there are two controllers using one service. And the service is defined in one of the controllers, say controller ‘A’.  And now controller ‘B’ or another added controller needs a change in the service. How can another developer quickly locate it? Our solution was to put all services and directives in their own folder. And all the controllers and views are placed in their own folders based on feature.

ControllersEach View has a controller, most controllers are responsible for one view but can have more if the views are similar and share functionality.  As seen under consent_management folder.  Controllers should be as slim as possible and only have functions that support the view. A controller that tries to do too much, like fetch data, is over exerting itself.  Making the code longer and harder  to manage and not reusable.  Any code that is not directly manipulating the view or could be useful to other controllers should be made into a service.

ServicesServices are meant to do the heavy lifting for controllers. And they should have very specific roles, such as handling data, validation, or storing sessions. Notice that these functionalities are needed by multiple controllers, so it makes sense to separate them from a single controller for code reuse and cross controller communication.  While angular has Services and Factories, which are both singletons and essentially can accomplish the same thing with subtle differences, you will mainly use Services.  Factories allow you to use the new keyword to create objects. So only use Factory if you need to create a bunch of objects life a factory in real life does, else a service will suffice.

DirectivesDirectives are where angular gets a lot of its power. Since directives can be used by multiple views we separate them into their own folder. A directive enables you to teach the browser new elements or controls. You can condense a lot of html and functionality into one html tag that can be used anywhere throughout the application.  A directive has unique scope options, an html file as a template, its own controller, and even a link function that gets called once when the directive is instantiated.  If you have a view that requires a unique UI  control, especially if it can be useful elsewhere, consider making it a directive.

Angular Hierarchy Explanation

AppThe app folder is where all of our development takes place. It contains a separate folder for each feature of the application and there are folders for Directives and Services. Each feature folder contains the html, css, and javascript controller files associated with it.  It also contains our app module and any other configuration files.

Content – The content folder is for any static content we add to the application. This includes images, global css, bootsrap, fonts, themes, and language files for internationalization(i18n). Language files could be delivered by the server as a web service.

ScriptsThe scripts folder is where we store all of the third party libraries. This includes the source version for development and assisted debugging, as well as the production ready minified versions. Since these are third part libraries no custom coding should be done or added here. In other words these files should never be touched!

SDKThe software development kit folder will be used for features that can be reused for other applications. Few examples are log in and registration. If another application is to be made that uses Web Services or login credentials then instead of re-coding log/registration forms and services again they can be taken from this SDK.


Using jQuery

Angular is built using a subset of JQuery, it is not required as angular already has included in its core what it needs. However if you Include jQuery before Angular it will use the full jQuery Library and get some extended functionality. It may be beneficial to know jQuery, however it can also cause confusion when making an Angular App. Meaning you may be tempted to use jQuery directly in code but this is not the “Angular” way. A true Angular app has everything it needs to accomplish what jQuery already does. So it is best to avoid jQuery in your code and find/learn the way it can be done in Angular. Which would be to use directives, jQuery if needed should be wrapped in a directive, but that is another topic. Extra Reading and Documentation on jQuery can be found at

You may also like...

5 Responses

  1. Cuc Cherrier says:

    This guide really helped give us ideas to structure our large angular application for production use. Thanks!

  2. Awilda Dubej says:

    I barrowed some ideas, thanks for the share.

  3. Mario Newmeyer says:

    It is amazing how fast projects can grow bigger and get out of hand

  4. Daryl Narayanan says:

    Thanks for sharing your experience.

  5. SannyQuava says:

    Make a more new posts please 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *