Angular 2 in the MEAN Stack – A Project Template

I recently became aware of the beauty of developing with the MEAN stack. It started with my desire to brush up on Angular 2 and using the Angular CLI. I ended up with a TODO application that runs on Node using MongoDB, Express.js, and Angular 2 (from a foundation found here:

I am also a fan of LESS. It makes writing modular CSS a breeze. I am also not yet sold on the Styled Component approach Angular is now pushing. I do believe Component-based UI architectures make writing modular CSS quite simple. I just don’t think styles should be located across the application when, with an optimally modular UI, the CSS used can be quite minimal. Beyond that, an application should have a look and feel that gives the user at least the illusion of cohesiveness. Easily done when styles are in one place.

Using Feature Modules with Angular 2 makes a lot of sense. Each feature can be created in isolation while still being integrated with the rest of the application. The module structure of the TODO application is shown in Figure 1. This structure allows the application to be extended and makes features easy to find for updates and bug fixes. The approach also provides a more SOLID application.

Figure 1: Module structure

With the focus on Angular 2, the server-side code is quite minimal and I don’t have much to say about it. Figure 2 depicts the main ideas.

Figure 2: Server-side

I almost forgot to mention that this app is on GitHub: Let me know your thoughts!

I look forward to continuing my work with the MEAN stack and sharing what I find that works – and what doesn’t work so well. Look for more in the future.


4 thoughts on “Angular 2 in the MEAN Stack – A Project Template

  1. Hi Caleb, Nice post thanks!
    Once the TODO object model and API get a bit more complicated. How would you solve the ‘have to write the object model twice, once for API node server js and once for ng2 services’. I dread the copy paste replication when the API contract could be shared with a common js ‘TODO object’ file – maybe?

    Liked by 1 person

    • Thank you Rob, I appreciate your good word and excellent question!

      In the scenario that you described, isolating the interface would indeed be critical if the API and DB models have a 1:1 relationship. In the 1:1 scenario, a common interface between them could be leveraged if the used schema types map directly to the types TypeScript recognizes. Considering the possibilities MongoDB has to offer, this approach would offer limitations to the data model.

      If the limitations are at the type level, a generic mapping layer could be introduced at build time that would transform the Data Model to TypeScript POCO’s for ng2 services to consume – coming from the Microsoft world myself, this smells a lot like EntityFramework. This could also solve some other potential problems due to the sort of “metadata” that could be brought along (e.g. subdocuments, setters/getters, middleware, constraints, etc). I see this as a matter of mixing the system layers, which should be avoided in a production system.

      I would probably introduce Shared ViewModels between the API and ng2 services. There could potentially be another layer of abstraction between the Data Model and the API. The result would be similar to the image below – please let me know if it decides not to display for you:

      Data, API, NG2 Initial Separation

      Thank you again for your question and comment – Caleb


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s