Rob Kraft

C# .Net applications work well on Amazon AWS and can easily work with DynamoDB; but the way you write code for SQL Server (a relational database) is a lot different from the way you need to write it for DynamoDB (a document storage service). You should plan to completely redesign and rewrite the .Net code to work with the DynamoDB store. If you do not want to do that, I recommend Amazon RDS for SQL Server if your web app is not currently on AWS and you plan to move it there. If your MVC web app is already on AWS, then again, you CAN use DynamoDB instead of SQL Server but you will need to rewrite all your code that touches the database, and you will need to go through a tedious process of figuring out how to map your SQL Server tables into DynamoDB documents - it is likely not a simple table to table mapping (unless your current SQL Server database tables have no relationships between any of the other tables).

I first recommend that you choose Angular over AngularJS if you are starting something new. AngularJs is no longer getting enhancements, but perhaps you meant Angular. Regarding microservices, I recommend considering microservices when you have different development teams for each service that may want to use different programming languages and backend data stores. If it is all the same team, same code language, and same data store I would not use microservices. I might use a message queue, in which case RabbitMQ is a good one. But you may also be able to simply write your own in which you write a record in a table in MSSQL and one of your services reads the record from the table and processes it. The most challenging part of doing it yourself is writing a service that does a good job of reading the queue without reading the same message multiple times or missing a message; and that is where RabbitMQ can help.

I think your choice of technologies are fine, but it you are starting new development I think your choice of architecture is most important. You can implement the desired architecture with many different technologies. Separating the layers of the application is important to allow each technology to be replaced or evolve independently. For example, I would write the code in a way that I could replace PostgreSQL with a different DBMS fairly easily in case a better alternative came along. The same goes for the React front end. If you have a good REST API you could replace the React front any with any framework, you could easily allow different locations to use Angular, Vue, or other front end technologies as long as the REST API is not designed to specifically target the React front end. I think the architecture of the code behind the REST layer, that would run in Express (the tool/language you are considering) is the decision that you will be stuck with for the longest time and that all other aspects of the application need to work around; so you want to get that architecture right. I think you should consider CQRS and Event Sourcing. https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing https://dzone.com/articles/cqrs-and-event-sourcing-intro-for-developers