Lesson 1.1: The Background

Over the past years, I have worked in the software industry. As I’ve been learning new technologies and techniques, I’ve always used side projects to become familiar with new technologies. In the past, I followed the Build a C#/WPF RPG by Scott Lilly to learn some new techniques since I enjoy games and RPGs. That sample is based on rich client technologies (first WinForms and then WPF), but I’ve been doing a lot of investigations into web clients, single page applications (SPA), and Azure-based microservices. So I thought it would be interesting to port the Simple RPG game to web technologies. That way people can extend their knowledge from WPF to web technologies by following along with a sample that they already know and enjoy.

We’re going to start by learning a little about the tools and infrastructure needed to build single page applications (SPA) and web services on the Microsoft platform. Blazor is a new ASP.NET framework for building SPA web apps using C# and .NET Core. Prior to Blazor, these types of applications were built on JavaScript-based frameworks, like ReactJS, Angular, Vue, etc. We’re going to build our service backend on Azure Functions because they are an easy, cost-effective way of building Serverless components in Aure.

These lessons are built on Microsoft technology — it’s what I’m familiar with and the skillset I’m looking to expand for my day job as well. I hope you will follow along and learn some fun and useful things.

Micro-architecture

I’m sure you’ve heard a lot about microservices in the last few years. It’s the concept of breaking down a monolithic, large-scale application into smaller services that can be built, deployed, managed, and scaled independently. This allows us to more quickly respond to customer requests and roll out new features and improvements. Also if we require larger scale in a particular service, we can create additional instances of just that service without scaling up the whole application’s infrastructure. These are all great concepts, elaborated upon by by Martin Fowler.

The most concise definition I’ve seen is here:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

James Lewis and Martin Fowler (2014)

This article is required reading for more details on the microservices architectural style.

More recently micro frontends have emerged as an architectural concept as well — breaking down a large web application UI into smaller independent frontends with their own coding, build, and release cadence and pipeline. This is another interesting trend in trying to break down large monolithic components into smaller chunks that are easier to manage. If you wish to learn more about micro frontends, please look at this article.

Serverless Compute

Another recent trend in cloud technologies is Serverless compute. This means that instead of reserving and paying for processing power in cloud services (like Azure or AWS), we only pay for and use computational power when it is needed — usually in response to an event, like an http request (though they support many other event types).

Serverless compute means that virtual machines are not just sitting idle waiting to run our application or service. When a request is made, the Azure cloud infrastructure loads up instances of our Azure Function and runs the code. As a developer, we don’t have to know or care about how that is done… theoretically. 🙂

For early start-ups, small applications, and samples/tutorials this type of consumption-based system is very useful. We can get great savings by using Serverless infrastructure. Anyway this was a long winded reasoning for why I picked building the service backend in Azure Functions.

In conclusion, I wanted to expose you to some design and architectural concepts that are driving this tutorial series. It may be a lot for new developers (and maybe not enough for experienced ones). But if you don’t understand the concepts now, you won’t need a deep understanding of all of them to walk through the lessons. And later on, when you start asking why some design choices were made, you can come back to this article as a refresher.