Web Uygulamaları, Bulut Uygulamaları
In previous article, we prepared our contract and wrote our test codes. In this article, we will access the contract from the UI and call the functions defined in the contract. If you haven’t read the previous article, you can go to the link below.
This series of articles will be 3 parts. We will develop a blockchain app in this series of article. It will be like Hand-on Labs. So we prefer way of learning by developing an application. The subject of this article is to create a smart contract.
Smart Contract is code parts that also store data in it. Programming language that used to write smart contract is Solidity. It isn’t very advanced but it is enough to write.
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.
This article will be about how to develop the messaging system with the serverless approach. We will use AWS as a cloud provider. We will prefer .NET Core as the language.
In this part, I will set up the scenario and give preliminary information about what will be the result.
Our RESTful API endpoints will be as follows.
[POST] api/comments
[GET] api/comments
We will use the AWS services below.
