There has been quite a lot written lately about the MEAN stack which is MongoDB, Express, Angular and Node, but I am going to describe the architecture I have used to create ObsPlanner.com. It comprises of both the MEAN stack and ASP.Net, Web.API, SQL Server as well as a number of third party components.
The ObsPlanner.com website is a web application aimed at the more technical amateur astronomer market. It allows the user to plan in advance what astronomical objects they wish to observe by taking into account obstructions such as buildings and then optimises the plan around the times the user is at the telescope. Plans can then be downloaded and loaded into telescope controlling software which will automate the plan. Future releases will also include a mobile/offline mode and maybe even control the scope itself via Bluetooth. But that is dependent on much more research.
This is a brief overview of the architecture I chose.
ASP.Net MVC Razor Views
By using Razor views, I could quickly create all the views for the front end based on layouts. Also with Razor and MVC I had a security model that could validate the user and redirect them if they were not authenticated or authorized to go to that view.
Each view has an angular controller to manage its data binding and any service calls to either the Node or Web.API layers. By using angular it was possible to create a neatly structured code base as well as giving the end user a fast UI experience.
ASP.Net MVC & Web.API
With ASP.Net MVC and Web.API I was able to utilize the forms based security model as well interface with the Entity Framework layer that manages all the relational data from SQL Server. The services also use token based authentication which was very easy to set up using MVC Filters and attributes.
Node js & Express
Entity Framework (EF)
I used a code first approach to create the entities that are relational in nature so the SQL Server database could be dropped and re-generated as the model changed. I also used the repository and Unit of Work patterns which lead to a faster integration with the MVC and Web.API controllers.
This is the data store for more relational entities such as the user and location as well as account stores. I was happier choosing this instead of having all data in Mongo as I was familiar with the security side of things and I wanted to use entity framework, repository and unit of work patterns.
I chose this as part of the back end for a fast read only data store that easily and quickly integrates with Node and Express. All the astronomical data is stored in this database and is made up of multiple collections for thousands of celestial objects. By using a data store that manages json natively it was very easy to retrieve astronomical data and pass it to the front end in the same format that the angular controllers could manage.
As ObsPlanner is a multi tiered application, I wanted an easily integrated payment system without having to worry about being compliant with the banking systems. Stripe has an easy to use API layer that can be used both as part of the front end layer as well as the middle tier layer written in C#. When a user does opt to move on to the Pro level, none of the card details go through the ObsPlanner system and only to Stripe systems.
There are a number of internal subsystems which need to manage the sending of messages to registered users, this is done by SendGrid which has a simple API and allows access to message statistics such as errors, opening rate etc.
All this is running on one instance of Windows Server 2008 R2, not ideal I know but it is all I can afford just now.
So that is a quick run down of the architecture of ObsPlanner.com as of February 2016. It may change in the coming months as more users register and I detect any pain points.