Skip to main content

Let's take a look at our project

In this workshop we are going to turn the CloudNativeWorkshop solution to a cloud native project. We will be using an extremely simplified version of by course business, Dometrain, as an example. Let's take a closer look to what's inside this solution.

The Dometrain.Monolith.Api​

The Dometrain.Monolith.Api is the brain of the Dometrain system. It is able of doing the following:

  • Students can create accounts and login via a JWT token
  • Students can browse available courses and search by name
  • Students can add courses to their cart
  • The API Admin can enroll students to courses after successful payment
  • The API Admin can manage students or courses

The API is retrieving and storing its data using a single Postgres database.

You can run the project including the database by running docker compose up on the root directory.

You can see all the API endpoints by accessing /swagger.

You can also call the API by using the Insomnia Collection that can be found in the Solution Items.

The plan​

The plan for this workshop is to turn this application into a cloud native app that uses the best tool for the right job, for the functionality it needs.

I would like to clarify that there isn't anything fundamentally wrong with this app. We will just use it as the foundation to teach cloud native concepts.

The great thing about this API is that it is technically distributed already.

Why is this API distributed?​

The base API we will be working on is a RESTful API. REST is an architectural style that ensured that our API can scale horizontally. That means that we can run many versions of the same API "in parallel" and we don't have to worry about in memory caches (because we don't have any) or sessions. We can simply use a reverse proxy or an API Gateway and run as many versions of it as we want and our load balancer will do all the hard work for us, routing the incoming requests at instances that can handle them.

There are however a few problems:

  • If we choose to use an in-memory cache, then our plan falls apart because each instance will have its own cache, which will lead to inconsistent results
  • We are using a single database for every type of data, tightly coupling domains that don't necessarily need to talk to each other
  • We can gain better performance and provide a better customer experience by making more appropriate data storage and data transfer choices

In this workshop we will solve all of these problems.

Let's start with a very exciting part. Introducing .NET Aspire!