Category : Web Applications (10)

Building Distributed Applications with Dapr

Today, the development of distributed systems has become an increasingly essential need. However, due to the complexity of these systems, developing and managing such applications presents challenges for us developers. Matters like communication between services and state management are not easy tasks. This is where Dapr (Distributed Application Runtime) comes into play, assisting us developers.

Dapr is a platform designed to make developing distributed applications easier and faster. With its provided features, we can perform tasks like communication between services, state management, and event publishing/listening more effortlessly. It even simplifies actor programming.

Actor Model - Microsoft Orleans

Object-oriented programming (OOP) is based on four fundamental concepts. These are: encapsulation, abstraction, inheritance, and polymorphism. Of these, encapsulation is the most important. It means that the internal data of an object can't be accessed from outside.

Imagine a product object with a stock property. To decrease the stock, we will need a DecreaseStock method. The stock cannot be manipulated from outside, and will be decreased using the DecreaseStock method, which has business rules. But what happens if multiple threads enter the DecreaseStock method at the same time? No one knows how much stock will be decreased.

The reason for this is the shared memory problem, which is the biggest disadvantage of OOP. Of course, there are many ways and approaches to overcome this. The classic method is the locking mechanism, but since it is a very costly operation, it is necessary to avoid it. The Actor model not only saves us from the locking cost, but also allows us to develop in a distributed environment as if it were not distributed. But how does it do this?

Domain Driven Design - Tactical Patterns

DDD is an approach for software that have high complexity. This approach eliminates the complexities within the process of developing software. DDD is broken down into two categories, strategical and tactical. Strategic pattern is the main component of DDD. But we will not be talking about strategic pattern in this post. Tactical Pattern deals with architecture. It is about how classes, methods and dependencies should be. So we can call it clean architecture. Lets start then.

Test Driven Development

TDD Cycle

TDD tells that a test case should be written first, then the code should be written.

TDD is a cyclical process and includes three stages: RED, GREEN, REAFTOR. In the RED stage, a test case is written and executed. The test case fails. In the GREEN stage, first code is written for the test case to pass. The code doesn't need to be clean. The main goal is to write the simplest code for the test case to pass. The test case is run again. If the test is successful, the REFACTOR stage is started. At this stage, if the code can be refactored, it is done. The test case is run again. If the test case fails, the code is refactored. This cycle is continued until the code becomes desired.

What is Modular Monolith?

Traditional Monolith

Firstly, let's talk about Traditional Monolith approach. This approach focuses on layers. It includes three layers, UI, Business and Data. All features in a project are vertically separated into these layers. Among those three layers, the business layer is the one that contains business logics of all features. Each feature knows business logic of other features, which is a fact we call tightly coupled.

ASP.NET Core Feature Management

Feature Management provides feature management in .NET Core applications. It allows the management and querying of the active / passive status of the features of the application. For example, you can ensure that a feature you have just developed is active in a certain date range. To give another example, you can ensure that a feature you have developed is active with a certain percentage. Like A/B testing.

Event Sourcing with ASP.NET Core - 02 Messaging

1. Introduction

Since this article is second part of the article below, I recommend you to read the following article before starting. We will continue with the sample project in the article below.

In the previous article, we made the example of Kanban Board. By creating a RESTful API, we wrote the create, assign, move and complete endpoints. We recorded the requests coming to these endpoints as an event in the Event Store. So we focused on the store part of the Event Store. In this article, we will focus on with the messaging part.

We will include the following endpoint in our RESTful API endpoints.

[GET] api/tasks/{id}

Event Sourcing with ASP.NET Core - 01 Store

1. Introduction

I recommend you to read the article below before applying this example tutorial.

In the article I have mentioned above, I had formed a sentence as follows.

In this article, we will deal with the store section of the Event Store. In other words, we will deal with the database feature where we can save events. In the next article, we will deal with the messaging part.

As an sample application, I chose the classic Kanban Board sample.

Our RESTful API endpoints will be as follows.

[POST] api/tasks/{id}/create
[PATCH] api/tasks/{id}/assign
[PATCH] api/tasks/{id}/move
[PATCH] api/tasks/{id}/complete

Couchbase GeoSearch with ASP.NET Core

The subject of this article will be about how to do "GeoSearch" by using Couchbase.

1. Installing the Couchbase

For this purpose, we create Couchbase cluster with the docker by running the command below.

    docker run -d --name couchbase -p 8091-8094:8091-8094 -p 11210:11210 couchbase

When Couchbase is up, it will start broadcasting at the address below.

http://localhost:8091/

We create the cluster by clicking the "Setup New Cluster" button. We define the password as "123456".

You can make adjustment according to your current memory status. You can turn off "Analytics". We complete the cluster installation by clicking the "Save & Finish" button.

What is Event Sourcing?

Previously, our services would be as follows.

This service consisted of hundreds of lines of code. To get rid of this confusion, we split our services into two parts as "Command" and "Query" with CQRS. We performed our CRUD operations with "Command" services and our query operations with "Query" services. Two separate services appeared as follows.