Architecting an angular CLI project

Today I’m going to start writing about how to create an angular CLI project taking into consideration the best practices adopted by the community and highlighted at the Angular Style Guide page.

This is the first part of a series. The only thing I’m going to assume is that you have node/npm and VSCode or any other text editor installed (I’ll be using VSCode for my examples). It’s going to be a pretty thorough tutorial (step-by-step). I’m also going to expand a little bit to cover some more ground.

The libraries I might mention in this series are based on my personal choice/preference. Feel free to use the one you prefer, or even create your own!

The goal is simple, documentation for future usage and share the knowledge with the community. I’ll be starting from scratch and going all the way up to deployment to Azure WebApps.

Without further ado, let’s start!

First things first, let install angular CLI and create the starter project:

Run the command npm install -g @angular/cliand then just check whether everything’s ok with: ng --version. This is the output I get as of the time of this writing:

Screen Shot 2017-09-06 at 16.05.05

Then run ng new name_of_your_app. It’ll take some time, wait and once it’s done open that folder with your editor, it should look like this:

Screen Shot 2017-09-06 at 16.12.31

Now let’s focus on the architecture adopted. The first thing I want is a folder to store the core of my app, then I’d like one for my custom components, one for pipes, another for directives and so on… The final structure will be like this:

Screen Shot 2017-09-06 at 17.07.50

We’ll discuss every folder separately, but for now it suffices to say this is the structure I chose according to my needs/feelings and is in no way “the right way” or “the best way” of approaching this subject. Your needs/feelings might lead you toward a different structure. Obviously I also tried to apply the angular guidelines as I said in the beginning of the article.

One of the first things we can do now is add a property to our environment files. These files are used to provide values according to the environment our app is running on. For example, I’m going to add a property namedbaseUrland it’ll have different values for production (let’s say I have a backend with the URL: and localhost (http://vm/my-proj/api). With that whenever we access environment.baseUrlit’ll have different values if we’re running locally or on a production server. This is what the files will look like:

export const environment = {
export const environment = {

If you’d like you could also open the .angular-cli.json file and edit the prefix property. This property will be used to prefix every component you create using the ng g component command (more on that command later).

  • app
    • components (we’ll use it to store all the non-screen components we create)
      • common (general, reusable components we use inside the screens)
      • layouts (the layouts components of our app like full layouts, footer and navigation bars)
    • directives (official docs)
    • pipes (official docs)
    • views (all the screens/partial screens of our app)
  • assets (images/css)
  • core
    • abstractions (all the base classes used by our app)
    • models (the models used by the app)
    • enums (pretty self explanatory 🙂 )
    • security (classes/items related to the security of the app)
    • services (official docs)
    • stores (layer of abstraction to represent our storing logic/communication with the backend)
    • utils (some utility classes used throughout the app)

With the basic structure done, now we can start coding!

In the next article we’ll start with the core folder.


Here’s the GitHub repository with the working project:

No Comments

You can leave the first : )

Leave a Reply

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