This week, my team and I have embarked on a new large scale application. It’s predominately your typical web multi-tier web application with business logic, security, CRUD, and what not.
However, it’s also going to be an Angular Single Page App (SPA). Thinking about the structure of this application, in terms functional blocks and project/solution layout is pivotal in the design and engineering process.
In my mind the definition of a large scale application is one that has a large, all-encompassing scope and/or involves a large team of developers. Without getting into too many details, this particular application will be used for commissions, payroll, and many other functions. While all of the functions seem related, they really aren’t related in terms their intended implementation or user presentation. This becomes an opportunity in the design process.
We could just go down the path of creating one big giant monolithic SPA, but this has many disadvantages:
- Did I already say monolithic? We want things loosely coupled. So, one big SPA is bad in this regard.
- Individuals on the team start stepping on each other
- Without being loosely coupled, a simple, seemingly unrelated, change in one part of the application breaks many things.
- Poor separation of concerns
- Maintenance, as such, with a big monolithic application becomes a nightmare. We’ve seen this before.
The solution in my mind was not to view the “application” as a single entity, but as many applications. Think of this as many “mini” SPAs.
ASP.NET MVC / Visual Studio provide very easy ways to create “areas” within a web application. In effect, each area is a completely self-contained web application. However, since all of the areas aren’t truly independent, they are still aware of their root/parent and this creates a great way to share common resources across multiple areas.
In the Angular (or JavaScript) sense, we can put all of our mini-SPA related scripts within the area and then create bundles for the specific areas. But that same area can still reference shared/common modules from the parent/root scripts. It comes down to module separation which is synonymous to namespaces. This creates an easy way for us to share directives, services, animations, and other common functionality across all of the areas. All of the areas can be tied together through common controllers (naming conventions) that handle navigation for shared layout elements. Think of a navigation, menu bar, other HTML elements that simply use the ‘controllerAs’ syntax. For any given area, that controller can be defined to handle the functions relative to the area in which the page is viewed.
At any rate, this is a primer for my next post where I’ll dive a bit more into the specifics of the layout, structure, and how the shared components can work together across multiple/mini SPAs. I’ve already learned some nice lessons in defining the base architecture.