Elasticsearch is a distributed, RESTful engine and a NoSQL database for fast searching. However, it has a significant difference than other databases, including NoSQL databases. When data is saved, Elasticsearch analyzes it (e.g., tokenization, stemming) and stores it in an inverted index, allowing for rapid full-text search.

In this article, I will demonstrate how to configure a Docker-Compose environment for an ASP.NET Core Web API and Elasticsearch.

Example Application

Our application will be a basic application. It will perform read, add, and remove operations on the product index.

Nest and Elastic.Clients.Elasticsearch are two main libraries to use Elasticsearch in Asp.Net Core applications. In our example, we will use Elastic.Clients.Elasticsearch library which is recommended by Elasticsearch.

appsettings.Production.json

  "ElasticsearchOption": {
    "Url": "http://elasticsearch-server:9200",
    "Username": "elastic",
    "Password": "changeme"
  }

I added a ElasticsearchOption section in the appsettings. The Elasticsearch service in our docker-compose file is named elasticsearch-server, so I’ve configured the Elasticsearch server name accordingly.

Program.cs

var userName = builder.Configuration.GetSection("ElasticsearchOption")["Username"];
var password = builder.Configuration.GetSection("ElasticsearchOption")["Password"];
var settings = new ElasticsearchClientSettings(new Uri(builder.Configuration.GetSection("ElasticsearchOption")["Url"]!)).Authentication( new BasicAuthentication(userName!,password!));

var client= new ElasticsearchClient(settings);

builder.Services.AddSingleton(client);

builder.Services.AddScoped<ElasticsearchService>();

I created ElasaticsearchClientSettings object to connect with Elasticsearch, and registered ElasticsearchClientfor search operations as above.

Docker-Compose

We have three services here our Web API application, Elasticsearch server and Kibana.

asp-net-core-elasticsearch

 asp-net-core-elasticsearch:
    container_name: asp-net-core-elasticsearch
    image: aliyildizoz909/docker-demo-elasticsearch
    ports:
      - "5000:8080"
    depends_on:
      - elasticsearch-server

• container_name: asp-net-core-elasticsearch: We set the container name as asp-net-core-elasticsearch.
• image: aliyildizoz909/docker-demo-elasticsearch: We specify the image source as aliyildizoz909/docker-demo-elasticsearch .
• "5000:8080" : Here, we did a port publish. When we go to the 5000 port via localhost, we tell the docker to redirect the requests to the 8080 port in the asp-net-core-elasticsearchcontainer. 8080 port is the default port of our published app in the container for asp.net core apps. You can change it via the ASPNETCORE_URLS environment variable or with the new one ASPNETCORE_HTTP_PORTS . See more information.
• depends_on This section defines the priority of services to run. We add here which services we want to run before the current service. So, in our example, we add elasticsearch-server here to run our application after the Elasticsearch server is ready.

elasticsearch-server

 elasticsearch-server:
    container_name: elasticsearch
    image: docker.elastic.co/elasticsearch/elasticsearch:8.7.1
    ports:
      - "9200:9200"
    environment:
      - xpack.security.enabled=false
      - "discovery.type=single-node"

• container_name: elasticsearch-server: We set the container name as elasticsearch-server .
• image: elasticsearch : We specify the image source as elasticsearch.
• 9200: This port represent the Elasticsearch server.
• environment: xpack.security.enabled=false means that Elasticsearch will not require authentication, allowing you to test any application without security restrictions. This is useful in development environments. However, if you set it to true, you'll need to configure additional security settings such as user authentication, role-based access control (RBAC), and TLS/SSL for secure communication.
• environment: The discovery.type=single-node setting in Elasticsearch configures the cluster to run in single-node mode. This means Elasticsearch will not attempt to discover or connect to other nodes, and it assumes that the node running with this configuration is the only one in the cluster.

kibana

kibana:
    container_name: kibana
    image: docker.elastic.co/kibana/kibana:8.7.1
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch-server 

• container_name: kibana: We set the container name as kibana.
• image: docker.elastic.co/kibana/kibana:8.7.1: We specify the image source as docker.elastic.co/kibana/kibana:8.7.1.
• 5601: This port represent the Kibana UI.
• environment: ELASTICSEARCH_HOSTS=http://elasticsearch:9200 is used to specify the URL of the Elasticsearch instance that your kibana will connect to.

Running Docker-Compose File

To run our Docker-Compose setup, use the following command from the directory containing your docker-compose.yml file

docker compose up

After running this command, we can access our application here http://localhost:5000

You can see the app from here.

Thank you.

Async programming is a paradigm that allows us to run multiple tasks concurrently with other tasks without blocking the execution flow. This technique is very useful for performing tasks that take a long time to complete. Because these tasks do not block the main thread, they increase application performance.

In asynchronous programming, we utilize the await keyword and the Task.Wait() and Task.WaitAll() methods. While these methods may seem similar, there are significant differences. This article will explore the distinctions between await, Task.Wait(), and Task.WaitAll().

await Keyword

Using this keyword initiates the task asynchronously, meaning it operates on a separate thread or subsystem without blocking the main thread. When this keyword is employed, the code pauses until the task concludes on the other thread, allowing the main thread to process other tasks concurrently.

Usage-1

var result = await DoSomethingAsync();

This usage pauses the execution of the current method at this line of code until the task completes. However, it doesn’t block the main thread, allowing it to continue executing other operations.

Usage-2

var task = DoSomethingAsync();

This usage starts the asynchronous task without pausing the current method, allowing subsequent code to execute immediately. The task runs in the background, freeing the main thread to perform other operations concurrently.

Task.Wait()

Unlike await, Task.Wait() converts asynchronous code to synchronous by blocking the main thread until the task completes.

Usage

var task = DoSomethingAsync();
task.Wait();
var result = task.Result;

Be careful when using this method because it will block the main thread until it completes the task, preventing any other operations until the main thread is released.

Task.Result

var task = DoSomethingAsync();
var result = task.Result;
//OR
var task = DoSomethingAsync().Result;

Accessing Task.Result works similarly to Task.Wait(), blocking the main thread until the task completes.

Task.WaitAll()

While Task.WaitAll() accepts multiple tasks and allows them to execute asynchronously, the method itself runs synchronously, blocking the main thread until all tasks have completed.

Task.WaitAll(task1,task2,task3, ....);

Again, this method blocks the main thread and waits synchronously until all tasks are completed but it executes the tasks asynchronously.

Thanks.

Caching is one of the important subjects in the software field. For reducing our application response time and improve the performance, caching is a very helpful tool.

There are two types of caching mechanisms.

• In-Memory Caching: The data are kept in the host’s memory on which the application resides.
• Distributed Caching: The data are kept on a different server in which the application doesn’t reside.

Redis is a Distributed Caching tool. There are some advantages and disadvantages for both caching mechanisms but I won’t explain them in this article. In this article, I will show you how to create a docker-compose file for an application that uses Redis.

Example Application

Our application will be a basic to-do application. It will perform read, add, and remove operations on the cache.

There are many libraries to use Redis in Asp.Net Core applications. In our example, we will use StackExchange.Redis library.

StackExchange.Redis

This is the most popular NuGet package for utilizing Redis with full functionality. It provides access to all redis-cli commands, it is very useful for complex scenarios. However, the implementation may be slightly more difficult compared to other methods. It may require setting up a Redis service and configuring the connection to the Redis server. This package uses the IDatabase interface for executing Redis commands.

appsettings.Production.json

  "RedisOption": {
    "Configuration": "redis-server",
    "DefaultDatabase": 0
  }

I added a RedisOption section to the appsettings. The Redis service in our docker-compose file is named redis-server, so I’ve configured the Redis server name accordingly. There are many databases numbered in the Redis server, I used 0 database as the default.

RedisService

 public class RedisService
 {
     private ConnectionMultiplexer _redis;

     public IDatabase Database { get; set; }
     public RedisService(IConfiguration configuration)
     {
         _redis = ConnectionMultiplexer.Connect(configuration.GetValue<string>("RedisOption:Configuration"));
         Database = _redis.GetDatabase(configuration.GetValue<int>("RedisOption:DefaultDatabase"));
     }

     public IDatabase GetDatabase(int db)
     {
         return _redis.GetDatabase(db);
     }
 }

I implemented a service to carry out general operations for Redis. Initially, it establishes a connection to Redis and then sets the default database.

Program.cs

builder.Services.AddSingleton<RedisService>();
builder.Services.AddSingleton<IDatabase>(x =>
{
    var redisService = x.GetService<RedisService>();
    return redisService.Database;
});

I registered RedisService and IDatabase as singletons to be accessible in the controllers.

ToDosController

    [HttpGet]
    public async Task<IEnumerable<string>> GetAsync()
    {
        if (_database.KeyExists(ToDosKey))
        {
            var cacheValue = await _database.ListRangeAsync(ToDosKey);
            return cacheValue.Select(x => x.ToString());
        }

        return [];
    }

    [HttpPost]
    public async Task<string> PostAsync(string todo)
    {
        await _database.ListRightPushAsync(ToDosKey, todo);
        return todo;
    }

    [HttpDelete]
    public async Task<string> DeleteAsync(string todo)
    {
        await _database.ListRemoveAsync(ToDosKey, todo);
        return todo;
    }

We have a controller here for testing Redis. It essentially uses the Redis List type to retrieve todos from the cache, adds a todo to the cache, and removes them from the cache.

You can see the app from here.

Docker-Compose

Actually, integrating Redis into a Docker container for use with an Asp.Net Core application, or any other application, is quite straightforward. You just have to make sure that the Redis service name in the docker-compose file corresponds with the Redis server’s configuration name in your application’s connection settings.

We have two services here our Web API application and Redis server.

asp-net-core-redis

asp-net-core-redis:
    container_name: asp-net-core-redis
    image: aliyildizoz909/docker-demo-redis
    ports:
      - "5000:8080"
    depends_on:
      - redis-server

• container_name: asp-net-core-redis: We set the container name as asp-net-redis .
• image: aliyildizoz909/docker-demo-redis : We specify the image source as aliyildizoz909/docker-demo-redis .
• "5000:8080" : Here, we did a port publish. When we go to the 5000 port via localhost, we tell the docker to redirect the requests to the 8080 port in the asp-net-core-rediscontainer. 8080 port is the default port of our published app in the container for asp.net core apps. You can change it via the ASPNETCORE_URLS environment variable or with the new one ASPNETCORE_HTTP_PORTS . See more information.
• depends_on This section defines the priority of services to run. We add here which services we want to run before the current service. So, in our example, we add redis-server here to run our application after the Redis server is ready.

redis-server

  redis-server:
    container_name: redis-server
    image: redis
    ports:
      - "6379:6379"

• container_name: redis-server: We set the container name as redis-server .
• image: redis : We specify the image source as redis.
• 6379:6379: These ports represent the Redis server.

Running Docker-Compose File

To run our Docker-Compose setup, use the following command from the directory containing your docker-compose.yml file

docker compose up

After running this command, we can access our application here http://localhost:5000

Thank you.

Docker-Compose for Asp.Net Core & Redis was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

RabbitMQ is a popular open-source message broker. It is easy to implement in your application and manage your queue, exchange, and messages. It supports many programming languages. Also, you can use it with many technologies, such as web apps, RPC, Streaming, or IoT.

In this article, I will demonstrate how to configure a Docker-Compose environment for an ASP.NET Core Web API and RabbitMQ.

Example Application

In our application, we will have two projects. We will send a weather forecast notification to our queue via the Asp.Net Core Web API application and then receive the message in the Worker Service application.

1. Asp.Net Core Web API Application: This app will be our publisher. We will make an HTTP Post request with Swagger to publish our message.
2. Worker Service Application: This app will be our consumer. We will receive messages here.

Connection String Configuration

When our apps run in a container they will be in the Production environment. So I added the RabbitMQ connection string to the appsettings.Production.json file.

  "ConnectionStrings": {
    "RabbitMQ": "amqp://guest:guest@docker-rabbitmq-server:5672"
  }

As you see I gave the server name as docker-rabbitmq-server . This name corresponds to the RabbitMQ service name in the docker-compose file. Docker provides a DNS service between containers in the same network. So we don't have to give the server IP address. It is important that we use the same connection string in both projects. They have to connect to the same RabbitMQ server.

I used the default username and password for RabbitMQ so I didn’t add an Environment Variable for those fields. You can provide those fields with environment variables at runtime for security vulnerabilities.

Sending Message

[HttpPost]
public IActionResult Post()
{
    var weatherForecast = new WeatherForecast
    {
        Date = DateTime.Now,
        TemperatureC = Random.Shared.Next(-20, 55),
        Summary = Summaries[Random.Shared.Next(Summaries.Length)]
    };

    _rabbitMQPublisher.Publish(weatherForecast);

    return Ok(weatherForecast);
}

After running the web API, we will make a post request to this action. As you see, it creates a random temperature and summary and then publishes it.

Receiving Message

public override Task StartAsync(CancellationToken cancellationToken)
 {
     _channel = _rabbitMQClientService.Connect();
     _channel.BasicQos(0, 1, false);
     return base.StartAsync(cancellationToken);
 }
 protected override async Task ExecuteAsync(CancellationToken stoppingToken)
 {
     var consumer = new AsyncEventingBasicConsumer(_channel);
     _channel.BasicConsume(RabbitMQClientService.QueueName, false, consumer);
     consumer.Received += Consumer_Received;
 }

 private async Task Consumer_Received(object sender, BasicDeliverEventArgs @event)
 {
     var weatherForecast = JsonSerializer.Deserialize<WeatherForecast>(Encoding.UTF8.GetString(@event.Body.ToArray()));

     Console.WriteLine("\nNew Weather Forecast Notification!!!");
     Console.WriteLine($"{nameof(weatherForecast.Date)}:{weatherForecast.Date.ToString("f")} {nameof(weatherForecast.TemperatureF)}:{weatherForecast.TemperatureF} {nameof(weatherForecast.TemperatureC)}:{weatherForecast.TemperatureC} {nameof(weatherForecast.Summary)}:{weatherForecast.Summary}");

     _channel.BasicAck(@event.DeliveryTag, false);
 }

I chose the worker service as the consumer app because it has built-in DI(Dependency Injection), Configuration tool, appsettings file, etc. You can do anything you want here what you do in an Asp.Net Core App too. Our worker service will run automatically after the app is launched.

Here we connected to the Received event. If the queue receives a message, it will trigger this event.

You can see the app from here.

Docker-Compose

We have three services here: the first one is our web API the publisher, the second one is our worker service the consumer and the third one is the RabbitMQ server.

asp-net-core-publisher

 asp-net-core-publisher:
    container_name: asp-net-core-publisher
    image: aliyildizoz909/docker-demo-rabbitmq-publisher
    ports:
      - "5000:8080"
    depends_on:
      - docker-rabbitmq-server   

• container_name: asp-net-core-publisher: We set the container name as asp-net-publisher
• image: aliyildizoz909/docker-demo-rabbitmq-publisher : We specify the image source as aliyildizoz909/docker-demo-rabbitmq-publisher
• "5000:8080" : Here, we did a port publish. When we go to the 5000 port via localhost, we tell the docker to redirect the requests to the 8080 port in the asp-net-core-publishercontainer. 8080 port is the default port of our published app in the container for asp.net core apps. You can change it via the ASPNETCORE_URLS environment variable or with the new one ASPNETCORE_HTTP_PORTS . See more information.
• depends_on This section defines the priority of services to run. We add here which services we want to run before the current service. So, in our example, we add docker-rabbitmq-server here to run our application after the RabbitMQ server is ready.

worker-service-consumer

 worker-service-consumer:
    container_name: worker-service-consumer
    image: aliyildizoz909/docker-demo-rabbitmq-consumer
    depends_on:
      - docker-rabbitmq-server

• container_name: worker-service-consumer: We set the container name as worker-service-consumer
• image: aliyildizoz909/docker-demo-rabbitmq-consumer : We specify the image source as aliyildizoz909/docker-demo-rabbitmq-consumer
• depends_on: Before the application runs the RabbitMQ server should be ready otherwise, it will not be able to connect and will give an error.

docker-rabbitmq-server

  docker-rabbitmq-server:
    container_name: docker-rabbitmq-server
    image: rabbitmq:3-management
    ports:
      - "15672:15672"
      - "5672:5672"

• container_name: docker-rabbitmq-server: We set the container name as docker-rabbitmq-server
• image: rabbitmq:3-management : We specify the image source as rabbitmq:3-management. I utilized the 3-management tag for this image to enable the RabbitMQ management plugin for monitoring exchanges, queues, and messages. This tag will provide a management tool at localhost:15672 .
• 15672:15672: These ports represent the management plugin.
• 5672:5672: These ports represent the RabbitMQ server.

Running Docker-Compose File

To run our Docker-Compose setup, use the following command from the directory containing your docker-compose.yml file

docker compose up

After running this command, we can access our application here http://localhost:5000

Thank you.

Docker-Compose for Asp.Net Core & RabbitMQ was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Docker Compose is a tool that helps us run multiple containers together in harmony with one command. With this tool, we can easily test and preview our applications very quickly. We just define our services(containers), volumes, and networks in this file; Docker creates them for us. Docker Compose is usually used for development and testing, but with each release, Docker is making progress on more production-oriented features, too.

In this blog, I explain how to connect an Asp.Net Core Web API application to an MSSQL database in a docker container environment.

I created the application. It performs crud operations on a table. You can view the application from here.

Connection String Configuration

If we consider that our connection be changed in the production, we must create another appsettings file for the production. So, below, I added a ConnectionString section in the appsettings.Production.json file.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "ConnectionStrings": {
    "DefaultConnection": "Server=docker-demo-sqlserver,1433;Database=DockerComposeDemo;User=sa;Password={0};TrustServerCertificate=True"
  }
}

The most important feature of docker-compose is connecting with other containers using their names. Docker provides a DNS service for us here. So here in the Connection string, I use the default port number of the SQL server image and use docker-compose-demo-sqlserver as the server name. I use this name as the name of the SQL server service within the docker-compose file in the following part.

Because of security vulnerabilities, we shouldn’t add the SQL server password into the app settings. In this example, we create an environment variable for the password and provide it dynamically when it runs.

builder.Services.AddDbContext<DockerComposeDemoDbContext>(
                       options =>
                       {
                           var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
                           if (!builder.Environment.IsDevelopment())
                           {
                               var password = Environment.GetEnvironmentVariable("MSSQL_SA_PASSWORD");
                               connectionString = string.Format(connectionString, password);
                           }
                           options.UseSqlServer(connectionString);

                       });

As you see, we first check the environment. If it is not Development, we provide the password from the environment variable called MSQL_SA_PASSWORD. The app provides the connection string to our DbContext at runtime, so we don’t have to add the password in the app settings.

Migration at startup

I apply migration and create the database at runtime. For that, I add the following code to the Program.cs file before the application is launched. When the app runs, it first creates our Database.

using (var scope = app.Services.CreateScope())
{
    var db = scope.ServiceProvider.GetRequiredService<DockerComposeDemoDbContext>();
    db.Database.Migrate();
}
app.Run();

Docker-Compose File

Docker-Compose files allow us to build our Dockerfiles by specifying the build context and Dockerfile path, too. In our example, we use the image from the registry. I add it to the Docker hub; you can check the repository here aliyildizoz909/docker-demo.

We have two services here: the first one configures our web API, and the second one configures the SQL server.

docker-demo-web-api service

 docker-demo-web-api:
    container_name: docker-demo-web-api-container
    image: aliyildizoz909/docker-demo
    environment:
      - MSSQL_SA_PASSWORD=Password1*
    ports:
      - "5000:8080"
    depends_on:
      - docker-demo-sqlserver    

• container_name: docker-demo-web-api-container : We set the container name as docker-demo-web-api-container
• image: aliyildizoz909/docker-demo : We specify the image source as aliyildizoz909/docker-demo
• MSSQL_SA_PASSWORD=Password1* : Under the environment section, we set the MSSQL_SA_PASSWORD environment variable. This variable’s value and the variable's value with the same name under docker-demo-sql-server service should be the same. Otherwise, we cannot access the SQL server in the container. The variable's name is another important thing we should be careful about. We must use the same variable name when we get the password in our application.
• "5000:8080" : Here, we did a port publish. When we go to the 5000 port via localhost, we tell the docker to redirect the requests to the 8080 port in the docker-demo-web-apicontainer. 8080 port is the default port of our published app in the container for asp.net core apps. You can change it via the ASPNETCORE_URLS environment variable or with the new one ASPNETCORE_HTTP_PORTS . See more information.
• depends_on This section defines the priority of services to run. We add here which services we want to run before the current service. So, in our example, we add docker-demo-sqlservice here to run our application after the SQL server is ready.

docker-demo-sqlserver service

  docker-demo-sqlserver:
    container_name: docker-demo-sqlserver-container
    image: mcr.microsoft.com/mssql/server:2022-latest
    environment:
      - ACCEPT_EULA=Y
      - MSSQL_SA_PASSWORD=Password1*
    ports:
      - "1433:1433"

• container_name: docker-demo-sqlserver-container : We set the container name as docker-demo-sqlserver-container
• image: mcr.microsoft.com/mssql/server:2022-latest : We specify the image source as mcr.microsoft.com/mssql/server:2022-latest
• ACCEPT_EULA and MSSQL_SA_PASSWORD are mandatory environment variables for this image. ACCEPT_EULA=Y means that we confirm acceptance of the End-User Licensing Agreement. MSSQL_SA_PASSWORD environment variable sets the password for the database system administrator (user-id = ‘sa’) to connect to the SQL Server once the container runs.
• "1433:1433" 1433 port is the default port for the SQL server. So here, we mapped the host port number(1433) and the container port number(1433).

Running Docker-Compose File

With the following command, we run our docker-compose file.

docker compose up

After running this command, we access our application here http://localhost:5000

You can also check my blog Understanding Asp.Net Core Dockerfile if you want to understand how the Dockerfile works and the Dockerfile of this image(aliyildizoz909/docker-demo).

Thank you.

Dockerfile Build Process

A Dockerfile is a file that contains a set of instructions listed sequentially. In other words, it is a set of instructions. Docker reads and builds these files to create images and later uses these images to create containers.

But how it works?

When we build a Dockerfile, Docker starts many processes from the first line down to the end of the lines. Every line corresponds to an image layer, using the previous layer as a base image. Docker also caches every layer in this process to avoid building the unchanged layers again. With this cache mechanism, Docker reduces the building time.

Docker build steps

1. In the first step, Docker reads the first line and pulls(if it does not exist) the specified base image from a registry during the FROM instruction process.
2. If there are executions of instructions in the Dockerfile, such as RUN, COPY or ADD Docker creates a temporary container from the previous image layer and executes these instructions in this container. After it completes the executions, Docker captures the changes in the temporary container and creates a new image's layer from these changes. After executions of instructions the layer will be created and Docker removes these temporary containers.
3. If a multi-stage build is involved and the stages don’t depend on each other, Docker builds every stage in parallel.
4. After Docker creates layers for each line, it tags these layers with a final image.

Importance of Instruction Order

Due to the caching mechanism, the order of instructions becomes very important. When creating a Dockerfile, we should first add the instructions that are less likely to change.

For example, we have a Dockerfile below.

FROM scratch
COPY src .
EXPOSE 80

We had built this file, and Docker started to put every line into the cache. Later, we needed to change our source files and rebuild the image. In this case, docker has been building COPY src . and EXPOSE 80 lines but does not build FROM scratchline; it gets it from the cache. This happens because the changes happen after FROM instruction, they don't affect this layer.

If we change the Dockerfile below

FROM scratch
EXPOSE 80
COPY src .

Even if we change src files, Docker would not rebuild the EXPOSE 80 line. It uses the cached layer because the changes happen after this line.

After understanding how Docker builds a Dockerfile, we can review every Asp.Net Core Web API Dockerfile instruction.

Asp.Net Core Web Api Dockerfile

VS 2022 has a Docker support tool that helps us create and build Dockerfiles or run containers. This is the default Dockerfile with recommended instructions provided by the VS 2022.

1. FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base

We pulled an image with the FROM instruction and gave it a temporary name(base). This image is a Debian OS image that includes the Asp.net Core 8.0 runtime. You can see its Dockerfile here.

Why do we add an image as a base here?

To run an application, we should have an OS that has our application’s dependencies. Without a base image, we can’t run our applications.

2. USER app

We switch to an app user here. After this instruction, our OS changes the default user(root) to the app user. The app user has fewer permissions than the root user, which is better than using a limitless permission user for potential security vulnerabilities. See more information.

3. WORKDIR /app

With this instruction, we switched to the /app directory. If /app doesn’t exist, Docker creates it. This directory contains our published application files.

base-stage
└── app

The folder view in the image after creating the working directory at the base stage.

4. EXPOSE 8080
5. EXPOSE 8081

Here, we specify to docker that our app uses the 8080 and 8081 ports. This is not a port publish; do not get it wrong. Our application uses these ports between other containers that connect to it, not outside the container. If you want to access the ports from outside the container, you should make a port publish.

7. FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build

We can use multi-stage builds in Dockerfiles. In this Dockerfile, we have 4 stages; every stage has a name and some operations to prepare the final stage. We use it to build multiple operations simultaneously, reducing the building time and the image size.

How do multi-stage builds reduce image size?

To develop a .Net application, we first need an SDK(Software Development Kit). Without an SDK, we can’t publish or build our application. However, SDKs are large, and they increase image sizes too much if we consider that we only need a runtime to run our application(that’s why we used a runtime as a base image, not an SDK). At this point, multi-stage builds are very helpful in avoiding unnecessary tools and SDKs. After a stage is completed, we move the files created by SDK to the final stage. Docker doesn’t move the SDK or the tool we installed in this stage to the final stage. So, in this way, our image only has a runtime and uses the SDK, too.

In this line, we create a stage called build from .Net SDK Image. In this stage, we perform our application’s build operations.

8. ARG BUILD_CONFIGURATION=Release

In this line, we declared an ARG called BUILD_CONFIGURATION with default value(Release). We will use this arg to change the build and publish configuration when we build Dockerfile.

Dockerfile lets us change the build behavior at runtime when we execute the build command. For example, we have two versions of our base image, and we want to build and publish our app with these two versions.

What can we do here?

First, we use two different Dockerfiles and add both versions to them. Yes, it works for us, but we have to build these images separately. However, if we use an arg like this ARG VERSION then, if we add the arg with $ in our base image statement like this FROM base-image:$VERSION we can change the version when building the Dockerfile with --build-arg flag.

example: docker build --build-arg VERSION=1.0 -t my-app:1.0

9. WORKDIR /src

We switch to the /src directory in the build stage. Every stage has its own file system based on the image of the stage. So this is the directory, and the /app directory in the 3. line are in the different file systems.

build-stage
└── src

The folder view in the image after creating a working directory at the build stage.

10. COPY [“DockerDemoWebApi/DockerDemoWebApi.csproj”,  “DockerDemoWebApi/”]

COPY is the most necessary instruction in a Dockerfile; if we cannot copy our application to the image, what is the meaning of dockerizing the app? In this line, we copy our app file with the .csproj extension to the DockerDemoWebApi directory in the /src file. When we use the COPY instruction, Docker creates a directory even if it doesn't exist in the image, like the WORKDIR instruction.

The important thing about the COPY instruction is to consider which path to use when executing the docker build command. If we provide the wrong build context to the command, Docker does not find the files we want to copy and give an error.

Why we only copied DockerDemoWebApi.csproj file?

Before building the application, we should install its dependencies, such as the packages, libraries, or frameworks it uses. If docker can’t install a package, it stops the build process, allowing us to catch errors easily. Another reason we do this is to benefit from the cache mechanism. Once we install all packages successfully, Docker does not install the packages even if we rebuild the Dockerfile again. It uses this layer from the cache.

build-stage
└── src
    └── DockerDemoWebApi
        └── DockerDemoWebApi.csproj

The folder view in the image after copying DockerDemoWebApi.csproj file at the build stage. We are still in the src directory.

11. RUN dotnet restore “./DockerDemoWebApi/DockerDemoWebApi.csproj”

We use RUN instructions to execute specified commands. In this line, we execute the dotnet restore command. This command creates config files to install our packages for the provided project. (./DockerDemoWebApi/DockerDemoWebApi.csproj).

build-stage
└── src
    └── DockerDemoWebApi
        ├── obj
        │   ├── DockerDemoWebApi.csproj.nuget.dgspec.json
        │   ├── DockerDemoWebApi.csproj.nuget.g.props
        │   ├── DockerDemoWebApi.csproj.nuget.g.targets
        │   ├── project.assets.json
        │   └── project.nuget.cache
        └── DockerDemoWebApi.csproj

The folder view in the image after copying DockerDemoWebApi.csproj file at the build stage.

12. COPY . .

We copy everything from the build context to the src directory in this line.

build-stage
└── src
    └── DockerDemoWebApi
        ├── Controllers
        │   └── WeatherForecastController.cs
        ├── obj
        │   ├── DockerDemoWebApi.csproj.nuget.dgspec.json
        │   ├── DockerDemoWebApi.csproj.nuget.g.props
        │   ├── DockerDemoWebApi.csproj.nuget.g.targets
        │   ├── project.assets.json
        │   └── project.nuget.cache
        ├── Properties
        │   └── launchSettings.json
        ├── appsettings.Development.json
        ├── appsettings.json
        ├── DockerDemoWebApi.csproj
        ├── Program
        └── WeatherForecast.cs

The folder view in the image after copying all files at the build stage.

.dockerignore

Our project has many folders and files. Most of them were created during development. These files make the development process easier and speed up the building process. However, we don’t need them in the image. Firstly, we start building the application in the image(dotnet build), and also, we don't develop it in the image. To avoid these files, we use the .dockerignore file. This also increases the building time when we build the Dockerfile.

**/.dockerignore
**/.env
**/.git
**/.gitignore
**/.vs
**/.vscode
**/bin
**/docker-compose*
**/Dockerfile*
**/node_modules
**/obj
LICENSE
README.md
!**/.gitignore
!.git/HEAD
!.git/config
!.git/packed-refs
!.git/refs/heads/**

13. WORKDIR “/src/DockerDemoWebApi”

We changed the working directory to build our application.

14. RUN dotnet build “./DockerDemoWebApi.csproj” -c $BUILD_CONFIGURATION -o /app/build

Here, we build our application with dotnet build command. To build our application with this command, we should give the application path where the files with the .csproj or .sln extension exist. With -c flag, we indicate which configuration(Debug or Release) we build the application with. We used $BUILD_CONFIGURATION arg here. This means we can provide this value when we build Dockerfile. If we don't provide it, the Docker uses the default arg value(8th Line). With -o flag, we provide the path that dotnet saves the created files after the building process.

build-stage
├── src
│   └── DockerDemoWebApi
│       ├── Controllers
│       │   └── WeatherForecastController.cs
│       ├── obj
│       │   ├── DockerDemoWebApi.csproj.nuget.dgspec.json
│       │   ├── DockerDemoWebApi.csproj.nuget.g.props
│       │   ├── DockerDemoWebApi.csproj.nuget.g.targets
│       │   ├── project.assets.json
│       │   └── project.nuget.cache
│       ├── Properties
│       │   └── launchSettings.json
│       ├── appsettings.Development.json
│       ├── appsettings.json
│       ├── DockerDemoWebApi.csproj
│       ├── Program
│       └── WeatherForecast.cs
└── app
    └── build
        ├── appsettings.Development.json
        ├── appsettings.json
        ├── DockerDemoWebApi.deps.json
        ├── DockerDemoWebApi.dll
        ├── DockerDemoWebApi.exe
        ├── DockerDemoWebApi.pdb
        ├── DockerDemoWebApi.runtimeconfig.json
        ├── Microsoft.OpenApi.dll
        ├── Swashbuckle.AspNetCore.Swagger.dll
        ├── Swashbuckle.AspNetCore.SwaggerGen.dll
        └── Swashbuckle.AspNetCore.SwaggerUI.dll

The folder view in the image after running the build command at the build stage.

If you notice, the app folder is on the same level as the src folder, that is because we provide the build path with a starting slash(-o /app/build). This usage creates folders at the root level.

16. FROM build AS publish

Docker also allows us to create a stage from another stage like here(16th line). In this stage, we do our publishing operations.

17. ARG BUILD_CONFIGURATION=Release

You may ask why we defined the BUILD_CONFIGURATION arg again; can’t we use the previous one? I quote from the docker doc. for the answer.

An ARG variable definition comes into effect from the line on which it is defined in the Dockerfile not from the argument's use on the command-line or elsewhere. Source: Dockerfile reference | Args-Scope

18. RUN dotnet publish “./DockerDemoWebApi.csproj” -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

With dotnet publish command, we publish our app using the provided configuration. The only strange thing is /p:UseAppHost=false . This expression means set false value to the UseAppHost property (/p:). .Net applications have some settings for development and publishing operations. We can change these settings in the project file(.csproj), or we can change them while building or publishing the application with a command. Basically, the UseAppHost property controls whether or not a native executable(the .exe file) is created for deployment. In the container, we don't execute this file manually; even if we want to, we still cannot run it in a Linux OS. Therefore, this file is not necessary. Also, it increases the image size if we create it.

publish-stage
├── src
│   └── DockerDemoWebApi
│       ├── Controllers
│       │   └── WeatherForecastController.cs
│       ├── obj
│       │   ├── DockerDemoWebApi.csproj.nuget.dgspec.json
│       │   ├── DockerDemoWebApi.csproj.nuget.g.props
│       │   ├── DockerDemoWebApi.csproj.nuget.g.targets
│       │   ├── project.assets.json
│       │   └── project.nuget.cache
│       ├── Properties
│       │   └── launchSettings.json
│       ├── appsettings.Development.json
│       ├── appsettings.json
│       ├── DockerDemoWebApi.csproj
│       ├── Program
│       └── WeatherForecast.cs
└── app
    ├── build
    │   ├── appsettings.Development.json
    │   ├── appsettings.json
    │   ├── DockerDemoWebApi.deps.json
    │   ├── DockerDemoWebApi.dll
    │   ├── DockerDemoWebApi.exe
    │   ├── DockerDemoWebApi.pdb
    │   ├── DockerDemoWebApi.runtimeconfig.json
    │   ├── Microsoft.OpenApi.dll
    │   ├── Swashbuckle.AspNetCore.Swagger.dll
    │   ├── Swashbuckle.AspNetCore.SwaggerGen.dll
    │   └── Swashbuckle.AspNetCore.SwaggerUI.dll
    └── publish
        ├── appsettings.json
        ├── DockerDemoWebApi.deps.json
        ├── DockerDemoWebApi.dll
        ├── DockerDemoWebApi.pdb
        ├── DockerDemoWebApi.runtimeconfig.json
        ├── Microsoft.OpenApi.dll
        ├── Swashbuckle.AspNetCore.Swagger.dll
        ├── Swashbuckle.AspNetCore.SwaggerGen.dll
        ├── Swashbuckle.AspNetCore.SwaggerUI.dll
        ├── web.config
        └── appsettings.Development.json

The folder view in the image after running the publish command at the publish stage.

20. FROM base AS final

We create a stage named the final from the base stage.

21. WORKDIR /app

We change the working directory to /app.

22. COPY —from=publish /app/publish .

In the COPY instruction, we can also copy files from another stage or an image from a registry. To use COPY like that, we use --from flag. In this line, we copied all the files in the publish folder from the publish stage to the /app directory.

final-stage
└── app
    ├── appsettings.json
    ├── DockerDemoWebApi.deps.json
    ├── DockerDemoWebApi.dll
    ├── DockerDemoWebApi.pdb
    ├── DockerDemoWebApi.runtimeconfig.json
    ├── Microsoft.OpenApi.dll
    ├── Swashbuckle.AspNetCore.Swagger.dll
    ├── Swashbuckle.AspNetCore.SwaggerGen.dll
    ├── Swashbuckle.AspNetCore.SwaggerUI.dll
    ├── web.config
    └── appsettings.Development.json

The folder view in the image after copying the publish files at the final stage.

23. ENTRYPOINT [“dotnet”, “DockerDemoWebApi.dll”]

After making our application ready to run, we use ENTRYPOINT instructions for the running operation. Here, we tell Docker to run our application automatically when someone creates a container from the image created from this Dockerfile.

Building Dockerfile

I use the docker build command for this operation, but you can also build it with the VS 2022 Docker Support tool.

Build Command Schema

docker build [OPTIONS] PATH | URL | -

The first step in building a Dockerfile is specifying the build context. The built context means that when Docker starts to build the Dockerfile, it copies your files from which PATH or URL. In our Dockerfile, we copy every file from under the DockerDemoWebApi folder. Because of that, our built context has to be the parent folder of the DockerDemoWebApi folder. To understand more, in the 10th line, we specify docker that our DockerDemoWebApi.csproj file is under the DockerDemoWebApi folder. So if I give a wrong build context to docker, it searches the DockerDemoWebApi folder, and because of the wrong build context, error occurs.

docker build ./WrongBuildContext

The second step is specifying the Dockerfile path. This is also important because if your Dockerfile path is different from your build context, you may have to use -f flag to specify the Dockerfile path.

You can give a tag and a name to your image with -t flag, but if you don't use it, docker sets <none> for the name and tag. If you only use one word, docker sets that word as the name of the image and shows your current image tag as the latest. However, if you use a colon(:), docker sets the word on the left of the colon as a name and the right of the colon as a tag.

docker build -t docker-demo:v1 -f ./DockerDemoWebApi/Dockerfile . 

With this command, we tell docker that;

1. Our Dockerfile is in the DockerDemoWebApi folder, so, search for it from the current path. -f ./DockerDemoWebApi/Dockerfile
2. Your build context is where I execute this command to .
3. Your image name is docker-demo and your tag is v1 .

$ docker image ls
REPOSITORY    TAG       IMAGE ID       CREATED             SIZE
docker-demo   v1        d798fa0b4c44   About an hour ago   221MB

The blog took a bit longer, but I wanted you to understand better how Docker builds operations.

Thank you for reading until the end. See you.

Merhabalar,

Bildiğiniz gibi mobil uygulama geliştirmek için bir çok yöntem var. Yaptığınız projeye, projenin süresine veya başka parametrelere bağlı olarak bu yöntemlerden birini seçebiliyoruz.

Bu yöntemler;

• Native (ios: Objective-C, Swift android: Java, Kotlin)
• Cross-Platform Native(Xamarin, React Native, Flutter)
• Hybrid (Capacitor, Apache Cordova, Adobe PhoneGap)
• PWA(Progressive Web Applications)(HTML, CSS, Javascript)

Ben bu yazımda sizlere Capacitor ile nasıl Hibrit uygulama geliştirilir, android ve ios’a nasıl uygulama çıkartılır, cli komutları nelerdir v.b. soruları cevaplamaya çalışacağım.

Teknik konulara geçmeden önce Hibrit Uygulama ve WebView nedir ve nasıl çalışır bunlara bakalım.

Hibrit mobil uygulama nedir?

Kısaca tek bir code base ile standart web teknolojilerini -Html, CSS ve javascript- kullanarak, bir çok mobil platformda çalışan uygulamalara hibrit uygulama diyebiliriz. Adının hibrit olmasının sebebi uygulamamızın aslında web uygulaması olduğu halde native bir şekilde kullanılabiliyor olmasından kaynaklanıyor.

Hibrit uygulama nasıl çalışır?

Hibrit uygulamalar mobil cihazda bir “web container” içinde çalıştırılır. Web Containerlar hibrit uygulamalarımız için bir browser runtime’ı sağlar. Bu sayede bir web uygulamamızı bir mobil cihazda çalıştırabiliyoruz.

Tabii web sayfasını sadece çalıştırarak ancak sayfaları görüntüleyebiliriz. Eğer cihazla da konuşmak istiyorsak -kameraya erişim gibi- bazı aracı teknolojiler kullanmamız gerekiyor.

Hibrit Uygulama Geliştirme Araçları

• CapacitorJs
• Apache Cordova
• Adobe PhoneGap
• Ionic Framework( Bir UI Framework’üdür Capacitor ile kullanılır)

Capacitor Nedir?

Şu anda v4.0'ı çıkarmış olan Capacitor, Ionic tarafından geliştirilmiş Ionic Framework, popüler web teknolojileri(Angular, React, Vue v.b.) ya da custom bir web sayfası ile de kullanılabilen bir hibrit uygulama geliştirme aracıdır. Kendi web sayfasında kendini “hibrit uygulamaların bir sonraki evrimi” olarak tanıtıyor. Aynı zamanda Apache Cordova ve Adobe PhoneGap’in manevi halefi olduğunu da belirtiyor. Bu nedenle bir çok Cordova plugini ile de geriye dönük uyumlu çalışabiliyor. Capacitor ayrıca PWA(Progressive Web Applications)’ı da destekliyor. Yani capacitor pluginleri PWA uygulamasında da sorunsuz çalışabiliyor.

Capacitor Plugin nedir?

Capacitor web sayfalarımızı göstermekle beraber cihaz ile web uygulamamız arasında köprü görevi görüyor. Eğer telefonun bir özelliğine erişmek istiyorsak onunla ilgili plugini web uygulamamıza eklememiz gerekiyor. Örneğin kameraya veya galeriye erişim için camera plugini’ni ya da pilin yüzde kaç kaldığını, şuan şarj ediliyor mu gibi bilgileri almak için device plugini’ni web projemize eklemek gerekiyor. Bu pluginleri npm ile projenize ekleyebilirsiniz.

Capacitor Community’si tarafından geliştirilen electron plugini ile de uygulamalarınızı desktop app olarak Linux, Mac ve Windows’ta çalıştırabilirsiniz.

Capacitor Pluginleri

• Resmi Pluginler: Capastior takımı tarafından maintain edilen pluginlerdir. (Action Sheet, App, Camera, Google Maps v.b.)
• Community Plugins: Capacitor Community’si tarafından maintain edilen pluginlerdir. Buradan açık kaynak pluginlere bakabilirsiniz.

Tabii native kadar cihazın tüm özelliklerine erişemesek de çoğu özelliğine erişebiliyoruz. Eğer bu pluginler işinizi görmüyorsa kendi plugin’inizi de geliştirip yayınlayabilirsiniz. Nasıl geliştireceğinize buradan bakabilirsiniz.

Capacitor Kurulum

Kurulum için gereksinimler aşağıda belirtilmiştir.

• Nodejs versiyonu 14 veya üzeri
• Android için
  – Android Studio
  – Android SDK Kurulumu
• iOS için
  – Xcode
  – Xcode Command Line Tools
  – Homebrew
  – Cocoapods

Kurulum

• Öncelikle eğer npm’i kurduysanız aşağıdaki komutu çalıştırın sonra aşağıda uygulamanız için gerekli olan soruları cevaplayın.
  npm init @capacitor/app
• Uygulamanın adını
  ? What is the name of your app?
• Uygulamanın kurulacağı dosya yolu
  ? What directory should be used for your app?
• Uygulama ID’si (ios için ak Bundle Id ve Android için Application Id’ye karşılık gelen benzersiz domain adı)
  ? What should be the App ID for your app?
• Bu işlemlerden sonra verdiğimiz dosya yolunda bazı dosyalar oluşacaktır. Eğer node_modules klasörü yoksa oluşturmak için uygulama klasöründe aşağıdaki kodu çalıştırın. Ayrıca iki tane capacitor plugini(camera ve splash-screen) de default olarak gelecektir.
  npm install

capacitor.config.json

Capacitor, projemiz oluştuktan sonra capacitor.config.json adında bir dosyayı da oluşturdu. Bu dosyada aslında cevapladığımız bilgilerin olduğunu görebilirsiniz. Capacitor mobil uygulamamızı çalıştırırken bu dosyada ki bilgileri kullanıyor. Uygulamayla ve Pluginlerle ilgili yada genel olarak uygulamayı geliştirme açısından bazı ayarları burada yönetiyoruz.

{
   "appId": "com.example.app", 
   "appName": "capacitor-demo",
   "bundledWebRuntime": false,
   "webDir": "dist",
   "plugins": {
      "SplashScreen": {
          "launchShowDuration": 0
      }
   }
}

Bu dosyada dikkat etmemiz gereken en önemli alan webDir dir. Capacitor mobil uygulamayı çıkartırken her zaman projemizin build alınmış ve içinde index.html dosyasının olduğu bir klasör yolu ister. Bu yolu yanlış verirsek mobil uygulamayı çıkartamayabilir. İşte bu yolu capacitor’e söylediğimiz yer “webDir”. Dosya da yer alan diğer propertylere buradan bakabilirsiniz.

manifest.json

Capacitor’un oluşturduğu bir diğer dosya da manifest.json dosyasıdır. Bu dosya, PWA için uygulamamız hakkında bazı bilgiler içerir. Tabii sadece bu dosya PWA uygulaması oluşturmak için yeterli değildir. Çok daha farklı bir konu olduğu için, buradan nasıl oluşturacağınızla ilgili daha detaylı bilgilere ulaşabilirsiniz.

Web uygulamamızı ayağa kaldırmak için npm start komutunu uygulama klasöründe çalıştıralım.

Bir de söylemeye gerek duymadım ama uygulamamız mobilde çalışacağı için responsive bir şekilde geliştirme yapmak çok önem kazanıyor.

iOS ve Android için CLI komutları

Web uygulamamızın mobil platformlarda ki projelerini çıkartmak ve yönetmek için capacitor’un cli komutlarını kullanacağız.
Bu komutları kullanmak için uygulama klasörümüzde
npm i @capacitor/cli komutunu çalıştırıp ilgili paketi yükleyelim.

Android ve iOS npm paketleri

Android için npm i @capacitor/android komutunu,
iOS için npm i @capacitor/ios komutunu çalıştırın.

Android platformu için uygulama çıkarma komutu

Aşağıdaki komut ile android adında, android uygulamasının bulunduğu bir klasör oluşturuyoruz.
npx cap add android

iOS platformu için uygulama çıkarma komutu

Aşağıdaki komut ile ios adında, ios uygulamasının bulunduğu bir klasör oluşturuyoruz.
npx cap add ios

Web uygulamasının build alınmış son halini çıkartma komutu

Aşağıdaki komut ile dist adında, web uygulamasının build alınmış son halinin bulunduğu bir klasör oluşturuyoruz.
npm run-script build

Bu komutları uygulama klasöründe çalıştırın. Aşağıdaki görselde projenin son halini görebilirsiniz.

Bu aşamadan sonra npx cap sync komutunu çalıştırıyoruz. Ayrıca bu komutu uygulamanızda yaptığınız her değişiklik veya eklenen her plugin için de tekrar çalıştırmamız gerekiyor. Bunu web uygulamamızdaki değişiklikler mobil uygulamalarımıza da yansısın diye yapıyoruz.

Android ve iOS klasörlerimiz oluştuysa bunları ister capacitor’un cli komutlarıyla isterseniz de kendi ide’lerinde(Xcode, Android Studio) açma veya çalıştırma işlemlerini yapabilirsiniz.

• npx cap open android/ios android veya ios klasörlerini kendi idelerinde açar (android için Android Studio ios için Xcode’u)
• npx cap run android/ios Android Studio veya Xcode’u çalıştırır.

Avantajlar

• Tek bir code base üzerinden geliştirme yapılabilmesi
• Open Source olması
• Eğer web developer iseniz yabancı olmadığınız bir ortamda kod yazma
• Hızlı geliştirme, aynı anda iki platforma da uygulama çıkartma
• Plugin’lerin PWA uygulamasında çalışabilmesi
• Electron plugini ile bir çok işletim sisteminde çalışan desktop uygulaması geliştirme

Dezavantajlar

• Web componentler kullanıldığı için native uygulama hissi vermemesi(UI,UX).
• Her şeyi yapamama. Eğer 3D oyunlar gibi yüksek performans isteyen uygulamalar geliştiriyorsanız capacitor bunun için uygun olmayabilir.
• Pluginlere bağımlı uygulamalar geliştirme. Eğer mevcut pluginler işinizi görmüyorsa kendi plugininizi yazmak zorunda kalmanız.

Teşekkürler.

Kaynaklar

• Capacitor by Ionic — Cross-platform apps with web technology (capacitorjs.com)
• What is Hybrid Mobile App Development: Hybrid vs Native vs Web (ionic.io)
• Mobile Application Development (amazon.com)
• Capacitor Whitepaper.pdf (hubspotusercontent00.net)

Capacitor ile Hibrit uygulama geliştirme was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Merhaba arkadaşlar,

Bu yazımda, Martin Fowler’ın 2003 yılında yayınlanan Patterns of Enterprise Application Architecture kitabında, ismini verdiği Active Record tasarım kalıbını inceleyeceğiz.

Değineceğim başlıklar aşağıda belirtilmiştir.

• Data Source Architectural Patterns(Veri Kaynağı Mimarisi Kalıpları) nedir?
• Active Record Pattern nedir?
• Ne zaman kullanılır?
• İmplementasyon
• Avantajları ve Dezavantajları

Data Source Architectural Patterns nedir?

Active Record Pattern’inin de dahil olduğu bir tasarım kalıbı çeşididir. Bu çeşide dahil olan tasarım kalıpları, veri erişimini ve veri tabanı ile ilgili işlemleri kolaylaştırmayı amaçlamaktadır. Çoğu, veri tabanını saran bir obje oluşturarak bu işlemleri yapar.

Aşağıda bu gruba dahil olan tasarım kalıpları ve Martin Fowler tarafından yapılan kısa açıklamaları yer alıyor.

• Table Data Gateway

An object that acts as a Gateway to a database table. One instance handles all the rows in the table.

• Row Data Gateway

An object that acts as a Gateway to a single record in a data
source. There is one instance per row.

• Active Record

An object that wraps a row in a database table or view, encapsulates
the database access, and adds domain logic on that data.

• Data Mapper

A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself.

Active Record Pattern nedir?

Bu patternde de, diğer orm araçlarından aşina olduğumuz gibi veri tabanındaki her bir satır, kodlama tarafında bir entity’e denk gelir. Diğerlerinden ayrıldığı nokta, bu entity üzerinde aynı zamanda temsil ettiği tabloya ait tüm operasyonların (CRUD) yapılmasını sağlayan fonksiyonların da yer almasıdır.

Bu tür entityl’ere active record denir. Her active record, veri tabanına kaydetme ve yüklemeden ayrıca veriler üzerinde işlem yapan business logic’ten de sorumludur. Active record patter’nin en belirgin özelliği data access logic’i business nesnesinin içine yerleştirmesidir.

Fotoğrafta, Person ismindeki bir tabloya ait CRUD operasyonları, business logic metotları ve aynı zamanda bir satıra karşılık gelen entity’nin bir arada olduğu görülebilir.

Active Record ve Row Data Gateway pattern’leri birlerine çok benzerdir. Aralarındaki temel fark, Row Data Gateway’in yalnızca veri tabanı erişimini içermesi, Aktive Record’un ise hem veri tabanı erişimi hem de business logic içermesidir.

Ne zaman kullanılır?

Active Record bazı yazılımcılar tarafından anti-pattern olarak isimlendiriliyor ancak kullanımının faydalı olduğu bazı durumlar ve projeler de olabilir.

Active Record tabanlı ORM’ler uygulamanızı çok hızlı bir şekilde oluşturmasını sağlar. Bu nedenle ucuz olması gereken ve kritik olmayan projeler için iyi bir çözüm olabilir. Bu tür projelere örnek olarak prototipler veya POC’lar(Proof Of Concept) verilebilir.

Active Record, business logic için çok karmaşık olmayan; okuma, yazma, güncelleme ve silme gibi işlemleri yapmamız için iyi bir seçim olabilir. Ana problem, ancak Active Record veri tabanındaki tabloya tam olarak karşılık gelirse iyi bir şekilde çalışır.

İmplementasyon

Aşağıda bu patterni implement etmiş framework’ ler belirtilmiştir.

• Eloquent (Laravel framework’ün bir parçası) — PHP
• RoR ActiveRecord (Ruby on Rails framework’ün bir parçası) — Ruby
• Django ORM (Django framework’ün bir parçası) — Python

Örnek

Örneğimizde active record’umuz için veri tabanı işlemlerini ve verileri mapleme işini Dapper ile yapacağız. Basit bir şekilde CRUD işlemlerini yapan bir active record base sınıfı ve bir active record oluşturacağız. Bu süreçte yapacağımız işlemler, bize bu patternin avantajları ve dezavantajlarını daha iyi bir şekilde gösterecektir.

MsSql’de ActiveRecordPatternDb adında örnek bir veri tabanı ve şeması ActiveRecord olan Person adında da bir tablo oluşturdum.

Öncelikle birden fazla active record’umuzun olacağını göz önünde bulundurarak, her biri için ayrı ayrı, aynı fonksiyonları yazmak yerine ortak olan fonksiyonlar(Save, Update, Delete, Read gibi) için bir interface yazmak daha mantıklı geldi. Bir de base sınıfta sql komutu üreteceğimiz için tablonun bazı bilgilerini de(SchemaName) bu interface üzerinde tanımlamak işimizi daha da kolaylaştıracaktır.

Yukarıda her tablo’da ortak olan metotların bulunduğu iki interface yazdım.

Aşağıda BaseActiveRecord adında generic olarak gelen active record’a göre sql komutları üreten bir sınıf oluşturdum. Bu sınıfı, Person active record’umuz kalıtım alacaktır.

Bu sınıfta, active record’tan sadece Schema Name ve tablosunun ismi(yani kendi ismi) dışında kalan tüm bilgiler reflection kütüphanesi kullanılarak alındı.

Aşağıda okuma işlemleri(Read ve FindById) diğerlerinden farklı olarak static bir şekilde tanımlanmış. Kitapta da query işlemlerini yapan metotlar static olarak verilmiş. Bunun sebebi, okuma işlemlerini yapmak için bir active record sınıfı instance’ı oluşturmak zorunda kalmamak içindir.

Yukarıda BaseActiveRecord’u ve IActiveRecord’u kalıtım alan Person isimli bir active recordumuz var. Görüldüğü gibi direkt kendisini base sınıfa parametre geçerek CRUD işlemlerini yapıyor.

Ben yazmadım ama, normalde business logic’ler de Person classına yazılır.

Avantajları ve Dezavantajları

Avantajları

• Hızlı uygulama geliştirme için iyi bir seçimdir.
• Active record’ları oluşturmak ve anlamak kolaydır.
• Kullanılıp atılan prototiplerin hızla uygulanmasını kolaylaştırır.
• Bir active record’a bakarak direkt olarak veri tabanı tablosunun veri yapısını anlayabiliriz.
• Çoğu ihitiyaç duyacağımız şeyleri aynı yerde kodladığımız için çok fazla katman oluşturmamıza gerek kalmaz. Bu da hızlı bir şekilde projeyi oluşturmamızı sağlar.

Dezavantajları

• Martin Fowler’a göre eğer business logic’iniz karmaşıksa ve entityleriniz arasında bire çok gibi ilişkiler ve koleksiyonlar oluşturmak istiyorsanız, bunu Active Record ile yapmanız çok kolay değil. Bunun da Data Mapper Pattern’ini kullanmamıza yol açacağını söylüyor.
• Bu pattern de nesne tasarımı ve veri tabanı tasarımı birleştirildiği için projenin ilerlemesi, her iki tarafında birlikte refactor edilmesini çok zorlaştırıyor.
• İki katmanı birleştirdiği için bağımlılığın yüksek olması sonucu Unit Test yazmayı zorlaştırması.
• SOLID prensiplerin S(Single Responsibility Principle) harfinin ihlal edilmesi. Her bir active record hem bir satıra denk gelen bir model hem bir data access objesi hem de business logic’leri üzerinde barındıran bir business objesi olması.

Robert C. Martin’in bu pattern ile ilgili düşünceleri…

The problem I have with Active Record is that it creates confusion about these two very different styles of programming. A database table is a data structure. It has exposed data and no behavior. But an Active Record appears to be an object. It has “hidden” data, and exposed behavior. I put the word “hidden” in quotes because the data is, in fact, not hidden. Almost all ActiveRecord derivatives export the database columns through accessors and mutators. Indeed, the Active Record is meant to be used like a data structure.

On the other hand, many people put business rule methods in their Active Record classes; which makes them appear to be objects. This leads to a dilemma. On which side of the line does the Active Record really fall? Is it an object? Or is it a data structure?

Örneği hazırlarken yaşadığım deneyimler

Eğer base bir sınıf oluşturup, Active Recordların yaptığı ortak işlemleri merkezileştirmek ve tekrar tekrar aynı kodu yazmak istemiyorsanız, en çok zorlanacağınız konular veri tabanı ve tablo ile ilgili, base sınıfın ihtiyaç duyacağı bilgileri ona ulaştırmanız olacaktır. Çoğu durumda ulaştıramayacağınız bilgileri reflection yardımı ile ulaşacaksınız. Bu bilgiler(tablonun şema adı, Primary Key adı, tablonun kendi adı vb) en başta active record’un üzerinde meta data olarak tutulursa işler biraz daha kolaylaşabilir.

Tablonun adı, örnekte direkt sınıfın adı olarak verildi bu sayede bu bilgiyi base sınıfa ulaştırmaya gerek olmadı benim için. Ama bu da active record’un adını tablo adı ile aynı olmasını her zaman zorunlu tutuyor. Zaten active record’un property’lerinin, tablosunun kolonlarına bire bir uyması gerektiğini söylemeye gerek yoktur. Çünkü base sınıfta generic tip ile çalıştığımız için ancak reflection yardımı ile property’leri okunabilir. Bunlardan biri yanlış olursa veri tabanına bağlanma ve tabloyu map etme kısımlarında hata çıkabilir. Zaten örnekte map’leme işlemlerini Dapper ile yaptık, eğer bu işlemler için de bir kütüphane kullanmak istemiyorsanız ayrıca bu işlemleri de kendiniz yapmanız gerekir.

Sonuç olarak active record’un veri tabanı ile çok sıkı bir ilişkisi olduğunu görebiliriz . Bir de ben her tablo’nun CRUD işlemleri için ayrı fonksiyonlar yazmak istemiyorum derseniz, belli bir yere kadar soyutlama yapıp sonrasında reflection kütüphanesi ile baya içli dışlı olmak gerekebilir. Bence bu pattern’i uygularken veri tabanının çok değişmemesi gerektiğini göz önünde bulundurarak en baştan her şeyin belirlenmesi ve Database First bir yaklaşım ile projeyi oluşturmaya başlamak işleri daha kolaylaştırabilir.

Demonun linkini buraya bırakıyorum. Teşekkürler.

Kaynaklar

• Patterns of Enterprise Application Architecture, Martin Fowler
• https://www.geekyhacker.com/2019/05/25/my-thoughts-on-active-record-pattern/
• https://karoldabrowski.com/blog/active-record-pattern-or-anti-pattern-overview/
• https://softwareengineering.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles
• The Active Record and Data Mappers of ORM Pattern | by Utpal Biswas | Cybridge Geeks | Medium

Active Record Pattern Nedir ? was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Merhabalar,

Bu yazımda Redux’a nasıl middleware eklenir , neden ihtiyaç vardır, redux-thunk ile api çağrılarımızı nasıl yaparız vb. sorulara cevaplamaya çalışacağım. Redux’ı veya React’ta redux’ın kullanımı ile ilgili anlamadığınız bir nokta varsa önceki yazılarıma göz atmanızı öneririm.

Middleware’e neden ihtiyacımız var ?

Redux’ta bir kuralımız var. Reducer’larımız pure olmalı ve asla side effect yaratacak işlemleri barındırmamalıdır. Bazı durumlarda -hatta çoğu durumda- pure olmayan işlemler yapmak zorunda kalırız. Bu işlemler ; api istekleri, bazı javascript fonksiyonları(math.random, array.push) veya kendi uygulamamızın gerektirdikleri olabilir. İşte tam bu noktada middleware ihtiyacı ortaya çıkıyor. Tabii, bu middleware’ler sadece side effect işlemleri için yoklar. Aynı zamanda state’timizi takip etmek için bazı ekstra araçları da middleware olarak kullanabiliriz.

Bu yazımda 2 tane middleware’den bahsedeceğim.

• redux-thunk
• redux-logger

redux-thunk middleware

Reducer’ın pure kalmasını sağlayan bir kütüphanedir. Side effect işlemlerini bu kütüphaneyi kullanarak yaparız. Çok basit bir işlem yapar. Normalde biz, dispatch kullanarak action’ı reducer’a parametre geçip state’i değiştirirdik. Bu kütüphane ile dispatch fonksiyonuna , action -yani obje - değilde yapacağımız işlemlerin olduğu bir fonksiyon göndeririz. Bu sırada thunk middleware’imiz, gelen parametrenin fonksiyon olup olmadığını kontrol edip fonksiyon ise çalıştırıyor. Fonksiyon içinde dispatch’e tekrar bir action gönderiliyor. Yine aynı şekilde thunk middleware araya girip dispatch’e gönderilen action’ın fonksiyon olup olmadığına bakıyor, eğer fonksiyonsa yine çalıştırıyor.Bu şekilde ,ta ki bir action -obje- yakalayana kadar devam eder. Objeyi yakaladığı an ,reducer’a bu objeyi yani action’ı parametre gönderiyor. Biraz karışık oldu biliyorum. Aşağıda ki flow üzerinden adımları tek tek anlatacağım.

1. Dispatch fonksiyonuna action parametre olarak geçirilir.(action’ın bir fonksiyon olduğunu düşünelim.)
2. Thunk middleware araya girerek, action’ın fonksiyon olup olmadığına bakıyor.
3. Action’ımız fonksiyon olduğu için bu fonksiyona dispatch parametre gönderilip ,fonksiyonumuz, middleware içinde çalıştırılıyor. Fonksiyonumuz , api çağrısını veya ne işlem yapıyorsa o işlemi yapıp bir action-obje- yaratıyor. Parametre olarak gelen dispatch’e de ,yaratılan action parametre verip tekrar çalıştırıyor.
4. Dispatch tekrar çalıştırıldığı için thunk middleware’miz tekrar araya giriyor. Ve bu işlemler yine tekrarlanıyor.
5. Gelen action artık bir obje olduğu için normal yoluna devam ediyor. Yani reducer’a parametre geçiliyor.

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;

export default thunk;

Yukarıdaki kısacık fonksiyon tüm işlemlerimizi yapıyor. Gelen action’ın tipine bakıp fonksiyon ise gerekli parametreleri verip çalıştırıyor, değilse sonraki adıma geçiyor. Fonksiyon olarak gönderdiğimiz action’a, dispatch ve yukarıdaki diğer değerler parametre gönderiliyor.

Fonksiyonumuz dispatch’i kullanmak zorundadır. Aksi halde programımız ilerlemez.

Nasıl Kullanılır ?

Projemize dahil etmek için aşağıdaki komutu çalıştırıyoruz.

npm install redux-thunk

Aşağıda middleware’lerimizi eklemek için redux’ın applyMiddleware fonksiyonundan yararlanıyoruz. createStore fonksiyonunun ikinci parametresine bu fonksiyonu göndererek middleware’lerimizi aktif hale getiriyoruz.

import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import rootReducer from './reducers/index';

const store = createStore(rootReducer, applyMiddleware(thunk));

Örnek

Önceki yazımda,redux’ın react ile kullanımıyla ilgili bir örnek yapmıştım. Redux-thunk’ı da bu örnek üzerinde kullanacağım.

Örneğimiz’de todo’ların başlangıç değerlerini api den çekeceğiz. Bunun için gerçek bir uygulama yapamayacağımızdan, sahte bir api kullanacağız. Böyle durumlarda ve uygulamalarımızı denemek için geliştirilen bir kütüphane var json-server. Bizde bu kütüphaneyi kullanacağız.

json-server kurulumu

npm install -g json-server

Yukarıdaki komutu çalıştırarak bilgisayarımıza kuruyoruz.

Bu işlemden sonra api’den çekeceğimiz verileri db adında bir json dosyasına yazıyoruz.

db.json

{
   "todos": [
              {"todo": "todos1"},
              {"todo": "todos2"},
              {"todo": "todos3"}
            ]
}

db.json dosyamız nerede ise oranın path’ini yazarak aşağıdaki komutu çalıştırıyoruz.

json-server --watch db.json

dosyamız, proje klasörümüzün içinde ise bir yol belirtmemize gerek yok. Başka bir yerde ise dosyanın tam yolunu vererek komutu çalıştırmalıyız. Bu işlemlerden sonra todolarımız “localhost:3000/todos” endpoint’inde görüntülenecektir. Başka endpoint’lerde ekleyebiliriz. Bu kütüphanenin bir çok özelliği vardır incelemek için github adresine gidebilirsiniz.

Redux-thunk’ın kurulumunu yaptığınızı varsayıyorum.Yapmadıysanız yukarıda nasıl yapıldığını anlattım.

Bu state için öncelikle ,yeni bir action ve reducer’a yeni bir case eklemeliyiz.

src/redux/actions/actionTypes.js

src/redux/reducers/todoReducer.js

src/redux/actions/thunkActions.js

Api isteği yapan fonksiyonlarımızı tutacak bir dosya oluşturuyoruz. Direkt actionCreators.js dosyamıza da ekleyebiliriz ama daha modüler ve uygulama daha kompleks hale gelmesin diye ayrı bir dosyada yapmak daha mantıklıdır. Ben burada daha genel bir dosya oluşturdum ama çoğu gerçek hayat projelerinde, yaptığı işlemlere göre bu fonksiyonlar gruplandırılıp ayrı dosyalarda tutulur.

İsteğimizi yaptıktan sonra ,gelen datayı kullanarak bir action oluşturup dispatch metoduna parametre geçiyoruz. Bu işlemden de sonra, thunk middleware tekrar devreye girerek ,gelen action’ı kontrol edip obje ise reducer’a parametre geçiyor.

Bu fonksiyonu TodoSearch Component’inde kullanacağız. Component, ilk render işleminde bu verileri default olarak gösterecek. İlk render işleminde çalışacak fonksiyonu(getTodosApiRequest) ,react'ın lifecycle metotlarından olan componentDidMount fonksiyonunu kullanarak kullanacağız.

src/components/TodoSearch.js

mapDispatchToProps fonksiyonunda component ilk render olduğunda tetiklenecek action’ı tanımladık. Action’ın olduğu dosyayı component’imizde import etmeyi unutmamalıyız(5.satırda). Action’ı ,Component ilk render işleminden hemen önce çalıştırmak için componentDidMount fonksiyonundan faydalanıyoruz(12.satırda). Bu sayede uygulamamız ilk açıldığında, api’den gelen 3 tane todo’yu -db.json dosyasında bu kadar verdik.- default olarak gösterecek.

redux-logger middleware

State her değiştiğinde; hangi action’ın çalıştığı, önceki state’in ve değiştikten sonraki state’in son halini konsola yazar. Bu sayede kullanıcının ne yaptığı an an takip edilebilir.

Nasıl Kullanılır ?

Projemize dahil etmek için aşağıdaki komutu çalıştırıyoruz.

npm i --save redux-logger

Yine aynı şekilde applyMiddleware fonksiyonu ile logger midleware’mizi createStore fonksiyonuna parametre geçiyoruz.

import { applyMiddleware, createStore } from 'redux';
import logger from 'redux-logger'
import rootReducer from './reducers/index';

const store = createStore(rootReducer,applyMiddleware(logger))

Örneğe buradan ulaşabilirsiniz.

Redux ile ilgili yazılarımın sonuna geldik. Umarım faydalı olmuştur. Görüşmek üzere.

React’ta redux ile middleware kullanımı ve redux-thunk. was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Merhaba Arkadaşlar,

Önceki yazımda redux’ın ne olduğunu,çalışma mantığını anlatmaya çalıştım. O yazıma buradan ulaşabilirsiniz.

Bu yazımda ise react’a redux’ı nasıl kullanacağız, neden ihtiyacımız var vb. soruları cevaplamaya çalışacağım.

React’a redux’a neden ihtiyacımız var ?

React’ta component’ler sürekli bir biri ile etkileşim içindedir. Bunun nedeni bir birinin state’ini kullanmalarıdır. Örneğin bir sayfanın navbar’ında login olan kişinin ismini gösteriyoruz. Bu isim, navbar component’inin state’dir. Daha sonra kişinin profil sayfasına gittiğimizde orada da ismini görürüz. Bu ismi öğrenmek için, her seferinde servisimize istek atmak çok kullanışlı olmayacağından, bu isim bilgisini tutan component’ten bilgiyi almak ,daha hızlı ve efektif olacaktır. Bu olaya component drilling adı verilir.

Bu durum bir kaç sorunu beraberinde getiriyor. Bunlardan ilki bir component’in durum bilgisine ihtiyaç varsa bu bilgi her zaman üst katmandan gelmek zorundadır. Bu durumda bu bilgi için her zaman üst katmanlara bağımlı olacağız. İkincisi ise , component sayıları arttıkça paralel olan component’ler bir birinin state’ine ihtiyaç duyduğu zaman ; state’i, bir birine direkt göndermeyecekleri için bu durum ikisininde atası olan bir component’te state‘i tutmaya itecektir. Her zaman state’i merkezileştirme gibi bir yapıya gidilecektir.

Redux’ın buna sağladığı çok basit bir çözümü vardır. State’leri store adında bir yapıda tutar. Tüm component’ler bu store’ bağlıdır. Bir component ,state ile ilgili bir işlem yaparsa ,store’un ilgili state’ine abone olan componen’tler otomatik kendini güncelliyor. Bu sayede tüm component’ler tek bir yapıyla muhatap olduğu için daha yönetilebilir bir state oluyor.

Nasıl kullanılır ?

Öncelikle iki tane kütüphaneye ihtiyacımız var redux ve react-redux.

Bunları indirmek için aşağıdaki komutları kullanıyoruz.

npm install redux
npm install react-redux
//tabii siz hangi paket yönetim aracını kullanıyorsanız ona göre indirin.

Reducer oluşturma.

Store’umuz tek bir state’i tutmayacağı için reducer’larımız da birden fazla olacaktır. Her bir reducer store’un ilgili state’i ile işlem yapacaktır.

Bu state’lere hem başlangıç değerlerini vermek hemde reducer’ların ilgileneceği state’i belirtmek için initialState.js adında bir dosya oluşturuyoruz.

örnek initialState dosyası

 export default {
        categories:[],
        currentCategory: {}
}

örnek reducer dosyası

import * as actionTypes from "../actions/actionTypes"
import initialState from "./initialState";

export default function changeCategoryReducer(state = initialState.currentCategory, action) {

     switch (action.type) {
            case actionTypes.CHANGE_CATEGORY:
                return action.payload
            default:
                return state;
    }

}

Dikkat ederseniz reducer, initialState’tin sadece ilgili state’ini değiştiriyor.

Store oluşturma.

createStore fonksiyonunu kullanarak store’umuzu oluşturuyoruz.

import { createStore } from "redux";
import reducer from "./reducer";

const store = createStore(reducer);

Reducer’larımız birden fazla ise redux’ın combineReducers fonksiyonunu kullanabiliriz.

import { createStore,combineReducers } from "redux";
import reducer1 from "./reducer1";
import reducer2 from "./reducer2";

const reducers = combineReducers({
         reducer1,
         reducer2
});
const store = createStore(reducers);

createStore fonksiyonu geriye bir obje dönüyor.

• dispatch: reducer’ı tetikleyen fonksiyon. Bu fonksiyonu doğrudan kullanmayız. Bu işlemi react-redux kütüphanesi ile gerçekleştiririz.
• getState: mevcut state’ti dönen fonksyion. Spesifik olarak bir state dönmez. Reducer’da kullanılan state’leri döner.
• replaceReducer: adından da anlaşılacağı gibi mevcut reducer’ları, parametre olarak geçilen reducer’larla değiştirir. Örneğin aynı state üzerinde farklı işlemler yapan iki reducer’imiz varsa, bazı durumlarda bu iki reducer’i değiştirmek isteyebiliriz.
• subscribe: component’leri bu fonksyion ile abone ederiz. Bu fonksiyonu da doğrudan kullanmayız. React-redux kütüphanesinin metotları ile bunu gerçekleştiririz.

Provider

Store’umuzu component’ler de kullanmak için bu nesne ile uygulamamızı sarmalıyoruz. Parametre olarak store’u veriyoruz.

import { Provider } from 'react-redux';
import { createStore,combineReducers } from "redux";
import reducer1 from "./reducer1";
import reducer2 from "./reducer2";

const reducers = combineReducers({
         reducer1,
         reducer2
});

const store = createStore(reducers);

ReactDOM.render(<Provider store={store}><App /></Provider>, document.getElementById('root'));

Connect

Component’leri state bağlayarak “this.props” üzerinden state ve action’lara erişim sağlamak için kullanılır.

import { connect } from "react-redux";
import { bindActionCreators } from 'redux'
import { action1 } from "../redux/actions"

class Component1 extends Component {

    render() {
           return (

             <div>
                 <h1>{this.props.state1}</h1>
                 <button onClick={this.props.action1}>click</button>

             </div>

           )
        }
}
function mapStateToProps(state) {
      return { state1: state.reducer1
               state2: state.reducer2 
            }
}

function mapDispatchToProps(dispatch) {
      return { 
              action1: bindActionCreators(action1, dispatch)
              //action1: ()=> dispatch(action1())
             }
}

export default connect(mapStateToProps,mapDispatchToProps)(Component1);

mapStateToProps: bu fonksiyon ile state’imize , direkt “this.props” üzerinden ulaşabiliyoruz. this.props.state1 bu fonksiyona parametre olarak gelen state üzerinden , erişmek istediğimiz state’i hangi reducer değiştiriyorsa onu kullanmalıyız. Örneğin reducer1 state1'i değiştirip geriye yeni bir state1 döndüğü için parametre olarak gelen state üzerinden reducer1'i çağırmalıyız state.reducer1.

mapDispatchToProps: dispatch’i props üzerinden tetiklemek için kullanılır.

bindActionCreators: bu fonksiyon , verilen parametrelere göre bir tetiklemeye hazır bir action yaratıyor. Yaptığı işlem buna eşdeğerdir. dispatch(action1())

Component’i bağlamak için en sonda component’i ,parametre olarak vermeliyi unutmamalıyız.

Örnek

Örnek olarak bir todo uygulaması yapacağız. Basit bir şekilde ekleme , silme ve arama işlemleri olacak.

Öncelikle aşağıdaki komut ile “redux-example” adında bir react projesi oluşturuyoruz. Sonrasında redux ve react-redux kütüphanelerini yüklüyoruz.

npx create-react-app redux-example
npm install redux
npm install react-redux

Uygulamamızın görünümü için reactstarp ve bootstrap kullanacağız. Bu kütüphanelerin yükleme komutları da aşağıdadır.

npm install --save bootstrap
npm install --save reactstrap react react-dom

Css’lerin etki etmesi için index.js dosyamıza bootstrap css dosyasını import etmemiz gerekir.

import 'bootstrap/dist/css/bootstrap.min.css';

Kütüphanelerimizi yükledikten sonra, src dosyamıza redux adında bir klasör oluşturuyoruz. Bu klasöre action’ larımız ile ilgili dosyalar koymak için actions , reducer’larımız için reducers adında iki klasör daha açıyoruz.

src/redux/actions/actionTypes.js

Bu dosyada todo’larımız üzerinde yapacağımız işlemlerin tiplerini belirliyoruz.

src/redux/actions/actionCreators.js

Action’ları tek tek üretmek zor ve mantıksız olacağından actionCreator’lardan faydalanırız. Verdiğimiz parametreye göre action’larımız hızlı bir şekilde üretecek.

src/redux/initialState.js

Reducer’a state’in,başlangıç değerlerini ve state tiplerini belirtmek için bu dosyaya gerekli bilgileri veriyoruz.

todos: Tüm todolarımızı tutatacak array .

filterTodos: todos üzerinde yaptığı arama sonuçlarını tutacak array. Bunu ayrı olarak yapmaktaki amaç; bir filtre işleminde todo’ları silmemek içindir.

src/redux/reducers/todoReducer.js

Gelen action tipine göre ekleme silme ve arama işlemlerini gerçekleştiriyoruz.

Dikkat ederseniz her zaman yeni bir obje dönüyorum. Mutlaka objenin referansını değiştirmek zorundayız.

• TODO_ADD: eski state’ti bir array’e kopyalayıp(Object spread opretaor) gelen todo’yu kopyalanan array’e ekliyorum.
• TODO_REMOVE: gelen todo hariç tüm todo’ları yeni bir array olarak dönüyorum.
• TODO_SEARCH: yine “action.payload” tan gelen değere göre arama yapıp filtre sonucunu “state.filterTodos” a set ediyorum.

Tüm case’lerde initialStat’e uygun bir obje dönmek zorundayız.Eğer reducer’ımız başka bir state üzerinde çalışsaydı, ona uygun dönülecekti.

src/redux/index.js

Bu dosyada reducer’larımızı combine ediyoruz. Bunun sonucunu createStore fonksiyonuna parametre geçeceğiz. Şimdilik bir tane reducer’ımız olduğu için onu gönderiyoruz.

src/redux/configureStore.js

İndex dosyasından gelen reducer’ları burada ,configureStore fonksiyonunda , createStore fonksiyonuna parametre veriyoruz. Bu kısımda middleware’lerimizi de ekleyebiliriz.

src/index.js

Store’umuzu oluşturduktan sonra uygulamamızı Provider nesnesi ile sarmallayıp store’u parametre olarak gönderiyoruz.

src/components/TodoAdd.js

mapDispatchToProps metodunda ekleme action’ını tanımladık. State ile bir işimiz olmadığı için connect fonksiyonunun ilk parametresini null geçtik.

Component’imiz çok basit bir işlem yapıyor. İnput’ta yapılan her değişkliği component’in state’inde tanımlanan todo değişkenine set ediyor. Butona tıklandığı zaman da bu değeri ,add action’ını kullanarak parametre geçiyor. Bu işlem sonucunda arka tarafta ,dispatch metodumuz action’ı reducer’ımıza parametre geçerek ilgili işlemi yapıyor.

src/components/TodoSearch.js

Bu component’in state’inde aranan değeri tutuyoruz. Bu aranan değer input’ta ,her değiştiğinde bir action tetikleniyor. Bu işlemden sonra reducer’ımızda filtreleme işlemi gerçekleşerek olası sonuçlar filterTodos state’ine set ediliyor. Eğer aranan değer boş ise tüm todo’ları değilse -demek ki aranan bir değer var- filtre sonucunu TodoList component’ine gönderiyoruz.

src/components/TodoList.js

Bu component’te ise parent component’ten gelen todo’ları map fonksiyonu ile gösteriyoruz. Bir todo’nun silinme işlemini yine ekleme işlemi gibi bir butona bağlıyoruz. Bu butona tıklandığında ilgili todo ile beraber action fırlatılıyor. Reducer’a giden action TODO_REMOVE case’ine düştükten sonra filtreleme işlemi yapılarak yeni state geri dönülüyor. State değiştiği için todos state’ine abone olan tüm component’ler kendini render ediyor.

Bu uygulamada ,hem redux hemde component diriling yöntemlerini kullanarak state’lerimizi yönettik. TodoSearch component’inden TodoList component’ine ,todos state’ini parametre geçerek component diriling yöntemini, todos state’ini redux mağazasından TodoSearch component’imize göndererek redux store yöntemini kullandık.

Örneğe buradan ulaşabilirsiniz.

Sonraki yazımda redux middleware’lerini , redux-thunk ile asenkron işlemleri anlatacağım. Görüşmek üzere.

React’ta redux nasıl ve neden kullanılır ? was originally published in SDTR on Medium, where people are continuing the conversation by highlighting and responding to this story.