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: https://scotch.io/tutorials/mean-app-with-angular-2-and-the-angular-cli).
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.
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.
I almost forgot to mention that this app is on GitHub: https://github.com/calebmagenic/ng2-mean. 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.
UPDATE: After working with later versions of Angular, I found it to be an effective front-end framework that can solve enterprise-level concerns. I enjoy working with TypeScript and creating stunning multi-faceted projects with the help of Nx Workspaces. To make it easier to get up to speed with the MEAN stack, Manning Publications released a new book called Getting Mean with Mongo, Express, Angular, and Node (2nd Ed.) written by two smashing authors and developers in the field Simon Holmes and Clive Harper. After leveraging this book, I am able to create substantial solutions using the MEAN stack. I highly recommend it even if you are just trying it out. It has a ton of immediately actionable information packed into it.
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?
Rob
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:
Thank you again for your question and comment – Caleb
After posting my long-winded response I realize you were likely not referring to the data model but rather a common TODO entity between the API and NG2. Right on.