Web Uygulamaları, Bulut Uygulamaları
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.
In the previous post, we prepared the contract and wrote the test codes. In this post, we will make the contract interact with UI and call the functions defined in the contract. If you haven’t read the previous post, you can reach it from the following link.
This series of articles will consist of 3 parts. In these articles, we will develop a Dapp (decentralized application). It will be like Hands-on Labs. This article is about creating smart contracts.
Smart Contracts are code parts that run in a blockchain network and store data. So it is a structure that contains both codes and data. Solidity is a programming language that enables us to write contracts.
Instead of the form elements being displayed side by side, it allows the form element to be displayed with the user action.
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.
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}
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.
There is a technology called “Event Store” in the .NET world for Event Sourcing. This technology offers solutions for “Aggregate” and “Projection”. In other words, in addition to providing the store where we can record the events, it also provides the “Messaging” and “Projection” services, which are necessary for us to record in “Query” databases.
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
The subject of this article will be about how to do “GeoSearch” by using 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.
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.
With the serverless approach, the problem about the server that the software developer confronts with has disappeared. Now we write our code and call the provider to run it. We are not dealing with server configurations, scalings etc. And pay as you go. This is a great opportunity.
AWS’s Lambda, GCP’s Cloud Function, Azure’s Azure Function etc., these services provide us this service. But this time, different kind of problem appears. These services do not support all languages. Even if it supports the language we want, it may not support the version we want. For example, AWS Lambda does not support the upper versions of .NET Core 2.1 yet. This is a problem. Nobody can restrict us 🙂
The Cloud Run service that Google built on Knative completely solves this problem. We give Cloud Run a docker image and Cloud Run runs our serverless service from this image. So whether we develop in PHP or .NET Core, it doesn’t matter. There is no limit as long as we can make dockerize. This is awesome.
