In the previous blog, we explored ReplicaSets and their importance in maintaining multiple identical pods for high application availability. However, in Kubernetes, we typically don't create ReplicaSets directly. Instead, we create higher-level objects such as Deployments, DaemonSets, or StatefulSets, which in turn manage ReplicaSets for us. In this blog, we'll delve into Deployments

Deployments are a crucial higher-level resource in Kubernetes, designed to manage the deployment and scaling of ReplicaSets, ensuring applications are always running in the desired state. We describe the desired state in the deployment configuration, and then the Deployment controller works to make the current state match the desired state.

Difference Between Deployments and ReplicaSets

Deployments and ReplicaSets have different roles in Kubernetes. A ReplicaSet ensures a specified number of pod replicas are always running, but it lacks advanced update features. Deployments, however, allow for easy updates and rollbacks for pods and ReplicaSets. They support rolling updates and rollbacks. While ReplicaSets keep the right number of pods running, Deployments help manage application lifecycles, updates, and scaling without downtime, making them the better choice for managing stateless applications in Kubernetes.

Configuring a Deployment

Configuring a Deployment involves defining a YAML file that specifies the desired state of the application. This includes details such as the application's image, the number of replicas, any necessary secrets and ConfigMaps, and a strategy for updating the application, ensuring smooth transitions with minimal downtime. Once the configuration file is applied, the Deployment controller works to ensure that the actual state matches the desired state.

Below is a sample YAML configuration for a Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Breakdown of the YAML File

When writing any object in Kubernetes, you need to include certain required fields: apiVersion, kind, metadata, and spec.

1. apiVersion:

    apiVersion: apps/v1
   

   This field specifies the version of the Kubernetes API that your object adheres to, ensuring compatibility with your Kubernetes cluster. In this case, it uses apps/v1.

2. kind:

    kind: Deployment
   

   This field defines the type of Kubernetes object being created. In our YAML file, it indicates that we are creating a Deployment.

3. metadata:

    metadata:
      name: nginx-deployment
      labels:
        app: nginx
   

   This section provides essential information about the Deployment:

   • name: This uniquely identifies the Deployment within its namespace (nginx-deployment). This is the only required field in metadata.

   • labels: Key-value pairs used to organize and select resources (app: nginx).

4. spec:

    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:latest
            ports:
            - containerPort: 80
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxUnavailable: 1
          maxSurge: 1
   

   The spec section defines the desired state of the Deployment, including its pods and their configurations:

   • replicas: Specifies the number of pod replicas that the Deployment should maintain (3 in this case).

   • selector: Defines how the Deployment identifies the pods it manages.

     • matchLabels: A set of key-value pairs used to match the pods (app: nginx). This should be the same as the labels in template.metadata.labels.

   • template: Describes the pod's configuration to be created.

     • metadata: Includes labels to be applied to the pods.

     • spec: Defines the pod's configuration.

       • containers: Lists the containers within the pod.

         • name: Identifies the container (nginx).

         • image: Specifies the Docker image to use (nginx:latest).

         • ports: Indicates which ports should be exposed by the container (containerPort: 80).

   • strategy: Defines the strategy for updating the Deployment.

     • type: Specifies the update strategy. In this case, it is RollingUpdate, which updates pods in a rolling fashion with minimal downtime.

     • rollingUpdate: Specifies parameters for the rolling update strategy, such as maxUnavailable and maxSurge.

Creating a Deployment

To create a Deployment using the above YAML configuration, save the configuration to a file named nginx-deployment.yaml and apply it to the Kubernetes cluster using the following command:

kubectl apply -f nginx-deployment.yaml

Managing a Deployment

You can list the Deployments using the kubectl get deployments command:

kubectl get deployments

Output:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           10s

You can use the kubectl describe command to check the state of the Deployment:

❯ kubectl describe deployments.apps/nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Mon, 15 Jul 2024 20:04:25 +0530
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-57d84f57dc (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  54s   deployment-controller  Scaled up replica set nginx-deployment-57d84f57dc to 3

List the ReplicaSets:

❯ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-57d84f57dc   3         3         3       93s

List the pods:

❯ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-57d84f57dc-w5n9r   1/1     Running   0          2m11s
nginx-deployment-57d84f57dc-8mf7x   1/1     Running   0          2m11s
nginx-deployment-57d84f57dc-gv24t   1/1     Running   0          2m11s

Scaling the Deployment

You can scale the Deployment to a different number of replicas using the kubectl scale command:

❯ kubectl scale --replicas=5 deployment nginx-deployment
deployment.apps/nginx-deployment scaled

❯ kubectl get deployments
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   5/5     5            5           4m11s

❯ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-57d84f57dc-w5n9r   1/1     Running   0          4m24s
nginx-deployment-57d84f57dc-8mf7x   1/1     Running   0          4m24s
nginx-deployment-57d84f57dc-gv24t   1/1     Running   0          4m24s
nginx-deployment-57d84f57dc-9gjph   1/1     Running   0          27s
nginx-deployment-57d84f57dc-t47qd   1/1     Running   0          27s

Deleting the Deployment

To delete the Deployment, use the following command:

kubectl delete deployment nginx-deployment

Deleting the Deployment will terminate all the pods it manages. If you want to keep the pods running after deleting the Deployment, use the --cascade=orphan flag:

kubectl delete deployment nginx-deployment --cascade=orphan

Conclusion

In summary, Deployments play a crucial role in managing the desired state of your applications by ensuring a specified number of pod replicas are running at all times. This not only enhances the availability and reliability of your applications but also simplifies the management of pods in a Kubernetes environment.

By defining a Deployment through a YAML file, you can easily control the number of replicas, monitor their status, and scale them as needed, ensuring your applications remain resilient and performant.

Thank you for reading this blog; your interest is greatly appreciated. I hope this information helps you on your Kubernetes journey. In the next part, we'll explore updating and rolling back Kubernetes deployments.

In the last blog, we explored Pods and how they encapsulate containers to run workloads on Kubernetes. While Pods provide useful features for running workloads, they also have inherent issues due to their ephemeral nature—they can be terminated at any time. When this happens, the user application will no longer be available.

To avoid such situations and ensure the user application is always available, Kubernetes uses ReplicaSets (RS). A ReplicaSet creates multiple identical replicas of a pod and ensures a specific number of pods are running at all times—neither fewer nor more.

A ReplicaSet controller continuously monitors the pods to ensure that the number of desired pods equals the number of available pods at all times. If a pod fails, the ReplicaSet automatically creates more pods. Conversely, if new pods with the same label are added and there are more pods than needed, the ReplicaSet will reduce the number by stopping the extra pods.

Configuring a ReplicaSet

Configuring a ReplicaSet involves defining a YAML file that specifies the desired state for the ReplicaSet. This YAML file includes crucial details such as the number of replicas, the selector to identify the pods managed by the ReplicaSet, and the pod template that defines the pods to be created.

Below is a sample YAML configuration for a ReplicaSet using an Nginx container:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
  labels:
    app: nginx-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-pods
  template:
    metadata:
      labels:
        app: nginx-pods
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Breakdown of the YAML File

When writing any object in Kubernetes, you need to include certain required fields: apiVersion, kind, metadata, and spec.

1. apiVersion:

    apiVersion: apps/v1
   

   This field specifies the version of the Kubernetes API that your object adheres to, ensuring compatibility with your Kubernetes cluster. In this case, it uses apps/v1.

2. kind:

    kind: ReplicaSet
   

   This field defines the type of Kubernetes object being created. In our YAML file, it indicates that we are creating a ReplicaSet.

3. metadata:

    metadata:
      name: nginx-replicaset
      labels:
        app: nginx-rs
   

   This section provides essential information about the ReplicaSet:

   • name: This uniquely identifies the ReplicaSet within its namespace (nginx-replicaset). This is the only field in metadata that is required.

   • namespace: Assigns a specific namespace for resource isolation (optional).

   • labels: Key-value pairs used to organize and select resources (app: nginx-rs).

   • annotations: These key-value pairs offer additional details about the Pod, useful for documentation, debugging, or monitoring (optional).

   • ownerReferences: Specifies the controller managing the Pod, establishing a relationship hierarchy among Kubernetes resources (optional).

4. spec:

    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx-pods
      template:
        metadata:
          labels:
            app: nginx-pods
        spec:
          containers:
          - name: nginx
            image: nginx:latest
            ports:
            - containerPort: 80
   

   The spec section defines the desired state of the ReplicaSet, including its pods and their configurations:

   • replicas: Specifies the number of pod replicas that the ReplicaSet should maintain (3 in this case).

   • selector: Defines how the ReplicaSet identifies the pods it manages.

     • matchLabels: A set of key-value pairs used to match the pods (app: nginx-pods). This should be the same as the labels in template.metadata.labels.

     • template: Describes the pod's configuration to be created.

       • metadata: Includes labels to be applied to the pods.

       • spec: Defines the pod's configuration.

         • containers: Lists the containers within the pod.

           • name: Identifies the container (nginx).

           • image: Specifies the Docker image to use (nginx:latest).

           • ports: Indicates which ports should be exposed by the container (containerPort: 80).

Additional optional fields for advanced configurations within the spec section include:

• resources: Manages the pod's resource requests and limits.

• volumeMounts: Specifies volumes to be mounted into the container's filesystem.

• env: Defines environment variables accessible to the container.

• volumes: Describes persistent storage volumes available to the pod.

Creating a ReplicaSet

To create a ReplicaSet using the above YAML configuration, save the configuration to a file named nginx-replicaset.yaml and apply it to the Kubernetes cluster using the following command:

kubectl apply -f nginx-replicaset.yaml

Managing ReplicaSet

You can list the replica sets using kubectl get replicaset command.

❯ kubectl get replicasets
NAME               DESIRED   CURRENT   READY   AGE
nginx-replicaset   3         3         3       2m17s

You can use the kubectl describe command to check the state of the replica set.

❯ kubectl describe replicasets.apps/nginx-replicaset
Name:         nginx-replicaset
Namespace:    default
Selector:     app=nginx-pods
Labels:       app=nginx-rs
Annotations:  <none>
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=nginx-pods
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  13s   replicaset-controller  Created pod: nginx-replicaset-rgxzx
  Normal  SuccessfulCreate  13s   replicaset-controller  Created pod: nginx-replicaset-prddh
  Normal  SuccessfulCreate  13s   replicaset-controller  Created pod: nginx-replicaset-rwvpn

You can list the pods using kubectl get pods command.

❯ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-replicaset-xqcjm   1/1     Running   0          10s
nginx-replicaset-pzzhh   1/1     Running   0          10s
nginx-replicaset-k4lp4   1/1     Running   0          10s/

Scaling the ReplicaSet

You can scale the ReplicaSet to a different number of replicas using the kubectl scale command:

❯ kubectl scale --replicas=5 replicaset nginx-replicaset
replicaset.apps/nginx-replicaset scaled

❯ kubectl get replicasets
NAME               DESIRED   CURRENT   READY   AGE
nginx-replicaset   5         5         3       17m

❯ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-replicaset-xqcjm   1/1     Running   0          17m
nginx-replicaset-pzzhh   1/1     Running   0          17m
nginx-replicaset-k4lp4   1/1     Running   0          17m
nginx-replicaset-79d96   1/1     Running   0          16s
nginx-replicaset-sdb5g   1/1     Running   0          16s

Updating the ReplicaSet

To update the ReplicaSet, such as changing the container image, you can modify the YAML file and apply the changes using:

kubectl apply -f nginx-replicaset.yaml

Alternatively, use the kubectl set image command to update the image directly:

kubectl set image replicaset/nginx-replicaset nginx=nginx:1.19

Deleting the ReplicaSet

To delete the ReplicaSet, use the following command:

kubectl delete rs nginx-replicaset

Deleting the ReplicaSet will terminate all the pods it manages. If you want to keep the pods running after deleting the ReplicaSet, use the --cascade=orphan flag:

kubectl delete rs nginx-replicaset --cascade=orphan

Scenarios where RS are useful

1. High Availability: ReplicaSets ensure that a specified number of pod replicas are always running, which is crucial for applications requiring high availability.

2. Load Balancing: By maintaining multiple replicas of a pod, ReplicaSets help distribute the load evenly across all replicas, improving performance and reliability.

3. Fault Tolerance: If a pod fails, the ReplicaSet automatically replaces it, ensuring continuous availability of the application.

4. Rolling Updates: ReplicaSets can be used to perform rolling updates to applications, allowing updates without downtime by incrementally replacing old pods with new ones.

5. Scalability: Easily scale the number of pod replicas up or down based on demand, ensuring efficient use of resources.

Conclusion

In summary, ReplicaSets play a crucial role in maintaining the desired state of your applications by ensuring a specified number of pod replicas are running at all times. This not only enhances the availability and reliability of your applications but also simplifies the management of pods in a Kubernetes environment.

Benefits of Using ReplicaSets:

• Enhanced Reliability: Ensures continuous application availability by maintaining multiple pod replicas.

• Improved Uptime: Automatically replaces failed pods to maintain the desired number of running pods.

• Simplified Scaling: Allows easy scaling of applications by adjusting the number of replicas.

• Consistent Performance: Distributes the load evenly across replicas, maintaining application performance.

By defining a ReplicaSet through a YAML file, you can easily control the number of replicas, monitor their status, and scale them as needed, ensuring your applications remain resilient and performant.

Thank you for reading this blog; your interest is greatly appreciated. I hope this information helps you on your Kubernetes journey. In the next blog, we'll explore Kubernetes deployments.

With Kubernetes, our main goal is to run our application in a container. However, Kubernetes does not run the container directly on the cluster. Instead, it creates a Pod that encapsulates the container.

A Pod is the smallest object that you create and manage in Kubernetes. A Pod consists of one or more containers that share storage and network resources, all running within a shared context. This shared context includes Linux namespaces, cgroups, and other isolation mechanisms, similar to those used for individual containers.

In a Kubernetes cluster, Pods use two models to run containers.:

1. One-container-per-Pod model: This is the common use case in Kubernetes. A Pod acts as a wrapper for a container, with Kubernetes managing the Pod instead of the individual container. Refer to diagram POD-A.

2. Multi-containers Pod model: Pods can run multiple containers that work closely together. These Pods hold applications made up of several containers that need to share resources and work closely. These containers operate as a single unit within the Pod. Refer to diagram POD-B.

Anatomy of a Pod

Containers

Main Container

• Primary Role: This is the application's primary container.

• Example: If you have a web application, the main container will run the web server that serves your application.

Sidecar Containers

• Supporting Role: These auxiliary containers support the main container, often used for logging, monitoring, or proxying tasks.

• Example: For the same web application, a sidecar container might handle logging by collecting and storing log data generated by the web server.

Storage (Volumes)

Pods can include storage resources known as volumes, which enable data persistence across container restarts. Volumes in a Pod are shared among all containers in that Pod, allowing for data exchange between them.

• Types of Volumes:

  • emptyDir: A temporary directory that is created when a Pod is assigned to a node and deleted when the Pod is removed.

  • hostPath: Maps a file or directory from the host node’s filesystem into a Pod.

  • persistentVolumeClaim: A request for storage by a user that binds to a PersistentVolume (PV) in the cluster.

  • configMap: Provides configuration data, command-line arguments, environment variables, or container files.

  • secret: Used to store sensitive data such as passwords, OAuth tokens, and SSH keys.

Network

Each Pod is assigned a unique IP address. Containers within the same Pod share the network namespace, which means they can communicate with each other using localhost. Pods can communicate with each other using their assigned IP addresses.

• Pod IP: A unique IP address assigned to each Pod.

• DNS: Kubernetes automatically assigns DNS names to Pods and services, facilitating network communication within the cluster.

Pod Lifecycle

Like individual application containers, Pods are considered to be relatively temporary (rather than permanent) entities. Understanding the lifecycle of a Pod is crucial for effective management and troubleshooting.

Pods can be in one of several phases during their lifecycle. A Pod's status field is a PodStatus object, which has a phase field. The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle.

• Pending: The Pod has been accepted by the Kubernetes system but one or more container images have not been created.

• Running: The Pod has been bound to a node, and all of the containers have been created. At least one container is still running or is in the process of starting or restarting.

• Succeeded: All containers in the Pod have terminated successfully, and the Pod will not be restarted.

• Failed: All containers in the Pod have terminated, and at least one container has terminated in failure.

• Unknown: The state of the Pod cannot be obtained, typically due to an error in communicating with the node where the Pod resides.

Pod Conditions

Pods have a set of conditions that describe their current state. These conditions are used to diagnose and troubleshoot the status of Pods.

• PodScheduled: Indicates whether the Pod has been scheduled to a node.

• Initialized: All init containers have been completed successfully.

• Ready: The Pod can serve requests and should be added to the load-balancer pools of all matching Services.

• ContainersReady: All containers in the Pod are ready.

• PodReadyToStartContainers: (beta feature; enabled by default) The Pod sandbox has been successfully created and networking configured.

Pod creation

A Pod can be created using two methods. The first method is by using the kubectl run command.

kubectl run --image nginx nginx-pod

The second method is declarative. In this approach, you create a Pod configuration file in YAML and apply it using the kubectl create or kubectl apply command. This method is widely used because it allows you to manage multiple versions of an application easily.

Create a configuration file named nginx-pod.yaml with the following content.

apiVersion: 
kind: 
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

kubectl apply -f nginx-pod.yaml

You can list the pods using kubectl get pods command.

❯ kubectl get pods
NAME        READY   STATUS    RESTARTS      AGE
nginx-pod   1/1     Running   0             5s

Let's break down the Pod manifest

When writing any object in Kubernetes, you need to include certain required fields: apiVersion, kind, metadata, and spec.

apiVersion

This field specifies the version of the Kubernetes API that your object adheres to, ensuring compatibility with your Kubernetes cluster (e.g., v1).

kind

This field defines the type of Kubernetes object being created. In our YAML file, it indicates that we are creating a Pod.

metadata

This section provides essential information about the Pod:

• name: This uniquely identifies the Pod within its namespace (e.g., nginx-pod).

• namespace: Assigns a specific namespace to the Pod for resource isolation.

• labels: These are key-value pairs used to organize and select resources (e.g., app: nginx).

• annotations: These key-value pairs offer additional details about the Pod, useful for documentation, debugging, or monitoring.

• ownerReferences: Specifies the controller managing the Pod, establishing a relationship hierarchy among Kubernetes resources.

spec

The spec section defines the desired state of the Pod, including its containers and their configurations:

• containers: This list defines each container within the Pod.

  • name: Identifies the container (e.g., nginx-container).

  • image: Specifies the Docker image to use (e.g., nginx:latest).

  • ports: Indicates which ports should be exposed by the container (e.g., port 80).

Additional Optional Fields: For more advanced setups, you can include additional fields within the spec section:

• resources: Manages the Pod's resource requests and limits.

• volumeMounts: Specifies volumes to be mounted into the container's filesystem.

• env: Defines environment variables accessible to the container.

• volumes: Describes persistent storage volumes available to the Pod.

Static pods

In Kubernetes, Static Pods offer a way to directly manage Pods on a node without the need for the Kubernetes control plane. Unlike regular Pods that are managed by the Kubernetes API server, Static Pods are managed directly by the Kubelet daemon on a specific node.

How Static Pods Work

Static Pods are defined by creating Pod manifest files on the node itself. These manifest files are usually located in a directory monitored by the Kubelet, such as /etc/kubernetes/manifests, or a directory specified in the Kubelet's configuration (kubelet.conf).

Key Characteristics of Static Pods

1. Node-Specific Management: Each node runs its instance of the Kubelet, which monitors a designated directory for Pod manifests. When a manifest file is detected or updated, the Kubelet creates, updates, or deletes the corresponding Pod on that node.

2. No Kubernetes API Interaction: Unlike regular Pods that are part of the Kubernetes API and etcd datastore, Static Pods are not managed via the API server. They do not appear in Kubernetes API responses and are not visible through tools like kubectl.

3. Use Cases: Static Pods are useful in scenarios where Pods need to run directly on a node, independent of the Kubernetes control plane. This can include bootstrapping components required for Kubernetes itself, or running critical system daemons that must be available even if the control plane is offline.

Creating Static Pods

To create a Static Pod:

• Create a Manifest File: Write a Pod manifest YAML file specifying the Pod's metadata and spec, similar to how you define regular Pods.

• Place in Watched Directory: Save the manifest file in the directory monitored by the Kubelet (/etc/kubernetes/manifests by default). This directory can be configured in the Kubelet configuration file by setting staticPodPath to the pod manifests path. Alternatively, it can also be passed to Kubelet through the --pod-manifest-path flag, but this flag is deprecated.

• If needed restart the kubelet:

    systemctl restart kubelet
  

Static Pods in Kubernetes are managed directly by the Kubelet and are automatically restarted if they fail. The Kubelet ensures that each Static Pod's state aligns with its specified manifest file. Despite this direct management, Kubelet also attempts to create a mirror Pod on the API server for each Static Pod. This makes the static pod visible to the API server, however, the API server cannot control the pod.

Conclusion

Pods are the core units in Kubernetes, encapsulating containers with shared storage and network resources. They can run single or multiple containers, providing flexibility in application deployment. Understanding Pods' anatomy, lifecycle, and creation methods, including static Pods, is crucial for efficient and scalable application management in Kubernetes environments.

Pods in Kubernetes are inherently ephemeral and can be terminated at any time. Kubernetes uses controllers to effectively manage Pods, ensuring their desired state is maintained. ReplicationSet controllers ensure a specified number of Pod replicas are running. Other controllers like Deployments, StatefulSets, and DaemonSets cater to different use cases.

Thank you for reading this blog; your interest is greatly appreciated, and I hope it helps you on your Kubernetes journey. In the next blog, we'll explore Kubernetes controllers that are used to manage Pods.

Kubeadm is a tool designed to simplify the process of creating Kubernetes clusters by providing kubeadm init and kubeadm join commands as best-practice "fast paths." - Kubernetes documentation

In this blog, we'll go through the step-by-step process of installing a Kubernetes cluster using Kubeadm.

Prerequisites

Before you begin, ensure you have the following:

1. Ensure you have a compatible Linux host (e.g., Debian-based and Red Hat-based distributions). In this blog, we're using Ubuntu which is a Debian-based OS.

2. At least 2 GB of RAM and 2 CPUs per machine.

3. Full network connectivity between all machines in the cluster.

4. Unique hostname, MAC address, and product_uuid for every node.

5. Ensure all the required ports are open for the control plane and the worker nodes. You can refer to Ports and Protocols or see the screenshot below.

   

Disable swap on all the nodes.

sudo swapoff -a
# disable swap on startup in /etc/fstab
sudo sed -i '/ swap / s/^/#/' /etc/fstab

Setup container runtime(Containerd)

To run containers in Pods, Kubernetes uses a container runtime. By default, Kubernetes employs the Container Runtime Interface (CRI) to interact with your selected container runtime. Each node needs to have container runtime installed. In this blog, we'll use containerd.

Run these instructions on all the nodes. I am using Ubuntu on all the nodes.

• Enable IPv4 packet forwarding:

    # sysctl params required by setup, params persist across reboots
    cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
    net.ipv4.ip_forward = 1
    EOF
  
    # Apply sysctl params without reboot
    sudo sysctl --system
  

  Run sudo sysctl net.ipv4.ip_forward to verify that net.ipv4.ip_forward is set to 1

• Specify and load the following kernel module dependencies:

    cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
    overlay
    br_netfilter
    EOF
  
    sudo modprobe overlay
    sudo modprobe br_netfilter
  

• Install containerd:

  Add Docker's official GPG key:

    sudo apt-get update
    sudo apt-get -y install ca-certificates curl
    sudo install -m 0755 -d /etc/apt/keyrings
    sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
    sudo chmod a+r /etc/apt/keyrings/docker.asc
  

  Add the repository to Apt sources:

    echo \
      "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
      $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
      sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
  

  Install containerd

    sudo apt-get update
    sudo apt-get -y install containerd.io
  

  For more details, refer to the Official installation documentation

• Configure systemd cgroup driver for containerd

  First, we need to create a containerd configuration file at the location /etc/containerd/config.toml

    sudo mkdir -p /etc/containerd
    sudo containerd config default | sudo tee /etc/containerd/config.toml
  

  Now, we enable the systemd cgroup driver for the CRI in /etc/containerd/config.toml at section [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] set SystemCgroup = true

  

  OR we can just run

    sudo sed -i "s/SystemdCgroup = false/SystemdCgroup = true/g" "/etc/containerd/config.toml"
  

  Restart containerd

    sudo systemctl restart containerd
  

  Containerd should be running, check the status using:

    sudo systemctl status containerd
  

Install kubeadm, kubelet and kubectl

Run these commands on all nodes. These instructions are for Kubernetes v1.30.

• Installapt-transport-https, ca-certificates, curl, gpgpackages

    sudo apt-get update
    sudo apt-get install -y apt-transport-https ca-certificates curl gpg
  

• Download the public signing key for the Kubernetes package repositories

    curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
  

• Add theaptrepository for Kubernetes 1.30

    echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
  

• Install kubelet, kubeadm and kubectl

    sudo apt-get update
    sudo apt-get install -y kubelet kubeadm kubectl
    sudo apt-mark hold kubelet kubeadm kubectl
  

• This is optional, Enable the kubelet service before running kubeadm

    sudo systemctl enable --now kubelet
  

Initialize the k8s control plane

Run these instructions only on the control plane node

• kubeadm init

  To initialize the control plane, run the kubeadm init command. You also need to choose a pod network add-on and deploy a Container Network Interface (CNI) so that your Pods can communicate with each other. Cluster DNS (CoreDNS) will not start until a network is installed.

  We will use Calico CNI, so set the --pod-network-cidr=192.168.0.0/16.

    sudo kubeadm init --pod-network-cidr=192.168.0.0/16
  

  Now, at the end of the kubeadm init command, you'll see kubeadm join command

  sudo kubeadm join <control-plane-ip>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash <hash> copy it and keep it safe.

• Run the following commands to set kubeconfig to access the cluster using kubectl

    mkdir -p $HOME/.kube
    sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    sudo chown $(id -u):$(id -g) $HOME/.kube/config
  

  Now, check the node using

    $ kubectl get nodes
    NAME             STATUS     ROLES           AGE    VERSION
    ip-zzz-zz-z-zz   NotReady   control-plane   114s   v1.30.2
  

  The node is in NotReady state because message: 'container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized' reason: KubeletNotReady . After setting up the CNI, the node should be in a Ready state.

• Set Up a Pod Network

  We must deploy a Container Network Interface (CNI) based Pod network add-on so that Pods can communicate with each other.

  Install the calico operator on the cluster.

    kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml
  

  Download the custom resources necessary to configure Calico.

    kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/custom-resources.yaml
  

  Verify all the Calico pods are in running state.

    $ kubectl get pods -n calico-system
    NAME                                       READY   STATUS    RESTARTS   AGE
    calico-kube-controllers-6f459db86d-mg657   1/1     Running   0          3m36s
    calico-node-ctc9q                          1/1     Running   0          3m36s
    calico-typha-774d5fbdb7-s7qsg              1/1     Running   0          3m36s
    csi-node-driver-bblm8                      2/2     Running   0          3m3
  

  Verify that the node is in a running state

    $ kubectl get nodes
    NAME             STATUS   ROLES           AGE     VERSION
    ip-xxx-xx-x-xx   Ready    control-plane   2m46s   v1.30.2
  

Join the worker nodes

Ensure containerd, kubeadm, kubectl, and kubelet are installed on all worker nodes, then run sudo kubeadm join <control-plane-ip>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash <hash>, which you can find at the end of the kubeadm init command's output.

Check the cluster state

Run these commands on the control-plane node since the worker nodes do not have the kubeconfig file.

• Check if the worker nodes are joined to the cluster.

    $ kubectl get nodes
    NAME               STATUS   ROLES           AGE    VERSION
    ip-xxx-xx-xx-xx    Ready    <none>          9m9s   v1.30.2
    ip-yyy-yy-yy-yy    Ready    <none>          23s    v1.30.2
    ip-zzz-zz-z-zz     Ready    control-plane   27m    v1.30.2
  

  To add a worker role to the worker node we can use kubectl label node <node-name> node-role.kubernetes.io/worker=worker command.

    $ kubectl get nodes
    NAME               STATUS   ROLES           AGE     VERSION
    ip-xxx-xx-xx-xx    Ready    worker          12m     v1.30.2
    ip-yyy-yy-yy-yy    Ready    worker          3m51s   v1.30.2
    ip-zzz-zz-z-zz     Ready    control-plane   31m     v1.30.2
  

• Check the workload running on the cluster

    $ kubectl get pods -A
    NAMESPACE          NAME                                       READY   STATUS    RESTARTS   AGE
    calico-apiserver   calico-apiserver-6fcb65fbd5-n4wsn          1/1     Running   0          35m
    calico-apiserver   calico-apiserver-6fcb65fbd5-nnggl          1/1     Running   0          35m
    calico-system      calico-kube-controllers-6f459db86d-mg657   1/1     Running   0          35m
    calico-system      calico-node-ctc9q                          1/1     Running   0          35m
    calico-system      calico-node-dmgt2                          1/1     Running   0          18m
    calico-system      calico-node-nw4t5                          1/1     Running   0          9m49s
    calico-system      calico-typha-774d5fbdb7-s7qsg              1/1     Running   0          35m
    calico-system      calico-typha-774d5fbdb7-sxb5c              1/1     Running   0          9m39s
    calico-system      csi-node-driver-bblm8                      2/2     Running   0          35m
    calico-system      csi-node-driver-jk4sz                      2/2     Running   0          18m
    calico-system      csi-node-driver-tbrrj                      2/2     Running   0          9m49s
    kube-system        coredns-7db6d8ff4d-5f7s5                   1/1     Running   0          37m
    kube-system        coredns-7db6d8ff4d-qj9r8                   1/1     Running   0          37m
    kube-system        etcd-ip-zzz-zz-z-zz                        1/1     Running   0          37m
    kube-system        kube-apiserver-ip-zzz-zz-z-zz              1/1     Running   0          37m
    kube-system        kube-controller-manager-ip-zzz-zz-z-zz     1/1     Running   0          37m
    kube-system        kube-proxy-dq8k4                           1/1     Running   0          9m49s
    kube-system        kube-proxy-t2sw9                           1/1     Running   0          18m
    kube-system        kube-proxy-xd6nn                           1/1     Running   0          37m
    kube-system        kube-scheduler-ip-zzz-zz-z-zz              1/1     Running   0          37m
    tigera-operator    tigera-operator-76ff79f7fd-jj4kf           1/1     Running   0          35m
  

Conclusion

Setting up a Kubernetes cluster with Kubeadm involves a clear and structured process. You can create a functional cluster by meeting all prerequisites, configuring the container runtime, and installing Kubernetes components. Using Calico for networking ensures seamless pod communication. With the control plane and worker nodes properly configured and joined, you can efficiently manage and deploy workloads across your Kubernetes cluster.

Thank you for reading this blog; your interest is greatly appreciated, and I hope it helps you on your Kubernetes journey; in the next article, we'll explore running workloads in the Kubernetes cluster.

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. - From Kubernetes Docs

In simpler terms, Kubernetes, also known as an orchestrator, is an open-source platform that automates the management of containers. Originally developed by Google as an internal container management project named Borg, Kubernetes was made open-source on June 7, 2014. In July 2015, it was donated to the Cloud Native Computing Foundation (CNCF).

Kubernetes means helmsman or pilot in Greek, reflecting its role in guiding containerized applications. It is also known as k8s, a shorthand that represents the 8 letters between the 'k' and the 's' .

Key Features

Kubernetes offers a robust set of features, including:

• Automatic Bin Packing: Schedules containers automatically based on resource needs and constraints, ensuring efficient utilization without compromising availability.

• Self-Healing: Replaces and reschedules containers from failed nodes, restarts unresponsive containers, and prevents traffic from being routed to them.

• Horizontal Scaling: Scales applications manually or automatically based on CPU or custom metrics utilization.

• Service Discovery and Load Balancing: Assigns IP addresses to containers and provides a single DNS name for a set of containers to facilitate load balancing.

• Automated Rollouts and Rollbacks: Manages seamless rollouts and rollbacks of application updates and configuration changes, continuously monitoring application health to prevent downtime.

• Secret and Config Management: Manages secrets and configuration details separately from container images, avoiding the need to rebuild images.

• Storage Orchestration: Automatically mounts storage solutions to containers from local storage, cloud providers, or network storage systems.

• Batch Execution: Supports batch execution and long-running jobs, and replaces failed containers as needed.

• Role-Based Access Control (RBAC): Regulates access to cluster resources based on user roles within an enterprise.

• Extensibility: Extends functionality through Custom Resource Definitions (CRDs), operators, custom APIs, and more.

With its extensive array of capabilities, Kubernetes simplifies the management of containerized applications, ensuring optimal efficiency and performance, while also providing scalability, resilience, and flexibility for diverse workloads.

Cluster Architecture

Kubernetes cluster has a straightforward yet elegant and efficient architecture, consisting of at least one master node, also known as a control-plane node, and at least one worker node. The diagram below illustrates the cluster architecture.

Control-plane node

The control plane is responsible for maintaining the overall state of the cluster. The control plane includes components like the API server, scheduler, controller manager, and etcd, which coordinate and manage the cluster operations.

kube-api-server

The Kubernetes API server serves as the core of the control plane. It exposes an HTTP API through which users, external components, and cluster components securely interact to manage the state of Kubernetes objects. It validates incoming requests before storing them and supports the incorporation of custom API servers to expand its functionality. Highly configurable, it accommodates diverse configurations and extensions to suit specific cluster requirements.

Scheduler

The Kubernetes scheduler watches for newly created pods without assigned nodes and selects suitable nodes for them. It retrieves resource usage data for each worker node from etcd via the API server. Additionally, it incorporates scheduling requirements specified in the pod's configuration, such as the preference to run on nodes labelled with specific attributes like "disk==ssd".

So basically, the scheduler is responsible for assigning a node to a pod based on available resources and scheduling constraints.

kube-controller-manager

The kube-controller-manager is a collection of different Kubernetes controllers, running as a single binary. It ensures that the actual state of objects matches their desired state. Each controller watches over its objects, maintains their state, and plays a specific role in maintaining the health and desired configuration of the cluster. Key controllers within kube-controller-manager include the ReplicaSet controller, Deployment controller, Namespace controller, ServiceAccount controller, Endpoint controller, and Persistent Volume controller.

cloud-controller-manager

The cloud-controller-manager includes the Node controller, Route controller, Service controller, and Volume controller. These controllers are responsible for interfacing with the cloud infrastructure to manage nodes, storage volumes, load balancing, and routing. They ensure seamless integration and management of cloud resources within the Kubernetes cluster.

ETCD

ETCD is a distributed key-value store used to persist the state of a Kubernetes cluster. New data is always appended, never replaced, and obsolete data is compacted periodically to reduce the data store size. Only the Kubernetes API server can communicate directly with ETCD to ensure consistency and security. The ETCD CLI management tool provides capabilities for backup, snapshot, and restore.

Worker node

A worker node in Kubernetes executes application workloads by hosting and managing containers, providing essential computational resources within the cluster. It consists of components such as the Kubelet, kube-proxy, and a container runtime interface(CRI) like Docker or containerd.

Kubelet

The kubelet operates as an agent on each node within the Kubernetes cluster, maintaining communication with the control plane components. It receives pod definitions from the API server and coordinates with the container runtime to instantiate and manage containers associated with those pods. The kubelet also monitors the health and lifecycle of containers and manages resources as per pod specifications.

kube-proxy

The kube-proxy is a network agent running on each node in the Kubernetes cluster. It dynamically updates and maintains the network rules on the node to facilitate communication between pods and external traffic. It abstracts the complexities of pod networking by managing services and routing connections to the appropriate pods based on IP address and port number.

Container Runtime

In Kubernetes, a container runtime is essential for each node to handle the lifecycle of containers. Some of the known container runtimes are Docker, CRI-O, containerd, and rkt. These runtimes interface with Kubernetes using the Container Runtime Interface (CRI), ensuring that containers are created, managed, and terminated as needed within the cluster.

Pod

In Kubernetes, you cannot directly run containers as you would with Docker. Instead, containers are grouped into units called pods. A pod can host multiple containers and is the smallest deployable object in Kubernetes.

How does all of this come together?

Let's see this with an example of pod creation:

First, define the pod by creating a YAML or JSON file that specifies its configuration, including container images, resource requirements, environment variables, storage volumes etc. This file acts as the pod's blueprint.

Once you have the pod definition file ready, you submit it to the Kubernetes API server using the kubectl command-line tool. For instance, you can apply the configuration with a command like kubectl apply -f pod-definition.yaml. Alternatively, you can create the pod directly with a command such as kubectl run my-pod --image=my-image.

The Kubernetes API server receives and validates the pod creation request, ensuring it meets all criteria. Once validated, it stores the pod definition in etcd, the cluster's key-value store.

The Kubernetes scheduler watches for newly created pods without assigned nodes. It interacts with the API server to get the pod configuration, evaluates the resource requirements and constraints, and then selects a suitable worker node for the pod, updating the pod configuration with the nodeName.

On the assigned node, the kubelet receives the pod definition from the API server. It manages pods and their containers, retrieves container images from a registry if needed, and uses the container runtime (like Docker or containerd) to create and start containers as specified and also set up storage as required. It monitors container health and can restart them based on defined policies. Meanwhile, kube-proxy configures networking rules for pod communication. When all containers are running and ready, the pod can accept traffic, showcasing Kubernetes' orchestration in maintaining application states.

Conclusion

Kubernetes is a robust platform for managing containerized applications, offering features that simplify deployment, scaling, and maintenance. This article covered its origins, core functionalities, and architecture. Leveraging Kubernetes enhances efficiency, resilience, and flexibility, making it essential for modern cloud-native environments.

Thank you for reading this blog; your interest is greatly appreciated, and I hope it helps you on your Kubernetes journey; in the next article, we'll explore how to install Kubernetes using the Kubeadm tool.

Containerization has revolutionized how we develop and deploy software, streamlining processes and enhancing scalability. It all began modestly in 1979 with the introduction of chroot, a Unix feature that allowed applications to operate within a confined directory subset. This breakthrough laid the groundwork for application isolation, a crucial concept for modern containerization.

Building upon chroot, FreeBSD's introduction of jails in 2000 marked a significant advancement. Jails provided a more robust form of isolation within a FreeBSD environment, enabling multiple applications to run securely on the same host without interference. This development was pivotal in demonstrating the practicality of isolating software environments for enhanced security and efficiency.

Following FreeBSD, Solaris Containers (2004), also known as Zones refined containerization by introducing sophisticated resource management capabilities. Zones allowed administrators to allocate specific CPU, memory, and storage resources to each container, optimizing hardware utilization and paving the way for efficient data centre management.

Google's control group(cgroup), integrated into the Linux kernel in 2007, brought fine-grained resource control to Linux-based containers. This innovation enabled administrators to manage and isolate resource usage among groups of processes, enhancing predictability and performance in containerized environments.

The culmination of these advancements led to the creation of Linux Containers (LXC) in 2008, which provided a user-friendly interface for leveraging Linux kernel features like cgroups and namespaces. LXC enabled the creation and management of lightweight, isolated Linux environments, marking a significant milestone towards the widespread adoption of container technology.

In 2013, Docker revolutionized containerization with its user-friendly platform for creating, deploying, and managing containers. Initially built upon LXC, Docker later introduced its container runtime and libcontainer, which leveraged Linux namespaces, control groups, and other kernel features. Docker's standardized container format and tooling simplified application packaging and deployment, accelerating the adoption of containers in both development and production environments.

Around the same time, the technological landscape experienced a major shift in software architecture. It moved from monolithic applications, where all modules run on a single machine and are tightly coupled, to a more decentralized and scalable model known as microservices architecture. In the 2000s, the rise of microservices architecture and the adoption of cloud computing rapidly accelerated the use of containerization. However, efficiently managing and orchestrating these containers remains a significant challenge.

Challenges in Container Management

Efficiently managing and orchestrating these containers at scale remains a formidable task, presenting challenges such as:

• Deployment: Deploying numerous containers across diverse environments requires meticulous handling of versions, dependencies, and configurations to ensure consistency and reliability.

• Scaling: Applications must scale dynamically to meet varying demands, necessitating automated mechanisms that optimize resource usage without manual intervention.

• Networking: Effective networking is essential for seamless service discovery, load balancing, and secure communication among containers, demanding robust management policies.

• Resource Management: Efficient allocation of CPU, memory, and storage resources is critical to prevent performance bottlenecks and control operational costs effectively.

• Security: Ensuring container security requires implementing strict access controls, secure configurations, and isolation strategies to mitigate risks of breaches.

• High Availability: Maintaining application availability involves proactive management of container failures, load balancing, and resilient failover strategies to minimize downtime.

Addressing these challenges is crucial for leveraging the full potential of containerization, enabling agility, scalability, and efficiency in software development and deployment.

Container Orchestration

While containerization has revolutionized software deployment, efficiently managing and scaling containerized applications across complex environments remains a daunting task. Container orchestration addresses these challenges by automating deployment, scaling, and management processes, ensuring applications run seamlessly from development through to production.

Container Orchestrators

Container orchestrators are tools that group systems together to form clusters where container deployment and management are automated at scale while meeting the production requirements.

They provide essential functionalities such as:

• Automated Deployment: Simplifying the deployment process with declarative configurations and automated rollouts.

• Scalability: Enabling horizontal scaling of applications based on resource demands, ensuring performance and efficiency.

• Networking Automation: Facilitating efficient networking by managing service discovery, load balancing, and network security policies.

• Resource Optimization: Optimizing resource allocation and utilization to enhance performance and reduce operational costs.

• Security Enhancements: Implementing security best practices, including isolation mechanisms, encryption, and access controls.

• High Availability Strategies: Ensuring continuous application availability through automated failover, load distribution, and recovery mechanisms.

Popular Container Orchestrators are:

1. Kubernetes:

   • Developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF).

   • Features: Automatic bin packing, self-healing, horizontal scaling, service discovery, load balancing, and automated rollouts and rollbacks.

2. Docker Swarm:

   • Native clustering and orchestration solution for Docker containers.

   • Features: Easy setup, Docker CLI compatibility, service discovery, load balancing, scaling, and rolling updates.

3. Apache Mesos:

   • An open-source project that abstracts CPU, memory, storage, and other compute resources away from machines.

   • Features: Highly scalable, supports multiple frameworks, resource isolation, fault-tolerance, and elasticity.

4. Nomad:

   • Developed by HashiCorp, it is a flexible and simple workload orchestrator.

   • Features: Multi-region, multi-cloud deployment, integrates with Consul for service discovery and Vault for secrets management, easy to use, and supports multiple workloads (Docker, non-containerized, Windows, etc.).

5. OpenShift:

   • Developed by Red Hat, built on top of Kubernetes with additional features.

   • Features: Developer and operational tools, automated installation, upgrade management, monitoring, logging, and security policies.

6. Rancher:

   • An open-source platform for managing Kubernetes at scale.

   • Features: Multi-cluster management, integrated monitoring and logging, centralized RBAC, and supports any Kubernetes distribution.

7. Amazon Elastic Kubernetes Service (EKS):

   • Managed Kubernetes service by Amazon Web Services.

   • Features: Fully managed, integrated with AWS services, auto-scaling, security, and compliance.

8. Google Kubernetes Engine (GKE):

   • Managed Kubernetes service by Google Cloud.

   • Features: Fully managed, integrated with Google Cloud services, auto-scaling, security, and compliance.

9. Azure Kubernetes Service (AKS):

   • Managed Kubernetes service by Microsoft Azure.

   • Features: Fully managed, integrated with Azure services, auto-scaling, security, and compliance.

10. IBM Cloud Kubernetes Service:

    • Managed Kubernetes service by IBM Cloud.

    • Features: Fully managed, integrated with IBM Cloud services, auto-scaling, security, and compliance.

11. Alibaba Cloud Container Service for Kubernetes (ACK):

    • Managed Kubernetes service by Alibaba Cloud.

    • Features: Fully managed, integrated with Alibaba Cloud services, auto-scaling, security, and compliance.

Conclusion

In conclusion, containerization has revolutionized software development and deployment, offering scalability, efficiency, and agility crucial in today's dynamic landscape. As we've explored the evolution from chroot to Docker and the challenges of managing containerized environments, it's clear that container orchestration is pivotal.

Thank you for reading this blog; your interest is greatly appreciated, and I hope it helps you on your Kubernetes journey; in the next blog, we'll explore Kubernetes, covering its features, architecture and core components.

In the early days of the Internet, building APIs was challenging. Developers had to design them in a way that made sense for everyone using them. It was like trying to order a drink from a bartender who had a complex menu with too many options. You would often end up getting more information than you needed or not enough, like ordering a simple orange juice and receiving the entire fruit basket! This caused frustration and wasted time for developers who had to sift through unnecessary data or make multiple requests to get what they wanted. Imagine having to ask the bartender for a drink, but instead of a simple order, you received an entire catalogue of beverages! To make matters worse, traditional APIs, known as REST APIs, relied on a large number of endpoints. These endpoints acted as specific paths to access different parts of the data. It was like having a maze with countless doors to navigate through. But then, something game-changing happened. Facebook introduced GraphQL, a revolutionary approach to building APIs in 2012 that turned the tables completely. With GraphQL, developers finally said goodbye to the headaches of over-fetching and under-fetching data. Fast forward to 2015, Facebook open-sourced GraphQL and in 2018 it donated GraphQL to the Linux Foundation.

GraphQL is a query language for API or some may say it is a new standard for developing APIs.

In this blog, we're going to explore how GraphQL tackles the challenges faced by traditional REST APIs. We'll also embark on a hands-on journey of building a GraphQL server in Go and to make our development process even more exciting and efficient, we'll leverage the power of Ent, an amazing entity library designed specifically for Go.

GraphQL the saviour

In the introduction, we mentioned issues of RESTful APIs. Let’s try to understand them and look into how GraphQL solves them.

Imagine you're at a library, and you want to gather information about different books. You go to the librarian and request details about a book's title, author, and publication date. The librarian gives you the title, but when you ask for the author's email or address or other books published by the same author, they tell you to go to a different librarian. To get all the information you need, you have to keep bouncing between different librarians. This is called under-fetching of data.

In the world of software and applications, a similar situation occurs when fetching data from servers.

Let's consider a scenario where you're using a book catalogue API to fetch information about different books. If you want to retrieve the name of the author for a specific book, you would typically need to make multiple API calls to different endpoints.

For instance, the if want to fetch the author-related details from the database then we might first hit on /books/:$id. Here, in the backend we might need to make two queries, the first query will fetch the book with a particular id or just the author id from the book table and then we'll have to make a second query to the author table with the author id and fetch the record, assuming author-related information is stored in a separate table.

Request 1: GET /books/1
Response 1:
"book":
   {
     "id": 1,
     "title": "The Ink Black Heart",
     "genre": "Mystery",
     "publicationDate": "30 August 2022",
     "isbn": "9780316413138"
     "author_id": "123"
   }

Request 2: GET /authors/123
Response 2:
"author":
  {
      "id": 123,
      "name": "J. K. Rowling"
  }

As you can see, the server has to make multiple calls to different endpoints to fulfil this request, resulting in what we call under-fetching of data. It means that the API fails to retrieve all the required data in a single call, leading to additional requests and unnecessary processing.

On the other hand, there's the issue of over-fetching data.

Imagine you're at a magical restaurant where you can order any food or drink you desire. You walk up to the bartender and say, "I'd like a drink, please." The bartender nods, disappears for a moment, and returns with a tray filled with every drink imaginable: water, soda, juice, cocktails, and even a bowl of soup! You only wanted a simple glass of lemonade, but now you're overwhelmed with choices. This is called over-fetching of data.

Let's say you only need the name of the author for a particular book. However, the server, following a traditional RESTful approach, fetches and sends all the available information about the author, such as their ID, phone number, email, and address. This extra data retrieval and processing are considered over-fetching, as it includes more information than necessary.

These types of data requests can strain system resources, resulting in high traffic and reduced performance. The continuous accumulation of such inefficient requests can degrade the system's overall performance and scalability over time.

The GraphQL solves above issues with only one API call.

Request: Get /graphql
Body:
{
  "query": "
    query {
      books {
        title
        genre
        author {
          name
        }
      }
    }
  "
}

Response:
{
  "data": {
    "books": [
      {
        "title": "The Ink Black Heart",
        "genre": "Mystery",
        "author": {
          "name": "J. K. Rowling"
        }
      },
      ...
    ]
  }
}

As you can see, the GraphQL query precisely defines the fields needed: book title, genre, and the nested author's name. The response contains only the requested data, eliminating under-fetching and over-fetching issues. This approach reduces network overhead, improves performance, and enhances the overall developer and user experience.

In the case of smaller companies with a limited user base, the challenges of over-fetching and under-fetching data may not pose significant problems. However, for behemoths like Facebook, which handles an enormous amount of data and millions of requests per second, these issues become critical. When serving user requests, Facebook often needs to make multiple REST calls to fetch the precise data required. The multiplication effect of even a few million extra requests can overload the servers with processing overhead, leading to high traffic and reduced performance.

Query and Mutation

To fully understand GraphQL we need to understand the Query and Mutation first.

Queries:

In GraphQL, queries are used to retrieve data from the server. They allow you to specify the exact data you need and the shape of the response. You define a query by specifying the fields you want to fetch and their relationships. The server processes the query and returns the requested data in a structured format, typically JSON.

For example, a query in GraphQL for retrieving book information may look like this:

query {
  book(id: 123) {
    title
    genre
    author {
      name
    }
  }
}

This query asks the server to fetch the title and genre of a book with the ID 123, along with the name of its author. The response will only contain the requested fields.

Mutations:

Mutations in GraphQL are used to modify or create data on the server. They allow you to perform operations such as creating new records, updating existing ones, or deleting data. Mutations are analogous to the POST, PUT, or DELETE methods in RESTful APIs.

For example, a mutation in GraphQL for creating a book and its author may look like this:

mutation {
  createBook(title: "The Ink Black Heart", genre: "Mystery", author: "J. K. Rowling") {
    id
    title
    genre
    author {
      id
      name
    }
  }
}

This mutation creates a new book with the title "The Ink Black Heart", genre "Mystery", and assigns it to the author "J. K. Rowling". The response will contain the ID, title, genre, and the ID and name of the author of the created book.

By using queries and mutations, GraphQL provides a flexible and efficient way to retrieve and modify data from a server. Clients can request precisely what they need, and mutations enable them to modify the data while maintaining a clear and consistent API contract.

For more information about GraphQL and what it can do or maybe on writing complex queries or mutations, you can visit the official documentation.

Let's Code

In this blog, we’ll develop a very minimal graphql server for the book catalogue application where we’ll be able to create book and author entities in the database and fetch them. The source code for this project is available at pratikjagrut/book-catalog.

Prerequisite

Go

Setting up Ent

Ent is an open-source entity framework designed specifically for Go. Think of it as a tool that helps us work with databases in an easier and more organized way. Ent has gained popularity in the Go community for its unique features and benefits.

Originally developed at Facebook, Ent was created to address the challenges of managing applications with large and complex data models. It was successfully used within Facebook for a year before being open-sourced in 2019. Since then, Ent has grown and even joined the Linux Foundation in 2021.

For detailed information on Ent see the docs.

After installing prerequisite dependencies, create a directory for the project and initialize a Go module:

mkdir book-catalog
cd book-catalog
go mod init github.com/pratikjagrut/book-catalog

Installation

Run the following Go commands to install Ent, and tell it to initialize the project structure along with a Book schema.

go get -d entgo.io/ent/cmd/ent
go run -mod=mod entgo.io/ent/cmd/ent new Book
go run -mod=mod entgo.io/ent/cmd/ent new Author

After installing Ent and running ent new, your project directory should look like this:

➜  book-catalog git:(main) ✗ tree .
.
├── ent
│   ├── generate.go
│   └── schema
│       ├── author.go
│       └── book.go
├── go.mod
└── go.sum

2 directories, 5 files

Code Generation

When you run the ent new command it generates a schema file for you at ent/schema/book.go

package schema

import "entgo.io/ent"

// Book holds the schema definition for the Book entity.
type Book struct {
   ent.Schema
}

// Fields of the Book.
func (Book) Fields() []ent.Field {
   return nil
}

// Edges of the Book.
func (Book) Edges() []ent.Edge {
   return nil
}

As you can see, initially, the schema has no fields or edges defined. Let's run the command for generating assets to interact with the Book and Author entity:

go generate ./ent

When we run the command go generate ./ent, it triggers Ent's automatic code generation tool. This tool takes the schemas we define in the schema package and generates the corresponding Go code. This generated code will enable us to interact with the database.

After running the code generation, you'll find a file named client.go under the ./ent directory. This file contains client code that allows us to perform queries and mutations on the entities. It serves as our gateway to interact with the database.

Let's create a test to use this. We'll use SQLite in this test case for testing Ent.

go get github.com/mattn/go-sqlite3
go get github.com/stretchr/testify/assert
touch ent/book-catalog_test.go

You can add the following code to your book-catalog_test.go file. This code creates an instance of ent.Client automatically generates all the necessary schema resources in the database, including tables and columns.

At this stage, the test only establishes a connection and creates a schema without any fields or edges. However, we will update and expand this test as we progress through the blog.

package ent

import (
   "context"
   "testing"

   "github.com/stretchr/testify/assert"

   _ "github.com/mattn/go-sqlite3"
)

func TestBookCatalog(t *testing.T) {
   client, err := Open("sqlite3", "file:book-catalog.db?cache=shared&_fk=1")

   assert.NoErrorf(t, err, "failed opening connection to sqlite")
   defer client.Close()

   ctx := context.Background()

   // Run the automatic migration tool to create all schema resources.
   err = client.Schema.Create(ctx)
   assert.NoErrorf(t, err, "failed creating schema resources")
}

Then, run the go test -v ./ent, it will create a schema with empty books table.

➜  book-catalog git:(main) ✗ go test -v ./ent
=== RUN   TestBookCatalog
--- PASS: TestBookCatalog (0.00s)
PASS
ok      github.com/pratikjagrut/book-catalog/ent    0.660s

Create database schema:

With the basic setup in place, we are now ready to expand our Book entity by adding fields and proceeding with building queries and mutations.

Let’s define a schema for our database:

The author has the following properties:

• ID: A unique identifier for the book. Auto-generated.

• Name: Name of the author

• Email: Email address of the author

In addition, we need to establish a relationship, or edge, between the Author and Book entities. In this scenario, an author can write multiple books, creating a One-to-Many (1->M) relationship.

Add the following fields and edges to the ent/schema/author.go file.

package schema

import (
   "entgo.io/ent"
   "entgo.io/ent/schema/edge"
   "entgo.io/ent/schema/field"
)

// Author holds the schema definition for the Author entity.
type Author struct {
   ent.Schema
}

// Fields of the Author.
func (Author) Fields() []ent.Field {
   return []ent.Field{
       field.String("name"),
       field.String("email"),
   }
}

// Edges of the Author.
func (Author) Edges() []ent.Edge {
   return []ent.Edge{
       edge.To("books", Book.Type),
   }
}

The book has the following properties:

• ID: A unique identifier for the book. Auto-generated.

• Title: The title or name of the book.

• Genre: The genre or category to which the book belongs.

• PublicationDate: The date when the book was published.

• ISBN: The International Standard Book Number assigned to the book.

• CreatedAt: The date and time of record creation in the database.

Here, the relation between the book and the author will be many-to-one. So we’ll create an inverse edge.

Now, add these fields to the ent/schema/book.go file.

package schema

import (
   "time"

   "entgo.io/ent"
   "entgo.io/ent/schema/edge"
   "entgo.io/ent/schema/field"
)

// Book holds the schema definition for the Book entity.
type Book struct {
   ent.Schema
}

// Fields of the Book.
func (Book) Fields() []ent.Field {
   return []ent.Field{
       field.String("title").NotEmpty(),
       field.String("genre").NotEmpty(),
       field.String("publication_date").NotEmpty(),
       field.String("isbn").NotEmpty(),
       field.Time("created_at").Default(time.Now()),
   }
}

// Edges of the Book.
func (Book) Edges() []ent.Edge {
   return []ent.Edge{
       edge.From("author", Author.Type).
           Ref("books").
           Unique(),
   }
}

Create mutations and queries

Once again, let's run go generate ./ent to generate the necessary mutations for the fields we defined in our Author and Book entity and check schema with go run -mod=mod entgo.io/ent/cmd/ent describe ./ent/schema command.

➜ go run -mod=mod entgo.io/ent/cmd/ent describe ./ent/schema
Author:
    +-------+--------+--------+----------+----------+---------+---------------+-----------+------------------------+------------+---------+
    | Field |  Type  | Unique | Optional | Nillable | Default | UpdateDefault | Immutable |       StructTag        | Validators | Comment |
    +-------+--------+--------+----------+----------+---------+---------------+-----------+------------------------+------------+---------+
    | id    | int    | false  | false    | false    | false   | false         | false     | json:"id,omitempty"    |          0 |         |
    | name  | string | false  | false    | false    | false   | false         | false     | json:"name,omitempty"  |          0 |         |
    | email | string | false  | false    | false    | false   | false         | false     | json:"email,omitempty" |          0 |         |
    +-------+--------+--------+----------+----------+---------+---------------+-----------+------------------------+------------+---------+
    +-------+------+---------+---------+----------+--------+----------+---------+
    | Edge  | Type | Inverse | BackRef | Relation | Unique | Optional | Comment |
    +-------+------+---------+---------+----------+--------+----------+---------+
    | books | Book | false   |         | O2M      | false  | true     |         |
    +-------+------+---------+---------+----------+--------+----------+---------+

Book:
    +------------------+-----------+--------+----------+----------+---------+---------------+-----------+-----------------------------------+------------+---------+
    |      Field       |   Type    | Unique | Optional | Nillable | Default | UpdateDefault | Immutable |             StructTag             | Validators | Comment |
    +------------------+-----------+--------+----------+----------+---------+---------------+-----------+-----------------------------------+------------+---------+
    | id               | int       | false  | false    | false    | false   | false         | false     | json:"id,omitempty"               |          0 |         |
    | title            | string    | false  | false    | false    | false   | false         | false     | json:"title,omitempty"            |          1 |         |
    | genre            | string    | false  | false    | false    | false   | false         | false     | json:"genre,omitempty"            |          1 |         |
    | publication_date | string    | false  | false    | false    | false   | false         | false     | json:"publication_date,omitempty" |          1 |         |
    | isbn             | string    | false  | false    | false    | false   | false         | false     | json:"isbn,omitempty"             |          1 |         |
    | created_at       | time.Time | false  | false    | false    | true    | false         | false     | json:"created_at,omitempty"       |          0 |         |
    +------------------+-----------+--------+----------+----------+---------+---------------+-----------+-----------------------------------+------------+---------+
    +--------+--------+---------+---------+----------+--------+----------+---------+
    |  Edge  |  Type  | Inverse | BackRef | Relation | Unique | Optional | Comment |
    +--------+--------+---------+---------+----------+--------+----------+---------+
    | author | Author | true    | books   | M2O      | true   | true     |         |
    +--------+--------+---------+---------+----------+--------+----------+---------+

With Ent, creating migrations and performing common operations such as creating a record or fetching records is straightforward and practical.

To create a new record in the database, we can simply call the following code:

author, _ := client.Author.Create().
       SetName("J. K. Rowling").
       SetEmail("jk@gmail.com").
       Save(context.Background())

book, _ := client.Book.Create().
       SetTitle("The Ink Black Heart").
       SetGenre("Mystery").
       SetIsbn("9780316413138").
       SetPublicationDate("30 August 2022").
       SetAuthor(author).
       Save(context.Background())

This code snippet creates a new author and book record and adds the edge using the SetAuthor method.

To fetch all the books from the database, we can use the following code:

books, err := client.Book.Query().All(ctx)

This code retrieves all the Book records stored in the database.

Ent provides many more useful functions and options for creating, fetching, and manipulating data in the database. Such features make database operations more manageable and efficient. I encourage you to explore the Ent documentation for a deeper understanding of Ent's capabilities and how to make the most of it in your projects.

Test ent setup

Let’s update our ent/book-catalog_test.go with migrations.

package ent

import (
   "context"
   "testing"

   "github.com/stretchr/testify/assert"

   _ "github.com/mattn/go-sqlite3"
)

func TestBookCatalog(t *testing.T) {
   // client, err := Open("sqlite3", "file:book-catalog.db?cache=shared&_fk=1")
   client, err := Open("sqlite3", "file:ent?mode=memory&cache=shared&_fk=1")
   assert.NoErrorf(t, err, "failed opening connection to sqlite")
   defer client.Close()

   ctx := context.Background()

   // Run the automatic migration tool to create all schema resources.
   err = client.Schema.Create(ctx)
   assert.NoErrorf(t, err, "failed creating schema resources")

   author, err := client.Author.Create().
       SetName("J. K. Rowling").
       SetEmail("jk@gmail.com").
       Save(ctx)
   assert.NoError(t, err)

   _, err = client.Book.Create().
       SetTitle("The Ink Black Heart").
       SetGenre("Mystery").
       SetIsbn("9780316413138").
       SetPublicationDate("30 August 2022").
       SetAuthor(author).
       Save(ctx)
   assert.NoError(t, err)

   author, err = client.Author.Create().
       SetName("George R. R. Martin").
       SetEmail("grrm@gmail.com").
       Save(ctx)
   assert.NoError(t, err)

   _, err = client.Book.Create().
       SetTitle("A Game of Thrones").
       SetGenre("Fantasy Fiction").
       SetIsbn("9780553593716").
       SetPublicationDate("1 August 1996").
       SetAuthor(author).
       Save(ctx)
   assert.NoError(t, err)

   books, err := client.Book.Query().All(ctx)
   assert.NoError(t, err)
   assert.Equal(t, len(books), 2)
}

Now run the go test and it should pass.

➜  book-catalog git:(main) ✗ go test -v ./ent
=== RUN   TestBookCatalog
--- PASS: TestBookCatalog (0.00s)
PASS
ok      github.com/pratikjagrut/book-catalog/ent

Setup GraphQL with Ent

Now, let's take our Ent setup with the SQLite database a step further by integrating GraphQL. This integration will provide a more advanced and practical way to handle database queries.

By integrating GraphQL with Ent, we can leverage GraphQL's flexible querying capabilities to efficiently retrieve data. With the help of 99designs /gqlgen, a powerful Go library, we can automatically generate GraphQL schemas and resolvers based on our Ent data models. This simplifies the process of building GraphQL APIs, allowing us to focus on defining schemas and writing resolver functions.

Install and configure entgql

Ent offers a convenient extension called contrib/entgql that allows it to generate GraphQL schemas seamlessly. By installing and utilizing this extension, we can effortlessly generate GraphQL schemas based on our Ent data models.

To get started with contrib/entgql, you can install it by running the following command:

go get entgo.io/contrib/entgql

To enable query and mutation capabilities for the Autor and Book schema using Ent and contrib/entgql, we need to add the following annotations to the schema of both entities.

Add the following code to ent/schema/author.go:

func (Author) Annotations() []schema.Annotation {
   return []schema.Annotation{
       entgql.QueryField(),
       entgql.Mutations(entgql.MutationCreate()),
   }
}

Add the following code to ent/schema/book.go:

func (Book) Annotations() []schema.Annotation {
   return []schema.Annotation{
       entgql.QueryField(),
       entgql.Mutations(entgql.MutationCreate()),
   }
}

With the annotations we added, we're telling contrib/entgql to generate essential GraphQL query and mutation fields for our entities to fetch and create data.

Let's create a new file named ent/entc.go and add the following content:

//go:build ignore

package main

import (
    "log"

    "entgo.io/ent/entc"
    "entgo.io/ent/entc/gen"
    "entgo.io/contrib/entgql"
)

func main() {
    ex, err := entgql.NewExtension(
        // Generate a GraphQL schema for the Ent schema
        // and save it as "ent.graphql".
        entgql.WithSchemaGenerator(),
        entgql.WithSchemaPath("ent.graphql"),
    )
    if err != nil {
        log.Fatalf("failed to create entgql extension: %v", err)
    }
    opts := []entc.Option{
        entc.Extensions(ex),
    }
    if err := entc.Generate("./ent/schema", &gen.Config{}, opts...); err != nil {
        log.Fatalf("failed to run ent codegen: %v", err)
    }
}

In this code, we have a main function that performs the Ent code generation. We use the entgql extension to generate a GraphQL schema based on our Ent schema. The generated GraphQL schema will be saved as ent.graphql.

It's worth noting that the ent/entc.go file is ignored during the build process using a //go:build ignore tag. To execute this file, we will utilize the go generate command, which is triggered by the generate.go file in your project.

Remove the ent/generate.go file and create a new one in the root of the project with the following contents. In the next steps, gqlgen commands will be added to this file as well.

package bookcatalog

//go:generate go run -mod=mod ./ent/entc.go

Running schema generation

Once you have installed and configured entgql, you can execute the code generation process by running the following command:\

go generate .

Note: If you encounter package inconsistencies or missing package errors in your IDE after running go generate, you can resolve them by running go mod tidy.

You'll notice a new file was created named ent.graphql:

directive @goField(forceResolver: Boolean, name: String) on FIELD_DEFINITION | INPUT_FIELD_DEFINITION
directive @goModel(model: String, models: [String!]) on OBJECT | INPUT_OBJECT | SCALAR | ENUM | INTERFACE | UNION
type Author implements Node {
 id: ID!
 name: String!
 email: String!
 books: [Book!]
}
type Book implements Node {
 id: ID!
 title: String!
 genre: String!
 publicationDate: String!
 isbn: String!
 createdAt: Time!
 author: Author
}
"""
CreateAuthorInput is used for create Author object.
Input was generated by ent.
"""
input CreateAuthorInput {
 name: String!
 email: String!
 bookIDs: [ID!]
}
"""
CreateBookInput is used for create Book object.
Input was generated by ent.
"""
input CreateBookInput {
 title: String!
 genre: String!
 publicationDate: String!
 isbn: String!
 createdAt: Time
 authorID: ID
}
"""
...

Install and configure gqlgen

Install 99designs/gqlgen:

go get github.com/99designs/gqlgen

To configure the gqlgen package, we need to create a gqlgen.yml file in the root directory of our project. This file is automatically loaded by gqlgen and provides the necessary configuration for generating the GraphQL server code.

Let's add the gqlgen.yml file to the root of our project and follow the comments within the file to understand the meaning of each configuration directive.

# schema tells gqlgen where the GraphQL schema is located.
schema:
- ent.graphql

# resolver reports where the resolver implementations go.
resolver:
layout: follow-schema
dir: .

# gqlgen will search for any type names in the schema in these go packages
# if they match it will use them, otherwise it will generate them.

# autobind tells gqngen to search for any type names in the GraphQL schema in the
# provided package. If they match it will use them, otherwise it will generate new.
autobind:
- github.com/pratikjagrut/book-catalog/ent
- github.com/pratikjagrut/book-catalog/ent/author
- github.com/pratikjagrut/book-catalog/ent/book

# This section declares type mapping between the GraphQL and Go type systems.
models:
# Defines the ID field as Go 'int'.
ID:
  model:
    - github.com/99designs/gqlgen/graphql.IntID
Node:
  model:
    - github.com/pratikjagrut/book-catalog/ent.Noder

To inform Ent about the gqlgen configuration, we need to make a modification to the ent/entc.go file. We will pass the entgql.WithConfigPath("gqlgen.yml") argument to the entgql.NewExtension() function.

Open the ent/entc.go file and copy and paste the following code:

//go:build ignore

package main

import (
   "log"

   "entgo.io/contrib/entgql"
   "entgo.io/ent/entc"
   "entgo.io/ent/entc/gen"
)

func main() {
   ex, err := entgql.NewExtension(
       // Tell Ent to generate a GraphQL schema for
       // the Ent schema in a file named ent.graphql.
       entgql.WithSchemaGenerator(),
       entgql.WithSchemaPath("ent.graphql"),
       entgql.WithConfigPath("gqlgen.yml"),
   )
   if err != nil {
       log.Fatalf("creating entgql extension: %v", err)
   }
   opts := []entc.Option{
       entc.Extensions(ex),
   }
   if err := entc.Generate("./ent/schema", &gen.Config{}, opts...); err != nil {
       log.Fatalf("running ent codegen: %v", err)
   }
}

Add the gqlgen generate command //go:generate go run -mod=mod github.com/99designs/gqlgen to the generate.go file:

package bookcatalog

//go:generate go run -mod=mod ./ent/entc.go
//go:generate go run -mod=mod github.com/99designs/gqlgen

Now, we're ready to run go generate to trigger ent and gqlgen code generation. Execute the go generate command from the root of the project and you may notice new files created.

➜  book-catalog git:(main) ✗ tree -L 1
.
├── ent
├── ent.graphql
├── ent.resolvers.go
├── generate.go
├── generated.go
├── go.mod
├── go.sum
├── gqlgen.yml
└── resolver.go

1 directory, 8 files

The Server

In order to build the GraphQL server, we need to set up the main schema Resolver as defined in resolver.go. The gqlgen library provides the flexibility to modify the generated Resolver and add dependencies to it.

To include the ent.Client as a dependency, you can add the following code snippet to resolver.go:

package bookcatalog

import (
   "github.com/pratikjagrut/book-catalog/ent"

   "github.com/99designs/gqlgen/graphql"
)

// Resolver is the resolver root.
type Resolver struct{ client *ent.Client }

// NewSchema creates a graphql executable schema.
func NewSchema(client *ent.Client) graphql.ExecutableSchema {
   return NewExecutableSchema(Config{
       Resolvers: &Resolver{client},
   })
}

In the above code, we define a Resolver struct with a field named client of type *ent.Client. This allows us to use the ent.Client as a dependency within our Resolver.

The NewSchema function is responsible for creating the GraphQL executable schema. It takes the ent.Client as a parameter and initializes the Resolver with it.

By adding this code to resolver.go, we ensure that our GraphQL server has access to the ent.Client and can utilize it for database operations.

To create the entry point for our GraphQL server, we'll start by creating a new directory called server. Inside this directory, we'll create a main.go file, which will serve as the entry point for our GraphQL server.

mkdir server
touch server/main.go

Run the server using the command below, and open localhost:8081 to access the GraphiQL IDE.

go run server/main.go

Query Data

When you run the GraphQL server using UI on localhost:8081 and send a query or mutation request, you will notice a "not implemented" message with a panic error displayed in the terminal. This occurs because we have not yet implemented the corresponding query and mutation functions in the GraphQL resolver.

{
  books {
    title
    author {
      name
    }
    genre
    publicationDate
    isbn
  }
}

Output:

{
  "errors": [
    {
      "message": "internal system error",
      "path": [
        "books"
      ]
    }
  ],
  "data": null
}

Just replace the following implementation in ent.resolver.go with the following code.

// Authors is the resolver for the authors field.
func (r *queryResolver) Authors(ctx context.Context) ([]*ent.Author, error) {
   return r.client.Author.Query().All(ctx)
}

// Books is the resolver for the books field.
func (r *queryResolver) Books(ctx context.Context) ([]*ent.Book, error) {
   return r.client.Book.Query().All(ctx)
}

Now, restart the server and run the above query again in GraphiQL IDE. This time you should see the output below.

{
  books {
    title
    author {
      name
    }
    genre
    publicationDate
    isbn
  },

  authors{
    name
  }
}

Output:

{
  "data": {
    "books": [],
    "authors": []
  }
}

Mutating Data

As observed in the previous example, our GraphQL schema currently returns an empty list of books and authors. To populate the list with data, we can leverage GraphQL mutations to create new book entries. Fortunately, Ent automatically generates mutations for creating and updating nodes and edges, making this process seamless.

We start by extending our GraphQL schema with custom mutations. Let's create a new file named book.graphql and add our Mutation type:

type Mutation {
 # The input and the output are types generated by Ent.
 createAuthor(input: CreateAuthorInput!): Author
 createBook(input: CreateBookInput!): Book
}

Add the custom GraphQL schema to gqlgen.yml configuration:

# schema tells gqlgen where the GraphQL schema is located.
schema:
 - ent.graphql
 - book.graphql

As you can see, gqlgen generated for us a new file named book.resolvers.go Copy and paste the following code snippet:

// CreateAuthor is the resolver for the createAuthor field.
func (r *mutationResolver) CreateAuthor(ctx context.Context, input ent.CreateAuthorInput) (*ent.Author, error) {
   return r.client.Author.Create().SetInput(input).Save(ctx)
}

// CreateBook is the resolver for the createBook field.
func (r *mutationResolver) CreateBook(ctx context.Context, input ent.CreateBookInput) (*ent.Book, error) {
   return r.client.Book.Create().SetInput(input).Save(ctx)
}

Now, restart the server and run the following mutation query in GraphiQL IDE.

mutation CreateBook {
  createAuthor(input: {name: "J. K. Rowling", email: "jk@gmail.com"}){id},
  createBook(input: {title: "The Ink Black Heart", 
    genre: "Mystery", 
    publicationDate:"30 August 2022", 
    isbn: "9780316413138",
    authorID: "1",
  }){id, title, author{name} }
}

Output:

{
  "data": {
    "createAuthor": {
      "id": "1"
    },
    "createBook": {
      "id": "4294967297",
      "title": "The Ink Black Heart",
      "author": {
        "name": "J. K. Rowling"
      }
    }
  }
}

Now let’s query the data:

{
  books {
    title
    author {
      name
    }
    genre
    publicationDate
    isbn
  },

  authors{
    name
    email
  }
}

Output:

{
  "data": {
    "books": [
      {
        "title": "The Ink Black Heart",
        "author": {
          "name": "J. K. Rowling"
        },
        "genre": "Mystery",
        "publicationDate": "30 August 2022",
        "isbn": "9780316413138"
      }
    ],
    "authors": [
      {
        "name": "J. K. Rowling",
        "email": "jk@gmail.com"
      }
    ]
  }
}

Conclusion

In this blog post, we discovered the power of combining GraphQL and Ent for creating efficient APIs in Go. GraphQL offers flexibility in working with data, while Ent simplifies database management. Integrating these tools enables seamless API development in Go.

We learned how to build a GraphQL server using Ent and explored essential features. Additionally, we leveraged GraphQL for querying and modifying data in the database.

I hope this blog post served as a valuable introduction to GraphQL and Ent, inspiring you to consider them for your future API development projects.

You can find the source code for the project on my GitHub.

Thank you for reading, and happy coding!

Sometimes, goroutines need to wait for some data or some kind of signal to be available before executing further. Cond primitive provides the most efficient way to just do that.

Cond implements a condition variable, a rendezvous point for goroutines waiting for or announcing the occurrence of an event. - sync package doc.

Cond is implemented as a struct with Locker field, and implements 3 methods.

The Broadcast() method of Cond wakes up all goroutines that are waiting on the condition c. The caller may or may not hold the associated mutex c.L while calling this method.

Similarly, the Signal() method of Cond wakes up one goroutine that is waiting on a condition c, if any.

The Wait() method of Cond atomically releases the associated mutex c.L and suspends the execution of the calling goroutine. After resuming the execution, the method re-acquires the mutex before returning. Unlike in other systems, the Wait() the method cannot return unless it is awoken by a call to Broadcast() or Signal().

Let's see an example:

package main

import (
    "fmt"
    "sync"
    "time"
)

var done bool

func reader(i int, c *sync.Cond, wg *sync.WaitGroup) {
    fmt.Printf("goroutine number %d started\n", i+1)
    defer wg.Done()
    c.L.Lock()
    defer c.L.Unlock()
    for !done {
        fmt.Printf("goroutine number %d waiting\n", i+1)
        c.Wait()
    }
    fmt.Printf("goroutine number %d finished\n", i+1)
}

func writer(c *sync.Cond, wg *sync.WaitGroup) {
    fmt.Println("Writer goroutine started")
    defer wg.Done()
    time.Sleep(5 * time.Second)
    c.L.Lock()
    defer c.L.Unlock()
    done = true
    c.Broadcast()
    fmt.Println("Writer goroutine is done")
}

func main() {
    var wg sync.WaitGroup
    m := &sync.Mutex{}
    c := sync.NewCond(m)
    for i := 0; i < 2; i++ {
        wg.Add(1)
        go reader(i, c, &wg)
    }
    wg.Add(1)
    go writer(c, &wg)
    wg.Wait()
}

➜ go run main.go
Writer goroutine started
goroutine number 2 started
goroutine number 2 waiting
goroutine number 1 started
goroutine number 1 waiting
Writer goroutine is done
goroutine number 1 finished
goroutine number 2 finished

Run this code in Go Playground

In the above example, we wait on a condition for !done{}. All the reader goroutines will be suspended until the writer goroutines update the variable done=true and send the waking-up signal to all suspended goroutines.

Once

The sync.Once type in Go is used to perform a certain operation exactly once in a concurrent setting, regardless of how many times it is called from different goroutines.

The sync.Once type guarantees that the operation is executed only once, even if multiple goroutines attempt to call it concurrently. This is useful when you need to initialize a shared resource that is expensive to create or when you want to ensure that a particular task is executed only once.

The sync.Once the type has a single method, Do(f func()), that takes a function f as an argument. The first call to Do() will execute the function f, and subsequent calls will do nothing. The sync.Once type internally maintains a flag that indicates whether f has been executed or not.

Let's see an example:

package main

import (
    "fmt"
    "sync"
)

func DBinit() {
    fmt.Println("Initializing database...")
}

func main() {
    var wg sync.WaitGroup
    var once sync.Once

    for i := 1; i < 5; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            once.Do(DBinit)
            fmt.Println("Database initialized.")
        }()
    }
    wg.Wait()
}

➜  go run main.go
Initializing database...
Database initialized.
Database initialized.
Database initialized.
Database initialized.

Run this code in Go Playground

Pool

The sync.Pool type in Go enables caching of temporary objects that can be utilized again across multiple goroutines. Essentially, the sync.Pool maintains a finite set of objects that are assigned to the goroutine, and once a goroutine finishes utilizing an object, it is returned to the pool for reuse by another goroutine.

The sync.Pool type works by maintaining a pool of objects that can be accessed and reused by multiple goroutines. We can request new resource objects using Get() the method of sync.Pool. It first checks if there are any objects in the pool. If there are, it returns one of the objects. If not, it creates a new object and returns it. When an object is no longer needed, it can be put back into the pool for future use using Put(x interface{}) the method.

Using sync.Pool can significantly reduce the number of objects that need to be garbage collected, which can improve overall performance in Go programs. However, it is important to use sync.Pool judiciously, as it is not always beneficial and can sometimes even hurt performance if not used correctly.

Here's an example:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    var bufCount int

    bufPool := &sync.Pool{
        New: func() any {
            bufCount++
            buf := make([]byte, 1024)
            return &buf
        },
    }

    for i := 0; i < 1000000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            buf := bufPool.Get().(*[]byte)
            bufPool.Put(buf)
        }()
    }

    wg.Wait()
    fmt.Println(bufCount)
}

➜  go run main.go
9

Run this code in Go Playground

Next, a sync.Pool is created using the New field, which is a function that creates a new object when the pool is empty. In this case, the New function creates a new byte slice with a length of 1024 and returns a pointer to the slice. The function also increments the bufCount variable to keep track of the number of objects created.

Then, a loop is started that creates 1 million goroutines. Each goroutine calls the sync.Pool's Get method to retrieve a byte slice from the pool. In the end, the goroutine calls the sync.Pool's Put method to return the byte slice to the pool.

If this program were written without using sync.Pool, each goroutine would create its own byte buffer whenever it needed one. This would result in a lot of unnecessary memory allocation and garbage collection, which can be costly in terms of performance.

Thank you for reading this blog, and please give your feedback in the comment section below.

Go is primarily designed around Communicating Sequential Processes i.e using channels and select primitives to write concurrent programs, but it also supports the traditional way of writing concurrent code using Memory Access Synchronization.

CSP primitives are sufficient for writing concurrent programs in most cases, but if the need arises to do low-level memory access synchronization, the sync package provides primitives for it. The sync package is part of the Go standard library.

sync package's primitives are:

• WaitGroup

• Mutex & RWMutex

• Cond

• Once

• Pool

WaitGroup

WaitGroup provides an alternative to using channels and the select statement to wait for goroutines to finish their execution. WaitGroup is preferred when the results of the concurrent process are not important or we've other ways of collecting results from goroutines.

Here's an example of using WaitGroup to block the main goroutine.

package main

import (
    "fmt"
    "net/http"
    "sync"
)

func fetchURL(url string, wg *sync.WaitGroup) {
    defer wg.Done()
    resp, err := http.Get(url)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
    defer resp.Body.Close()
    fmt.Println("URL hit: ", url)
}

func main() {
    var wg sync.WaitGroup
    urls := []string{
        "https://www.google.com",
        "https://www.youtube.com",
        "https://www.amazon.com",
        "https://www.linkedin.com",
    }
    fmt.Println("Start executing goroutines!")
    for _, url := range urls {
        wg.Add(1)
        go fetchURL(url, &wg)
    }
    fmt.Println("Outside of for loop")
    wg.Wait()
    fmt.Println("All goroutines executed successfully!")
}

➜  go run main.go
Start executing goroutines!
Outside of for loop
URL hit:  https://www.youtube.com
URL hit:  https://www.google.com
URL hit:  https://www.amazon.com
URL hit:  https://www.linkedin.com
All goroutines executed successfully!

In the program above, the order of execution of the goroutines is visible in the output. First, the statement before the for loop was executed. Then, inside the for loop, we created four goroutines and before goroutines could finish executing, the for loop exited and the statement after the for loop was executed.

In the above program, we used WaitGroup to synchronise the goroutine execution and block the main goroutine. We incremented the counter by calling wg.Add(1) each time we created a new goroutine. Once a goroutine is completed, we decremented the counter by calling wg.Done(). We used wg.Wait() to pause the main goroutine. wg.Wait() stops the program from continuing until the counter reaches 0, indicating that all goroutines had finished executing.

Mutex & RWMutex

The simultaneous access of shared resources by multiple parallel processes can result in inconsistency in the data or the outcomes of those processes. This inconsistency is referred to as a Race condition.

For example: If a program has multiple goroutines, which are trying to read and write the shared variable. In this case, there is no way to know which goroutine will access the variable first. It may happen that one goroutine is reading that variable and at the same time, another goroutine updates the data on the variable, this may lead to incorrect behaviour of the program. This situation is called a Data Race.

Let's understand it with code:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    count := 0
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            count++
            wg.Done()
        }()
    }
    wg.Wait()
    fmt.Println("Final Count: ", count)
}

In the above example, we've got a count variable that is accessed by all the routines. Now when we run the program we see a different final count. But as we were running for loop 1000 times we should get a count equal to 1000, but that's not the case. There is some inconsistency in the data.

➜  go run main.go       
Final Count:  981
➜  go run main.go
Final Count:  985
➜  go run main.go
Final Count:  979

Run this code in Go Playground

In Go, channels are the preferred way to share data by communicating, but if you must use the shared memory then we need to make sure that Memory Access is Synchronised.

Mutex

To solve the above issue we use Mutex. Mutex stands for mutual exclusion. Mutex is a way to guard or control the Memory Access Synchronization.

In Go, Mutex is implemented as a struct that contains a flag that indicates whether the lock is currently held by a goroutine or not. If the lock is not held, a goroutine can acquire the lock by calling the Lock() method on the Mutex. If the lock is already held by another goroutine, the calling goroutine will be blocked until the lock is released.

When a goroutine holds the lock, it has exclusive access to the shared resource and can modify it without any interference from other goroutines. Once the goroutine is done with the shared resource, it can release the lock by calling the Unlock() method on Mutex.

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    var lock sync.Mutex

    count := 0
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            lock.Lock()
            count++
            lock.Unlock()
            wg.Done()
        }()
    }
    wg.Wait()
    fmt.Println("Final Count: ", count)
}

➜  go run main.go
Final Count:  1000
➜  go run main.go
Final Count:  1000
➜  go run main.go
Final Count:  1000

Run this code in Go Playground

In the above example, we're using a mutex, we're locking and unlocking our critical section of code. We apply a lock before the goroutine accesses the count variable. This way only one goroutine can access the count variable and other goroutines will be waiting for the count variable to be unlocked to gain access. This is how mutex synchronises the shared memory access.

Mutex is useful for scenarios where a shared resource needs to be accessed by multiple goroutines in a mutually exclusive manner. However, it can be inefficient in scenarios where there are many read operations and fewer write operations, as it allows only one goroutine to hold the lock at a time, regardless of whether it is reading or writing. In such scenarios, Go provides a more efficient primitive called RWMutex.

RWMutex

The Go's sync package also provides RWMutex with traditional Mutex. RWMutex stands for Reader/Writer mutual exclusion.

The lock can be held by an arbitrary number of readers or a single writer. - sync package doc.

It is a type of lock that allows multiple readers to access a shared resource concurrently, but only one writer to modify it at a time.

When a reader wants to access the shared resource, it first calls the RLock() method on the RWMutex. This method acquires a read lock, which allows multiple readers to access the resource simultaneously. To release the lock it calls the RUnlock() method. If a writer holds the lock, the reader must wait until the writer releases it.

When a writer wants to modify the shared resource, it calls the Lock() method on the RWMutex. This method acquires a write lock, which prevents other readers and writers from accessing the resource until the writer calls Unlock() and releases the lock. If readers are holding the lock, the writer must wait until all readers have released it.

Let's see an example:

package main

import (
    "fmt"
    "sync"
)

func main() {
    m := &sync.RWMutex{}
    var wg sync.WaitGroup

    for i := 0; i < 5; i++ {
        wg.Add(1)
        go readerFunction(&wg, m)
    }
    wg.Add(1)
    go writerFunction(&wg, m)

    wg.Wait()
}

func writerFunction(wg *sync.WaitGroup, m *sync.RWMutex) {
    defer wg.Done()
    fmt.Println("Writer acquires lock")
    m.Lock()
    m.Unlock()
}

func readerFunction(wg *sync.WaitGroup, m *sync.RWMutex) {
    defer wg.Done()
    fmt.Println("Reader acquires lock")
    m.RLock()
    m.RUnlock()
}

➜  go run main.go
Reader acquires lock
Writer acquires lock
Reader acquires lock
Reader acquires lock
Reader acquires lock
Reader acquires lock

Run this code in Go Playground

Mutex VS RWMutex which one to use?

In scenarios where more read operations need to be performed, then RWMutex is an efficient choice because it lets multiple reader goroutines acquire locks simultaneously. This reduces the waiting time for reader goroutines significantly and expedites the overall execution of the program.

Following is an example that shows the difference in execution time for Mutex and RWMutex programs:

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    m := &sync.Mutex{}
    var wg sync.WaitGroup

    start := time.Now()
    for i := 0; i < 3; i++ {
        wg.Add(1)
        go readerFunction(&wg, m)
    }
    wg.Add(1)
    go writerFunction(&wg, m)

    wg.Wait()
    fmt.Println("Total execution time: ", time.Since(start))
}

func writerFunction(wg *sync.WaitGroup, m *sync.Mutex) {
    defer wg.Done()
    m.Lock()
    m.Unlock()
}

func readerFunction(wg *sync.WaitGroup, m *sync.Mutex) {
    defer wg.Done()
    m.Lock()
    time.Sleep(1 * time.Second)
    m.Unlock()
}

➜  go run main.go
Total execution time:  3.003424166s

Run this code in Go Playground

The above program uses Mutex for synchronisation and it takes 3.003424166s to execute. Let's try the same program with RWMutex.

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    m := &sync.RWMutex{}
    var wg sync.WaitGroup

    start := time.Now()
    for i := 0; i < 3; i++ {
        wg.Add(1)
        go readerFunction(&wg, m)
    }
    wg.Add(1)
    go writerFunction(&wg, m)

    wg.Wait()
    fmt.Println("Total execution time: ", time.Since(start))
}

func writerFunction(wg *sync.WaitGroup, m *sync.RWMutex) {
    defer wg.Done()
    m.Lock()
    m.Unlock()
}

func readerFunction(wg *sync.WaitGroup, m *sync.RWMutex) {
    defer wg.Done()
    m.RLock()
    time.Sleep(1 * time.Second)
    m.RUnlock()
}

➜  go go run main.go
Total execution time:  1.0011145s

Run this code in Go Playground

The above program uses RWMutex for synchronisation and it takes 1.0011145s to execute.

The difference is the execution time is quite significant.

It is important to use RWMutex judiciously because it may not be appropriate for all types of shared resources. For example, if the shared resource is small and is accessed frequently, the overhead of acquiring and releasing locks may outweigh the benefits of using RWMutex. In such cases, other synchronization mechanisms like atomic operations or channels may be more appropriate.

In the next blog, we'll look into cond, once and pool primitives provided by the sync package.

Thank you for reading this blog, and please give your feedback in the comment section below.

Concurrency, asynchronous, parallel and threaded are some keywords we see floating around when we talk about running multiple processes using multiple resources. Although these terms may appear interchangeable in English, they have distinct differences in computer language, particularly at the compiler level and during runtime execution, as well as in their underlying philosophies.

In the software development world, in theory, concurrency and parallelism are considered the same and used interchangeably though they aren't the same. They may have some overlapping similarities but still, they're different. Concurrency is dealing with a lot of things at once and parallelism is doing a lot of things at once.

Concurrency is at the code level, it is a way of structuring the code so that it may use parallelism to run but not necessarily. We can not write parallel code we can only write concurrent code hoping it will run parallel.

For example, if you write a chat application then it needs to be able to handle each message from each user independently without affecting other users. So you structure your program in such a way that employs concurrency. Now suppose you've got a single-core CPU, in this case, the second message will have to wait until the first message is processed but if you have core CPUs then both messages will be processed parallelly.

Go's philosophy of concurrency

It is very important to understand the thought behind Go's pattern of achieving concurrency before we begin to write concurrent code.

Go is a concurrent language. Concurrency primitives are built in Go's core, so it implicitly supports concurrency. Go was designed around CSP. CSP stands for Communicating Sequential Processes. It was introduced by Charles Antony Richard Hoare in 1978 in a paper published by the same name at the Association for Computing Machinery(ACM).

Communicating Sequential Processes

CSP works on three simple rules:

• Write sequential code

  Writing parallel code is not an easy task. We've to use a significant amount of brain power to understand the problem and write in a way that it'll surely run in parallel without getting into any parallel processes running traps such as deadlock or livelock. Instead writing sequential code is easy. We've been doing it all the time.

• Processes will have local state and no shared state

  One of Go's mottos is, Share memory by communicating, don't communicate by sharing memory. So every process will have its local state and no shared state but if the process has to share data with another process then communicate that data instead of using shared memory. This means a process will send a copy of data to another process.

• Scale by adding the same processes

  So once you have a sequential code that can be run independently, then add more of those processes to scale your software.

Go is primarily designed around these CSP primitives but it also supports the traditional way of writing concurrent code using Memory Access Synchronization.

Concurrency building blocks in Go

To write a concurrent program, Go provides us with a toolset:

• Goroutines

• Channels

• Select

• Sync package

Goroutines

Go follows a concurrency model called fork-join. Fork-join means that a program can create a separate branch of execution, or child process, that runs concurrently with its parent process and will eventually rejoin the parent process at a later point in time.

In Go, this forked process or child process can be called a goroutine.

Goroutines are unique to Go. It is one of the basic units of the Go program. It is a lightweight thread of execution that enables concurrent programming.

Goroutines are neither the OS thread nor the green thread, they're abstraction over coroutines. Coroutines are concurrent subroutines that can not be interrupted, they can be suspended or reentered through multiple points in execution. Goroutines are lightweight, cheap and faster at execution than thread.

Every Go program has at least one Goroutine, i.e main goroutine.

go keyword is used to fork a child i.e to create a goroutine in the program.

Here's an example of a goroutine:

package main

import (
    "fmt"
    "net/http"
    "time"
)

func fetchURL(url string) {
    resp, err := http.Get(url)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
    fmt.Println("URL hit: ", url)
    defer resp.Body.Close()
}

func main() {
    urls := []string{
        "https://www.google.com",
        "https://www.youtube.com",
        "https://www.amazon.com",
        "https://www.linkedin.com",    
    }

    for _, url := range urls {
        go fetchURL(url)
    }
    time.Sleep(2 * time.Second)
}

If you run the above program you'll see the output as follows.

➜ go run main.go
URL hit:  https://www.youtube.com
URL hit:  https://www.google.com
URL hit:  https://www.linkedin.com
URL hit:  https://www.amazon.com

A function called with a go keyword, that's all we need to create a block of code that runs concurrently. This is how the first rule of CSP is satisfied, write a sequential process that is capable of running independently.

In the above example, we're creating a goroutine for each URL. time.Sleep() is used to block the main goroutine until all the goroutines are finished execution. Go provides better features, such as channels and sync package to block or to make the parent process wait for goroutines.

Channels

Channels in Go are synchronization primitives of CSP. Channels are widely used for communicating data between goroutines.

Channels can be thought of as a river. Similarly how river functions, a channel functions, as a means of conveying a continuous flow of information. They're typed conduits through which goroutines can safely and efficiently send and receive data.

Creating a channel is very easy. You've to declare a chan variable with the datatype.

Here's an example:

var chanName chan interface{}
chaneName := make(chan interface{})

The above example of creating a bidirectional channel, i.e. we can write to or read from the channel but Go also allows us to create a unidirectional channel.

To create a unidirectional channel we need to use the <- operator. The position of the <- operator decides if the channel is a read channel or a write channel.

Here's an example of a read-only channel that can receive values of the interface{} type.

var chanName <-chan interface{}
chaneName := make(<-chan interface{})

Here's an example of a write-only channel that can send values of the interface{} type.

var chanName chan<- interface{}
chaneName := make(chan<- interface{})

Unidirectional channels are not often instantiated instead, they're used as parameters and return types of functions.

Here's an example:

package main

import (
    "fmt"
    "net/http"
)

func fetchURL(url string, done chan<- bool) {
    resp, err := http.Get(url)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
    fmt.Println("URL hit: ", url)
    defer resp.Body.Close()
    done <- true
}

func main() {
    urls := []string{
        "https://www.google.com",
        "https://www.youtube.com",
        "https://www.amazon.com",
        "https://www.linkedin.com",
    }
    // Create a boolean channel
    done := make(chan bool)
    // Close channel after use
    defer close(done)
    // Create goroutines
    for _, url := range urls {
        go fetchURL(url, done)
    }
    // Block the main goroutine execution
    for i := 0; i < len(urls); i++ {
        <-done
    }
}

This is the same example from the goroutine section. Here we used channels to block the execution of the main goroutine. Channel done is declared as a bidirectional channel in the main but we passed it as a unidirectional channel (only send/write). Go implicitly converted the bidirectional channel to a unidirectional channel.

Method close() is used to close the channel after use. When a closed channel is written to, a panic occurs.

panic: send on closed channel

Closing a channel is not strictly necessary, and there are situations where it is not needed. However, it is a good practice to close channels when they are no longer needed, as it allows the receiving goroutines to exit gracefully and can prevent memory leaks.

Buffered channel

In Go, a buffered channel is a channel with a fixed capacity that allows multiple values of data to be stored. Buffered channels allow us to make n writes, where n is capacity defined, regardless of whether it's being read or not. We can create a buffered channel by passing capacity in integer value to make a function. A buffered channel is an in-memory FIFO queue for concurrent processes to communicate.

Here's an example of a buffered channel:

package main

import (
    "fmt"
    "net/http"
)

func fetchURL(urls []string, done chan<- string) {
    for _, url := range urls {
        resp, err := http.Get(url)
        if err != nil {
            fmt.Println("Error:", err)
            return
        }
        defer resp.Body.Close()
        done <- fmt.Sprintln("URL hit: ", url)
    }
    close(done)
}

func main() {
    urls := []string{
        "https://www.google.com",
        "https://www.youtube.com",
        "https://www.amazon.com",
        "https://www.linkedin.com",
    }
    done := make(chan string, len(urls))
    go fetchURL(urls, done)

    for v := range done {
        fmt.Println(v)
    }
}

In the above example, we created a buffered channel of type string and capacity equal to the length of the slice, in this case, 4. We can use range to fetch the data from the buffered channel. The important thing to notice is that when we use range to fetch data the buffered channel has to be closed once data is populated otherwise for loop will keep on waiting forever.

Select statement

In Go, the select statement is like a switch statement but for channels. It's one of the important features of Go's concurrency. It is used to choose from multiple channel operations that are waiting for information to be sent or received on a particular channel.

Here's a code block showing how to use a select statement.

var c1, c2 <-chan int
select {
case <- c1:
    // Do something
case <- c2:
    // Do something
case <-time.After(2 * time.Second):
        fmt.Println("Timed out.")
        return
default:
    // Do someting until all channels are blocked
}

Even though the select statement looks like a switch statement but its execution is very different. Cases in the select statement do not execute sequentially, instead, all channels are considered simultaneously to check if any of them is ready. If none of the channels is ready then the default block is executed over and over again.

Here's an example of the select statement:

package main

import (
    "fmt"
    "net/http"
)

func fetchURL(url string, urlChan chan<- string) {
    resp, err := http.Get(url)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
    defer resp.Body.Close()
    urlChan <- fmt.Sprintln("URL hit first: ", url)
}

func main() {
    urls := []string{
        "https://www.google.com",
        "https://www.youtube.com",
    }

    googleChan := make(chan string)
    youtubeChan := make(chan string)

    channels := []chan string{googleChan, youtubeChan}

    for i, url := range urls {
        go fetchURL(url, channels[i])
    }

    select {
    case msg := <-googleChan:
        fmt.Println(msg)
    case msg := <-youtubeChan:
        fmt.Println(msg)
    }
}

In the above program, we're trying to hit URLs and then using select to block the execution of the main goroutine. Whichever channel is ready that case will be executed.

➜  go run main.go
URL hit first:  https://www.youtube.com

We can use an infinite for loop to keep on waiting for all channels to be ready or till time out.

package main

import (
    "fmt"
    "net/http"
    "time"
)

func fetchURL(url string, urlChan chan<- string) {
    resp, err := http.Get(url)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
    defer resp.Body.Close()
    urlChan <- fmt.Sprintln("URL hit: ", url)
}

func main() {
    urls := []string{
        "https://www.google.com",
        "https://www.youtube.com",
        "https://www.amazon.com",
        "https://www.linkedin.com",
    }

    googleChan := make(chan string)
    youtubeChan := make(chan string)
    amazonChan := make(chan string)
    linkedinChan := make(chan string)

    channels := []chan string{
        googleChan,
        youtubeChan,
        amazonChan,
        linkedinChan,
    }

    for i, url := range urls {
        go fetchURL(url, channels[i])
    }

    for {
        select {
        case url := <-googleChan:
            fmt.Println(url)
        case url := <-youtubeChan:
            fmt.Println(url)
        case url := <-amazonChan:
            fmt.Println(url)
        case url := <-linkedinChan:
            fmt.Println(url)
        case <-time.After(2 * time.Second):
            fmt.Println("Timed out.")
            return
        }
    }
}

➜ go run main.go
URL hit:  https://www.youtube.com
URL hit:  https://www.linkedin.com
URL hit:  https://www.google.com
URL hit:  https://www.amazon.com
Timed out.

Sync package

In addition to using channels, Go also allows for the more traditional approach of writing concurrent programs that utilize memory access synchronization. The sync package offers various primitives, including WaitGroup, Mutex, RWMutex, Cond, Once, and Pool.

We will explore the sync package in greater detail in a separate blog post.

Thank you for reading this blog, and please give your feedback in the comment section below.

Reference: "Concurrency in Go: Tools and Techniques for Developers" by Katherine Cox-Buday

In the terminal, we type git commands git <sub-command> <flag> it runs if it succeeds we're happy. On a day-to-day basis, we mostly use repetitive commands like git pull <remote> <branch>, git push <remote> <branch>, git commit and many others and sometimes we use prolonged commands like this one git log --graph --pretty=format:'%Cred%h%Creset %Cgreen%cr%Creset -%C(yellow)%d%Creset %s %C(bold blue)[%cn]%Creset' --abbrev-commit --date=relative which prints commit history in a custom fashion.

Typing those repetitive or lengthy, complex commands with too many arguments could be erroneous and could decrease our efficiency ensuing less productivity.

In this article, we'll learn how to run Git commands efficiently and develop a more productive Git workflow using Aliases.

NOTE: The aliases in this article are my personal choice influenced by my day-to-day Git interaction.

What is an alias?

Aliases are short commands assigned to a particular command. It can be visualized as a shortcut for any command.

Creating an alias serves some basic needs:

• It helps to shorten the lengthy command and saves us from tedious, erroneous typing.

• It saves us from memorizing complex commands.

• Creates abridged commands for regularly used commands ensuing in an increase in productivity.

We can use two types of aliases for Git commands:

• Bash alias

• Git alias

We'll look into both.

Bash Alias

Defining a bash alias is a simple task. Below is a command for it.

alias g='git'

And done, we've g as an alias for the git command.

But this alias is not persistent as soon as you end the terminal session the alias is gone. To make it persistent we've to add this alias in .bashrc if you use the bash shell or .zshrc if you use zsh. These files are mostly located in your home directory.

To know what shell you're using type echo

echo "$SHELL"
/usr/bin/zsh

For the git command, I've two bash aliases g and gt. Sometimes due to an old habit, I tend to type git instead of g and while doing that sometimes I miss the i in git so to avoid throwing an error I added gt as an alias in .zshrc.

alias g='git'
alias gt='git'

Git alias

To define a git alias we use the git config command. We can define two types of aliases in Git.

• Global aliases, are stored in .gitconfig file which is mainly located in the home directory. These aliases are available to all git repositories present in the system. Command to define global alias:

    git config --global alias.<alias_name> '<command>'
  

    or you can directly edit the .gitconfig file.
  

• Local aliases, which are stored in .git/config file of the particular project. These aliases are not available to any other repository. Command to define local alias:

    git config alias.<alias_name> '<command>'
  

    or you can directly edit the .git/config file.
  

Some useful git aliases

• Git Status

  git status is a command which is used very frequently to see changed or untracked files.

    git config --global alias.st 'status'
  

  So now instead of git status we can just type git st or g st if bash alias g=git is set. This is the benefit of using aliases, the whole command can be converted into a few characters.

    $ g st
    On branch master
    Your branch is up to date with 'origin/master'.
  
    nothing to commit, working tree clean
  

  The git will store this alias in .gitconfig file under [alias] section as st = status.

• Git Pull

  git pull <remote> <ref/branch> this command pulls the code from a specified remote branch.

    git config --global alias.pl 'pull'
  

  Now the pull command will be git pl <remote> <ref/branch>.

  We can shorten it further depending on the remote and branch.

    git config --global alias.plo 'pull origin'
  

  Now the command git plo main is the same as git pull origin main.

  We can create dedicated alias for git pull origin main

    git config --global alias.plom 'pull origin main'
  

  Now the entire command is abridged, git plom.

• Git Checkout

  git checkout Switch branches or restore working tree files.

    git config --global alias.co 'checkout'
  

  Now we can use git co <branch> to checkout that branch.

  To create a new branch we use git checkout -b <new_branch> <start_point>

    git config --global alias.cnb 'checkout -b'
  

  So now we can use git cnb <new_branch> <start_point>

• Git Branch

  git branch List, create or delete branches

    git config --global alias.br 'branch'
  

    $ git br
  
    * branch1
    main
  

• Git add

  git add <pathspec>... adds file contents to the index

    git config --global alias.a 'add'
  

  The command will be git a <pathspec>...

  To add all the files (changed + untracked) we can do git add .

    git config --global alias.aa 'add .'
  

  Now to add all files we can use git aa

• Git commit

  After adding files to the index we use git commit to record changes to the repository. For git commit alias could be:

    git config --global alias.ci 'commit'
  

    $ git ci
  
    [update.theme 89f083e] Update CR yaml
    1 file changed, 1 insertion(+)
    create mode 100644 cr.yaml
  

• Git push

  Once your changes are committed and you need to update the remote reference with new changes we use git push <remote> <branch>

    git config --global alias.p 'push'
  

  We can shorten it further depending on the remote and branch.

    git config --global alias.po 'push origin'
  

  Now the command git po main is the same as git push origin main.

  We can create dedicated alias for git push origin main

    git config --global alias.pom 'push origin main'
  

  Now the entire command is abridged, git pom.

• Git log

  git log is one of the most important commands in git. It shows us the commit history. Now there are various ways of seeing commit history, depending on how we wanna see commit history we can use the flags.

  I usually use these three aliases for logs.

  This alias shows complete commit logs with the addition and deletion stats.

    git config --global alias.lg 'log --stat'
  

    $ git lg
  
    commit 8b6ac3a9789002a2c578139c830f17b9e18b53f7 (HEAD -> git.aliases, origin/main, origin/HEAD, update.theme)
    Author: Pratik Jagrut <26519653+pratikjagrut@users.noreply.github.com>
    Date:   Sat May 1 21:47:48 2021 +0530
  
        Update public directory
  
    public | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)
  

  This alias draws a text-based graphical representation of the commit history printed in between commits with relative time.

    git config --global alias.lgdr "log --graph --pretty=format:'%Cred%h%Creset %Cgreen%cr%Creset -%C(yellow)%d%Creset %s %C(bold blue)[%cn]%Creset' --abbrev-commit --date=relative"
  

    $ git lgdr
  
    * 8b6ac3a 6 hours ago - (HEAD -> git.aliases, origin/main, origin/HEAD, update.theme) Update public directory [Pratik Jagrut]
    * f47c1c6 6 hours ago - Update theme [Pratik Jagrut]
  

  This alias draws a text-based graphical representation of the commit history printed in between commits with a short format of the date.

    git config --global alias.lgds "log --graph --pretty=format:'%Cred%h%Creset %Cgreen%cr%Creset -%C(yellow)%d%Creset %s %C(bold blue)[%cn]%Creset' --abbrev-commit --date=short
  

    $ git lgds
  
    * 8b6ac3a 2021-05-01 - (HEAD -> git.aliases, origin/main, origin/HEAD, update.theme) Update public directory [Pratik Jagrut]
    * f47c1c6 2021-05-01 - Update theme [Pratik Jagrut]
  

Here's the .gitconfig file for all the above aliases.

[alias]
  st = status
  pl = pull
  plo = pull origin
  plom = pull origin main
  co = checkout
  cnb = checkout -b
  br = branch
  a = add
  aa = add .
  ci = commit
  p = push
  po = push origin
  pom = push origin main
  lg = log --stat
  lgdr = log --graph --pretty=format:'%Cred%h%Creset %Cgreen%cr%Creset -%C(yellow)%d%Creset %s %C(bold blue)[%cn]%Creset' --abbrev-commit --date=relative
  lgds = log --graph --pretty=format:'%Cred%h%Creset %Cgreen%cd%Creset -%C(yellow)%d%Creset %s %C(bold blue)[%cn]%Creset' --abbrev-commit --date=short

These were some of the aliases from my list, you can make more aliases for sub-commands like branch, remote, diff, config, etc...

Conclusion

Git aliases are a very useful feature. They help to improve the overall efficiency and productivity of the git workflow. We can define as many aliases as we want, Git is too generous. It is always good to have aliases for regularly used and lengthy commands.

Thank you for reading this blog, and please give your feedback in the comment section below.

If we don't need a custom type for an error, and we can work with a single error type then we can use errors.New() function to create an error on the fly.

Creating a new error is simple. We simply need to call the New function as shown in the below example:

package main

import (
  "errors"
  "fmt"
)

func division(i, j float32) (interface{}, error) {
  if j == 0 {
    return "", errors.New("ERROR: Division by Zero")
  }
  return i / j, nil
}

func main() {
  if _, err := division(157, 0); err != nil {
    fmt.Println(err)
  }
}

ERROR: Division by Zero

Run the code in Go Playground

NOTE: Each call to the New() function returns a distinct error value even if the text is identical.

The New() function makes it easy to create an error, but how New() function is doing this?

Take a look at the source code of the errors package.

package errors

// New returns an error that formats as the given text.
// Each call to New returns a distinct error value even if the text is identical.
func New(text string) error {
  return &errorString{text}
}

// errorString is a trivial implementation of error.
type errorString struct {
  s string
}

func (e *errorString) Error() string {
  return e.s
}

The New () function takes a string as input and returns the pointer to the type errorString struct that only has one field s string.

The return type of the New() function is error, and the actual returning value is a pointer to the errorString struct. This means type errorString implements error interface.

The implementation of the errors package is pretty straightforward and easy to fathom.

Creating errors with fmt.Errorf() function

Use of errors.New() to create new errors is just fine, but if we want to add more information or context to the error, then New() function is futile because it does not have a built-in string formatting mechanism. We will have to use something like fmt.Spritnf to format our error string and then pass it to the New() function which is just overwork.

The better way to use is fmt.Errorf function.

package main

import (
  "fmt"
)

func division(i, j float32) (interface{}, error) {
  if j == 0 {
    return "", fmt.Errorf("ERROR: Division by Zero\nDividend: %v\nDivisor: %v", i, j)
  }
  return i / j, nil
}

func main() {
  if _, err := division(157, 0); err != nil {
    fmt.Println(err)
  }
}

ERROR: Division by Zero
Dividend: 157.000000
Divisor: 0.000000

Run the code in Go Playground

In the above program, we have replaced errors.New() function with fmt.Errorf(). Now, we can format our error and add new information to it using the Errorf function.

If you look at the implementation of fmt.Errorf() is a bit more complicated than the errors package due to the string formatting feature but at some level fmt.Errorf() function calls the errors.New() function.

So, the common question is when to use fmt.Errorf() and errors.New()? It depends on the behaviour of the error. If the error needs to have any runtime information, like the address stored in a pointer or the time at which an error occurred, then it is a good idea to use fmt.Errorf() which gives the flexibility to format your error as per your need. On the other side, your error is more of a static behaviour or it is a sentinel error and does not need to have any runtime information, then errors.New() is good enough.

Adding context to the error

Sometimes error does not make much sense unless we provide context to it. This context or additional information could be anything like the function where the error occurred or any runtime value.

The general way of adding context to the error is by using fmt.Errorf and %v verb.

package main

import (
  "errors"
  "fmt"
)

var ErrUnauthorizedAccess = errors.New("Unauthorized access")

func isUserAuthorized(uname string) error {
  // some logic to verify user authorization
  authorize := false
  if authorize {
    return nil
  }
  return ErrUnauthorizedAccess
}

func searchFile(fileId int) (interface{}, error) {
  uname := "NotAnAdmin"
  err := isUserAuthorized(uname)
  if err != nil {
    return nil, fmt.Errorf("ERROR: searchFile: %v", err)
  }
  return "Return file", nil
}

func main() {
  _, err := searchFile(10001)
  if err != nil {
    fmt.Println(err)
  }
}

ERROR: searchFile: Unauthorized access

Run the code in Go Playground

In the above example, the original error is ErrUnauthorizedAccess which is then annotated with extra information using fmt.Errorf("ERROR: searchFile: %v", err).

While creating a new error using fmt.Errorf, everything from the original error is discarded except the text. Hence we lose the original error ErrUnauthorizedAccess and the only remnant of the original error is its text Unauthorized access. The below example illustrates this problem:

func main() {
  _, err := searchFile(10001)
  if err == ErrUnauthorizedAccess {
    fmt.Println("Please use the valid authorization token")
  }
}

Run the code in Go Playground

In the above snippet, the error returned from fmt.Errorf is compared to the original error which should be completely valid. But if you run this code, you will see the blank output. This is because the new error has lost the original error and capability to compare it.

To avoid such situations, we can create a custom error type that stores the original error.

package main

import (
  "errors"
  "fmt"
)

var ErrUnauthorizedAccess = errors.New("Unauthorized access")

type serviceError struct {
  fn  string
  err error
}

func (e *serviceError) Error() string {
  return fmt.Sprintf("Error: %v: %v", e.fn, e.err)
}

func isUserAuthorized(uname string) error {
  // some logic to verify user authorization
  authorize := false
  if authorize {
    return nil
  }
  return ErrUnauthorizedAccess
}

func searchFile(fileId int) (interface{}, error) {
  uname := "NotAnAdmin"
  err := isUserAuthorized(uname)
  if err != nil {
    return nil, &serviceError{fn: "searchFile", err: err}
  }
  return "Return file", nil
}

func main() {
  _, err := searchFile(10001)
  if err != nil {
    if errVal, ok := err.(*serviceError); ok && errVal.err == ErrUnauthorizedAccess{
        fmt.Println("Please use the valid authorization token")
    }
  }
}

Please use a valid authorization token

Run the code in Go Playground

In the above program, we've struct serviceError, a custom error type that stores the original error in the err field, and fn field that stores the function name where the error will occur(i.e context of an error). In the main function, we're using type assertion to extract the concrete value of err and using it to compare with the original error.

This block of code is also referred to as the unwrapping of error. Because we're extracting the underlying error.

if errVal, ok := err.(*serviceError); ok && errVal.err == ErrUnauthorizedAccess{
  fmt.Println("Please use the valid authorization token")
}

Wrapping and Unwrapping error

Wrapping of errors means creating a hierarchy of errors by adding context or more information to the error. Consider an onion, and how each upper layer of an onion wraps around the inner layer of the onion. Similarly, one error can wrap up another error, and that error can get wrapped by another error, and so on. We can create a hierarchy of errors which is helpful to form stack trace.

In the above section, we've seen how we added the context to an error using fmt.Errorf is also a kind of error wrapping because it creates a new error over an original error.

In Go1.13, the errors package introduced some new functions to manage errors.

To support wrapping, fmt.Errorf now has a %w verb for creating wrapped errors, 
and three new functions in the errors package ( errors.Unwrap, errors.Is and errors.As) 
simplify unwrapping and inspecting wrapped errors.

Read more in the release note.

Wrapping error

When we used fmt.Errorf and %v to add context to the error we lost the original error. Since Go1.13 fmt.Errorf supports %w a verb whose argument must be an error. When %w is present fmt.Errorf wraps the error and the error is returned by fmt.Errorf will have Unwrap method that will return the argument of %w.

return fmt.Errorf("adding more context: %w", err)

This wrapped error will have access to errors.Is, errors.As and errors.Unwrap methods which will help handle them.

errors.Is

The errors.Is function compares an error to a value. errors.Is(err, error)

This statement

if err == ErrUnauthorizedAccess { ... }

can be replaced by

if errors.Is(err, ErrUnauthorizedAccess) { ... }

In simple terms, the error.Is function behaves like a comparison to a sentinel error.

errors.As

The errors.As function tests whether an error is a specific type. errors.As(err, &e)

This statement

if errVal, ok := err.(*Error); ok { ... }

can be replaced by

var e *serviceError
if errors.As(err, &e) { ... }

err is a *serviceError, and e is set to the error's value

In simple term, errors.As function behaves like type assertion.

errors.Unwrap

Unwrap function is used to extract the underlying or wrapped error.

e2 := fmt.Errorf("adding more context: %w", e1)
errors.Unwrap(e2) // returns e1

NOTE: An error containing another error may implement Unwrap method returning the underlying error. Doing so, will give access to the Is and As methods, without needing to use fmt.Errorf with %w.

package main

import (
  "errors"
  "fmt"
)

var ErrUnauthorizedAccess = errors.New("Unauthorized access")

type serviceError struct {
  fn  string
  err error
}

func (e *serviceError) Error() string {
  return fmt.Sprintf("Error: %v: %v", e.fn, e.err)
}

func (e *serviceError) Unwrap() error { return e.err }

func isUserAuthorized(uname string) error {
  // some logic to verify user authorization
  authorize := false
  if authorize {
    return nil
  }
  return ErrUnauthorizedAccess
}

func searchFile(fileId int) (interface{}, error) {
  uname := "NotAnAdmin"
  err := isUserAuthorized(uname)
  if err != nil {
    return nil, &serviceError{fn: "searchFile", err: err}
  }
  return "Return file", nil
}

func main() {
  _, err := searchFile(10001)
  if err != nil {
    fmt.Println(err)

    if errors.Is(err, ErrUnauthorizedAccess) {
      fmt.Println("Please use valid authorization token")
    }

    var e *serviceError
    if errors.As(err, &e) {
      fmt.Printf("Function %v returned %v error\n", e.fn, e.err)
    }

    fmt.Println(errors.Unwrap(err))
  }
}

Error: searchFile: Unauthorized access
Please use a valid authorization token
Function searchFile returned Unauthorized access error
Unauthorized access

Run the code in Go Playground

In the above program, struct serviceError implements the Error method, which makes it a custom error type. It has an error field and implements the Unwrap method which returns the original error, this lets us call errors.Is and errors.As method on it.

If you remember the previous example, we used this block of code to unwrap the error.

if errVal, ok := err.(*serviceError); ok && errVal.err == ErrUnauthorizedAccess{
  fmt.Println("Please use the valid authorization token")
}

But now, we replaced it by errors.Is

if errors.Is(err, ErrUnauthorizedAccess) {
  fmt.Println("Please use valid authorization token")
}

The same example using fmt.Errorf and %w verb

package main

import (
  "errors"
  "fmt"
)

var ErrUnauthorizedAccess = errors.New("Unauthorized access")

func isUserAuthorized(uname string) error {
  // some logic to verify user authorization
  authorize := false
  if authorize {
    return nil
  }
  return ErrUnauthorizedAccess
}

func searchFile(fileId int) (interface{}, error) {
  uname := "NotAnAdmin"
  err := isUserAuthorized(uname)
  if err != nil {
    return nil, fmt.Errorf("ERROR: searchFile: %w", err)
  }
  return "Return file", nil
}

func main() {
  _, err := searchFile(10001)
  if err != nil {
    fmt.Println(err)

    if errors.Is(err, ErrUnauthorizedAccess) {
      fmt.Println("Please use valid authorization token")
    }

    fmt.Println(errors.Unwrap(err))
  }
}

ERROR: searchFile: Unauthorized access
Please use a valid authorization token
Unauthorized access

Run the code in Go Playground

In software, errors are an inevitable part. We can not ignore them, thinking we'll save the hustle of handling them. But ignoring error means weakening the software instead handle it.

Below are some good reads about error handling.

• Don’t just check errors, handle them gracefully

• Working with Errors in Go 1.13

• Why Go's Error Handling is Awesome

• Return and handle an error

Thank you for reading this blog, and please give your feedback in the comment section below.

In Golang, an error is a value type whose zero value is nil i.e, the error is a built-in type. This coerces developers to treat the error as a first-class citizen. Errors are treated similarly as int, string, bool, etc. An error may return from any function, it may pass as a parameter, and it may store into a variable.

Golang has errors but no exceptions. Its way to handle the exception is not to have an exception in the first place. Please read Dave Cheney's blog about Why Go gets exceptions right.

Golang has support for multiple return values from the function. This feature is primarily used for returning a result and an error. Below is a signature of a Read method from bufio package.

func (b *Reader) Read(p []byte) (n int, err error)

Read the method returns the number of bytes reads into p and returns a variable err of type error. So, for some reason, if this function fails, then the caller will be apprised by returning a custom-defined error. The caller should first inspect the error to determine if an error has occurred or not and only after that returned result should be used. Below is an idiomatic way of handling errors in Golang.

if err != nil {
  // handle error
}

The above block of code is pervasive in Golang based projects. If the error value is not equal to nil that means the function has returned an error. This idiomatic way of handling errors gives us more control over error handling. We can decorate the error and make it more informative. Below is an example of error handling.

package main

import (
  "fmt"
  "os"
)

func main() {
  f, err := os.Open("README.md")
  if err != nil {
    fmt.Println(err)
    os.Exit(1)
  }
  fmt.Println(f.Name(), "opened successfully")
}

open README.md: no such file or directory
Program exited: status 1.

Run the code in Go Playground

In the above program, we are trying to open the README.md file that is not present, so os.Open the function returns an error that we are inspecting and handling.

Representation of error type

In Golang, an error is a built-in type, but actually, the error is an interface type made available globally. It is a single-method interface.

type error interface {
  Error() string
}

Any type that implements the error interface is a valid error. To create a custom error, a type needs to define the Error method. In the above example of the opening file, the error returned from os.Open function was of type \pathError*. pathError is a custom error which implements the error interface.

Create an error type

From the above section, we know that an error is an interface, and any type which implements that interface is an error.

package main

import "fmt"

type httpError struct {
  code   int
  method string
  fn     string
}

func (h *httpError) Error() string {
  return fmt.Sprintf("ERROR:%d:%s:%s", h.code, h.method, h.fn)
}

//Mock function to demo some operation
func getUser(uid int) (interface{}, error) {
  // some business logic
  authorized := false
  if authorized {
    //find user logic
    return "User found", nil
  }
  return "", &httpError{code: 401, method: "GET", fn: "getUser"}
}

func main() {
  _, err := getUser(1)
  if err != nil {
    fmt.Println(err)
  }

  // Inline variant
  // if _, err = getUser(2); err != nil {
  //  fmt.Println(err)
  // }
}

ERROR:401:GET:getUser

Run the code in Go Playground

In the above example, the httpError struct implements the error interface by defining the Error method. getUser is a mock function that mocks the getUser operation.

Here, the main function is the caller for the methods. So the main function is supposed to handle the returned errors. In the main function, this statement _, err := getUser(1) executes the getUser function, stores the error in the err variable and ignores the result using _.

After the function call, the caller is checking if the function is returning an error or not using an if-else statement.

If you see the return type of an error in getUser function is error interface type but the return statement is returning a struct or say the address of the struct variable &httpError{code: 401, method: "GET", fn: "getUser"}.

If the return type of a function and the type of actual return value is different, then how can this function be returning anything?

This is because the type httpError implements the error interface. Under the hood, the interface variable will hold the value and type that implements it.

Another thing to notice is the output.

ERROR:401:GET:getUser

We are passing variable err of type httpError struct to the fmt.Println function, and it is printing nicely documented output, instead of messy struct variables.

How?

This is happening because we have defined the Error method that returns a custom error message string. So under the hood, the fmt.Println function is called the Error method and prints the returned string. So we never have to explicitly call the Error method to get a custom error message.

Handling errors using the type assertion

In the above example, the variable err is of type interface. err variable will not have access to fields of httpError. But err is a variable of error interface and that interface is implemented by type httpError we can use type assertion to extract the underlying concrete value of the interface variable.

In the interfaces blog, we've seen how a type assertion is performed. By extracting this underlying value, we can gain more control over the error value, and we can decide how to return this information to the caller. Below is an illustrative example:

package main

import "fmt"

type httpError struct {
  code   int
  method string
  fn     string
}

func (h *httpError) Error() string {
  return fmt.Sprintf("ERROR: %d:%s:%s\n", h.code, h.method, h.fn)
}

//Mock function to demo some operation
func getUser(uid int) (interface{}, error) {
  // some business logic
  authorized := false
  if authorized {
  //find user logic
  return "User found", nil
  }
  return "", &httpError{code: 401, method: "GET", fn: "getUser"}
}

func main() {
  _, err := getUser(1)
  if err != nil {
    if errVal, ok := err.(*httpError); ok {
      fmt.Printf("Status Code: %d\n", errVal.code)
      fmt.Printf("Method: %s\n", errVal.method)
      fmt.Printf("function returned error: %s\n", errVal.fn)
    }
  }
}

Status Code: 401
Method: GET
function returned error: getUser

Run the code in Go Playground

This one is the same example as the previous one with a small tweak. Instead of printing the err variable, we are performing type assertion on it. Here errVal, ok := err.(*httpError) will return a pointer to the instance of the httpError. Now we can access the fields of the httpError struct using errVal.

In case the underlying error is not of type *httpError, then the ok the variable will be set to false returning control outside the if block.

Handling errors using type switch

Using a type switch we can check the type of error and handle it accordingly. Read more about type switch in the interfaces blog. Below is an illustrative example:

package main

import "fmt"

type fooError struct {
  msg string
}

func (f *fooError) Error() string {
  return fmt.Sprintf("Error: %s", f.msg)

}

type barError struct {
  msg string
}

func (b *barError) Error() string {
  return fmt.Sprintf("Error: %s", b.msg)
}

func doSomething() error {
  return &fooError{"Something is wrong with foo!"}
}

func main() {
  err := doSomething()

  switch err.(type) {
  case nil:
    fmt.Println("Everything is fine.")
  case *fooError:
    fmt.Println("Foo: ", err)
  case *barError:
    fmt.Println("Bar: ", err)
  }
}

Foo:  Error: Something is wrong with foo!

Run the code in Go Playground

In the above example, switch err.(type) will discern the underlying type of the err variable and after comparing it with all the cases, the error will be handled by matched case.

In this blog, we have seen:

• What is an error in Golang?

• How error is represented in Golang?

• Implementing an error interface to create error

• Using type assertion and type switch to extract more information about the error

In the next blog, we'll see more about creating custom errors and handling them gracefully.

Thank you for reading this blog, and please give your feedback in the comment section below.

Type assertion is used to get the underlying concrete value of the interface variable. i.(Type) this is the syntax of type assertion, where:

i -> interface variable

Type -> type that implements the interface

Let's see an example of type assertion.

package main

import "fmt"

type Person interface {
    info() string
}

type Student struct {
    name string
}

func (s Student) info() string {
    return fmt.Sprintf("Student name is %s\n", s.name)
}

func main() {
    s := Student{
        name: "Barry Allen",
    }
    var p Person = s
    name := p.(Student)
    fmt.Println(name)
}

{Barry Allen}

Run this code in Go Playground

In the above example, we create a Person interface which is then implicitly implemented by the Student struct by implementing the info method. var p Person = s this statement creates an interface variable p and assigns Student struct type variable s to it. name := p.(Student) this statement extracts the concrete value of the type Student and assign it to the name variable.

In the above program, type Student implements the Person interface and hence p.(Student) can hold the concrete value of type Student. But if Type from i.(Type) does not implement the interface then Go will throw a compilation error. Below is an illustrative example.

package main

import "fmt"

type Person interface {
    info() string
}

type Student struct {
    name string
}

func main() {
    var p Person
    name := p.(Student)
    fmt.Println(name)
}

./prog.go:15:11: impossible type assertion:
    Student does not implement Person (missing info method)

Run this code in Go Playground

If the Type implements the interface but if the concrete value of that type is not available then Go will panic in runtime.

package main

import "fmt"

type Person interface {
    info() string
}

type Student struct {
    name string
}

func (s Student) info() string {
    return fmt.Sprintf("Student name is %s\n", s.name)
}

func main() {
    var p Person
    name := p.(Student)
    fmt.Println(name)
}

panic: interface conversion: main.Person is nil, not main.Student

goroutine 1 [running]:
main.main()
    /tmp/sandbox657831697/prog.go:19 +0x45

Run this code in Go Playground

Similarly, if the concrete type of interface variable does not match with Type of i.(Type) then the program will panic in runtime.

package main

import "fmt"

type Person interface {
    info() string
}

type Student struct {
    name string
}

func (s Student) info() string {
    return fmt.Sprintf("Student name is %s\n", s.name)
}

type Teacher struct {
    name string
}

func (s Teacher) info() string {
    return fmt.Sprintf("Teacher name is %s\n", s.name)
}

func main() {
    t := Teacher{
        name: "Richard Feynman",
    }
    var p Person = t
    name := p.(Student)
    fmt.Println(name)
}

panic: interface conversion: main.Person is main.Teacher, not main.Student

goroutine 1 [running]:
main.main()
    /tmp/sandbox133075599/prog.go:30 +0x45

Run this code in Go Playground

To avoid the above panic errors Go has another way for type assertion.

value, ok := i.(Type)

In the above syntax, Ok is a boolean variable. It will be false if i.(Type) has no concrete value and vice versa.

package main

import "fmt"

type Person interface {
    info() string
}

type Student struct {
    name string
}

func (s Student) info() string {
    return fmt.Sprintf("Student name is %s\n", s.name)
}

type Teacher struct {
    name string
}

func (s Teacher) info() string {
    return fmt.Sprintf("Teacher name is %s\n", s.name)
}

func main() {
    var p Person
    name, ok := p.(Student)
    fmt.Println(name, ok)

    t := Teacher{
        name: "Richard Feynman",
    }
    var p1 Person = t
    name1, ok1 := p1.(Teacher)
    fmt.Println(name1, ok1)

    name2, ok2 := p1.(Student)
    fmt.Println(name2, ok2)
}

{} false
{Richard Feynman} true
{} false

Run this code in Go Playground

Type switch

Type switch is similar to switch case statements where type switch compares the concrete type of an interface against types specified in cases. Below is the syntax of the type switch:

switch i.(type) {
    case float32:
        // Something to do
    case int:
        // Logic
    default:
        // Default logic
    }

Here i.(type) the syntax is fairly similar to type assertion syntax, where i is interface but instead of value type we use keyword type.

package main

import (
    "fmt"
)

func guessType(i interface{}) {
    switch i.(type) {
    case string:
        fmt.Println("It is string")
    case int:
        fmt.Println("It is Int")
    case bool:
        fmt.Println("It is boolean")
    default:
        fmt.Println("IDK")
    }
}

func main() {
    guessType(10)
    guessType("Hello")
    guessType(true)
    guessType(10.11)
}

It is Int
It is string
It is boolean
IDK

Run this code in Go Playground

In the above example, we're passing an empty interface as an argument to function. The empty interface is implemented by all the types so we can pass any type of parameter while calling that function.

i.(type) evaluates the concrete type of an interface and then a matching case is executed if none of the cases is matched then the default case is executed.

Implementing interfaces using pointer receivers vs value receivers

In Golang methods can have both pointer or value as a receiver which restricts the accessibility of methods only to the type of its receiver. Methods from an interface can be pointers or values as a receiver in their implementation.

Implementing interface with value receiver

package main

import (
    "fmt"
)

type Car interface {
    information()
}

type Ferrari struct {
    name   string
    colour string
}

func (f Ferrari) information() {
    fmt.Printf("Name of the car: %s\n", f.name)
    fmt.Printf("Colour of the car: %s\n", f.colour)
    fmt.Println()
}

func main() {
    var c1 Car

    f := Ferrari{
        name:   "SF90 STRADALE",
        colour: "ROSSO CORSA",
    }
    c1 = f
    c1.information()

}

Name of the car: SF90 STRADALE
Colour of the car: ROSSO CORSA

Run this code in Go Playground

In the above code, type Ferrari is implementing the method information from an interface Car with a value receiver and in the main function, we're assigning the variable f of struct Ferrari to variable c1 of an interface Car and then calling information method using interface variables.

Implementing interface with pointer receiver

package main

import (
    "fmt"
)

type Car interface {
    information()
}
type Porsche struct {
    name   string
    colour string
}

func (p *Porsche) information() {
    fmt.Printf("Name of the car: %s\n", p.name)
    fmt.Printf("Colour of the car: %s\n", p.colour)
    fmt.Println()
}

func main() {

    p := &Porsche{
        name:   "718 SPYDER",
        colour: "BLACK",
    }
    var c2 Car = p
    c2.information()
}

Name of the car: 718 SPYDER
Colour of the car: BLACK

Run this code in Go Playground

In the above code, type Porsche is implementing the method information from an interface Car with a pointer receiver and in the main function we're assigning a variable pointer p of struct Porsche to variable c2 of an interface Car and then calling information method using interface variables.

In Golang, a method with a value receiver or pointer receiver can be called on either value or pointer. It means if you're implementing a method with a value receiver then you can use a value or pointer of that type to call that method.

But in the case of an interface does this phenomenon work?

Calling a method with value receiver on pointer type

In the below code, we implement the method information with value receiver and call it on pointer type.

package main

import (
    "fmt"
)

type Car interface {
    information()
}

type Ferrari struct {
    name   string
    colour string
}

func (f Ferrari) information() {
    fmt.Printf("Name of the car: %s\n", f.name)
    fmt.Printf("Colour of the car: %s\n", f.colour)
    fmt.Println()
}

func main() {
    var c Car
    f1 := &Ferrari{
        name:   "SF90 STRADALE",
        colour: "ROSSO CORSA",
    }
    c = f1
    c.information()
}

Name of the car: SF90 STRADALE
Colour of the car: ROSSO CORSA

Run this code in Go Playground

In the above code, the pointer to value conversion is done by Golang implicitly. It is valid to call a method with value type on any value or anything whose value can be dereferenced.

Calling a method with a pointer receiver on the value type

In the below code, we implement the method information with a pointer receiver and call it on the value type.

package main

import (
    "fmt"
)

type Car interface {
    information()
}

type Porsche struct {
    name   string
    colour string
}

func (p *Porsche) information() {
    fmt.Printf("Name of the car: %s\n", p.name)
    fmt.Printf("Colour of the car: %s\n", p.colour)
    fmt.Println()
}

func main() {
    var c Car

    p := Porsche{
        name:   "718 SPYDER",
        colour: "BLACK",
    }
    c = p
    c.information()

}

./prog.go:29:4: cannot use p (type Porsche) as type Car in assignment:
    Porsche does not implement Car (information method has pointer receiver)

Run this code in Go Playground

In the above code, we're implementing the information method using a pointer receiver and then calling it on value type instead of a pointer, and we're getting a compilation error. So what's happening?

If we look at the implementation of the information method it has a pointer receiver and we're calling it on p which is a value type and does not implement the Car interface. Hence we see the compilation error.

But in Golang, the method with value receiver or pointer receiver can be called on either value or pointer then why is this failing here?

This is because: it is completely valid to call the pointer receiver method using a pointer or using any value whose address can be obtained. In this case, the value type assigned to the interface variable is a concrete value of the interface whose address can not be obtained and hence we get that compilation error.

Note: If we call a method directly with a struct variable then this issue will not occur.

Comparing the interface's variables

The two interface variables are comparable only if the concrete value and concrete type are comparable. Interface variables can be compared with == and != operators.

If the concrete types or concrete values are not the same then the interface variables are not equal. If the concrete types or concrete values are the same then the interface variables are equal. Variables of an empty interface are always equal. Read more on Golang comparison operators.

package main

import "fmt"

type Int int

func (i Int) String() string {
    return fmt.Sprintf("Value of Int is %d", i)
}

type Float float32

func (f Float) String() string {
    return fmt.Sprintf("Value of Float is %f", f)
}

func main() {
    var i Int = 10
    var f Float = 5.5

    var v1 fmt.Stringer = i
    var v2 fmt.Stringer = f

    fmt.Println(v1 == v2) // false, because concrete types are not same

    var i1 Int = 6
    var v3 fmt.Stringer = i1

    fmt.Println(v1 == v3) // false, because concrete values are not same

    var f2 Float = 5.5
    var v4 fmt.Stringer = f2

    fmt.Println(v2 == v4) // true

    var m, n interface{}
    fmt.Println(m == n) // true
}

Run this code in Go Playground

Some good resources to read

Go Data Structures: Interfaces by Russ Cox

The Laws of Reflection by Rob Pike

Thank you for reading this blog, and please give your feedback in the comment section below.

For example, an animal walks, eats and sleeps so we can have an interface Animal which declares the methods walk, eat and sleep and any animal e.g. Tiger, who walks, eats and sleeps so we say Tiger implements the animal interface.

Another example could be of shapes, any shape has an area and perimeter. So the Shape interface can declare area and perimeter methods and any shape such as a rectangle or triangle can implement a shape interface.

It is much similar to the OOP world's interface, where the interface specifies the methods and type decides how to implement them. In OOP programming we might have to use the implement keyword to explicitly implement the interface, but in Golang, if a type defines all the methods from an interface then it implicitly implements interface.

Declaring and Implementing Interface

To declare an interface in Golang we use the type and interface keyword. Below is a syntax:

type InterfaceName interface {
  // Method declaration
}

Stringer the interface is declared in the fmt package, which has a signature of the only one method String.

fmt.Stringer doc

type Stringer interface {
    String() string
}

To implement a particular interface a type needs to implement all the methods with the exact names and signatures defined in that interface. Interfaces in Go are implicitly implemented.

Below is an implementation of the fmt.Stringer interface from the standard library.

package main

import "fmt"

type Person struct {
    name    string
    age     int
    address Address
}

type Address struct {
    city, country string
    pincode       int
}

func (p Person) String() string {
    return fmt.Sprintf("My name is '%s', I'm '%d' years old, I love in '%s', '%s'", p.name, p.age, p.address.city, p.address.country)
}

func main() {
    person := Person{
        name: "James Bond",
        age:  34,
        address: Address{
            city:    "London",
            pincode: 123456,
            country: "UK",
        },
    }

    address := Address{
        city:    "London",
        country: "UK",
        pincode: 123456,
    }

    fmt.Println(person)
    fmt.Println(address)
}

My name is 'James Bond', I'm '34' years old, I love in 'London', 'UK'
{London UK 123456}

Run this code in Go Playground

In the above example, we've two structs one is Person and the other one is Address and only the Person struct implements the Stringer interface by implementing the String() method because of which we could print the custom string format output.

Notice the output, the person variable has its custom string and the address variable prints output in curly braces.

Once a type implements an interface then the method implemented by that type can also be called using an interface variable.

package main

import (
    "fmt"
)

type Shape interface {
    Area()
}

type Square struct {
    side int
}

func (s Square) Area() {
    fmt.Printf("Area of the square is %d\n", s.side*s.side)
}

func main() {
    sq := Square{
        side: 10,
    }
    var sh Shape = sq
    sq.Area()
    sh.Area()
}

Area of the square is 100
Area of the square is 100

Run this code in Go Playground

In the above program, type Square is implementing the Shape interface. In the main function, we call the implemented method Area on variable sq of type Square and on variable sh of type Shape interface and the program still work fine.

Interface's types and values

The variable of an interface stores, a concrete value and the type of that concrete value is called concrete type. This representation can be envisaged as a tuple (type, value). An interface variable can store any concrete type and value as long as that type and value implement the interface's method. The below program illustrates the type and value of the interface.

package main

import "fmt"

type Int int

func (i Int) String() string {
    return fmt.Sprintf("Value of Int is %d", i)
}

type Float float32

func (f Float) String() string {
    return fmt.Sprintf("Value of Float is %f", f)
}

func describe(s fmt.Stringer) {
    fmt.Printf("Concrete type of an interface is %T\n", s)
    fmt.Printf("%v\n", s)
    fmt.Println()
}

func main() {
    var s fmt.Stringer
    describe(s)

    var i Int = 10
    s = i
    describe(s)

    var f Float = 15.0005
    s = f
    describe(f)
}

Concrete type of an interface is <nil>
<nil>

Concrete type of an interface is main.Int
Value of Int is 10

Concrete type of an interface is main.Float
Value of Float is 15.000500

Run this code in Go Playground

In the above program:

We create two customs types Int and Float whose underlying types are int and float32 respectively. Both types implement fmt.Stringer interface by implementing String() string the function.

The statement var s fmt.Stringer creates a variable of an interface fmt.Stringer with zero value <nil>.

In the main function, we assign variables of type Int and Float to the interface variable s. This means when a particular type implements an interface then the variable of that type can also be represented as the type of an interface.

The type and value of the interface depend on the type and which implements that interface. Sometimes the concrete type and value of an interface are also called dynamic type and value. We call it dynamic because we can assign any type to the interface as long as that type implements the interface.

Zero Value of an interface

The zero value of an interface is <nil>. A nil interface has its concrete value and concrete type nil.

package main

import "fmt"

func main() {
    var s fmt.Stringer
    fmt.Printf("The concrete type of a nil interface is %T\n", s)
    fmt.Printf("The concrete value of a nil interface is %v", s)
}

The concrete type of a nil interface is <nil>
The concrete value of a nil interface is <nil>

Run this code in Go Playground

If we try to call a method on a nil interface, the program will panic.

package main

import "fmt"

type Day string

func (day Day) String() string {
    return string(day)
}

func main() {
    var s fmt.Stringer
    fmt.Println("The day is ", s.String())
}

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x497683]

goroutine 1 [running]:
main.main()
    /tmp/sandbox117008893/prog.go:13 +0x23

Run this code in Go Playground

The error pretty much is self-explanatory. The underlying concrete value and type are nil so the method can not be called on that object.

Empty Interface

An interface with zero methods is called an empty interface. The empty interface is represented by interface{}.

Since an empty interface has no methods it is implemented by all the types. Let's dive into an example:

package main

import "fmt"

func getType(s interface{}) {
    fmt.Printf("%T\n", s)
}

func main() {
    i := 10
    getType(i)

    s := "Hola"
    getType(s)

    f := 12.24
    getType(f)

    b := true
    getType(b)
}

int
string
float64
bool

Run this code in Go Playground

The function getType(s interface{}) accepts an empty interface as an argument hence we were able to pass any type of variable to the function.

Have you ever wondered how the Println function can accept any number of values of different different types and print it? The answer is interface{}.

This is the signature of the Println function func Println(a ...interface{}) (n int, err error). The Println function is a variadic function which can take arguments of the type interface{}.

Implementing multiple interfaces

A type can implement more than one interface. Let's see how it is done.

package main

import (
   "fmt"
)

type Shape interface {
   Area()
}

type Quadrilateral interface {
   isQuadrilateral() bool
}

type square struct {
   noOfSides int
   side      int
}

func (s square) Area() {
   fmt.Printf("Area of the square is %d\n", s.side*s.side)
}

func (s square) isQuadrilateral() bool {
   if s.noOfSides == 4 {
       return true
   }
   return false
}

func main() {
   s := square{
       noOfSides: 4,
       side:      10,
   }

   var sh Shape = s
   sh.Area()

   var q Quadrilateral = s
   fmt.Println(q.isQuadrilateral())
}

Area of the square is 100
true

Run this code in Go Playground

In the above example, we've two interfaces Shape and Quadrilateral. Type square implements both interfaces. The program is easy and self-explanatory.

Embedding interfaces

In Golang, one interface can embed any other interface. Golang does not support inheritance but this embedding of interfaces can give a sense of inheritance. Below is an illustrative example:

package main

import (
    "fmt"
)

type Shape interface {
    Area()
}

type Quadrilateral interface {
    Shape
    fmt.Stringer
    isQuadrilateral() bool
}

type square struct {
    noOfSides int
    side      int
}

func (s square) Area() {
    fmt.Printf("Area of the square is %d\n", s.side*s.side)
}

func (s square) isQuadrilateral() bool {
    if s.noOfSides == 4 {
        return true
    }
    return false
}

func (s square) String() string {
    return fmt.Sprintf("Number of sides are %d and dimension of side is %d", s.noOfSides, s.side)
}

func main() {
    s := square{
        noOfSides: 4,
        side:      10,
    }
    var q Quadrilateral = s
    fmt.Println(s.String())
    s.Area()
    fmt.Println(q.isQuadrilateral())
}

Number of sides are 4 and dimension of side is 10
Area of the square is 100
true

Run this code in Go Playground

In the above example, we have Shape and fmt.Stringer interfaces which are embedded in the Quadrilateral interface. The type square implements method from Shape, fmt.Stringer and Quadrilateral interfaces. In the main function, we're creating a variable of type square and assigning it to the variable of the Quadrilateral interface. After that, we're calling all the methods implemented by type square using only the variable of the Quadrilateral interface.

Thank you for reading this blog, and please give your feedback in the comment section below.

Go allows us to use a struct as a field of another struct, this pattern is called nesting. A nested struct can be defined using the following syntax.

type struct1 struct{
    // fields
}

type struct2 struct{
    // fields
    s struct1
}

Suppose we need to collect the data of a person, the person's name, age and address. In the address, we need to collect the city and country of that person. So we can do this using nested structs as shown below:

package main

import "fmt"

type Person struct {
    name    string
    age     int
    address Address
}

type Address struct {
    city, country string
}

func main() {
    person := &Person{
        name: "James Bond",
        age:  34,
        address: Address{
            city:    "London",
            country: "UK",
        },
    }

    fmt.Printf("%#v", person)
}

&main.Person{name:"James Bond", age:34, address:main.Address{city:"London", country:"UK"}}

Run this code in Go Playground

Accessing fields of nested struct

To access the fields of nested structs we can do structObj1.structObj2.structObj3........fieldName.

Below is an example:

package main

import "fmt"

type Person struct {
    name    string
    age     int
    address Address
}

type Address struct {
    city, country string
}

func main() {
    person := &Person{
        name: "James Bond",
        age:  34,
        address: Address{
            city:    "London",
            country: "UK",
        },
    }

    fmt.Printf("Name: %v\n", person.name)
    fmt.Printf("Age: %v\n", person.age)
    fmt.Printf("City: %v\n", person.address.city)
    fmt.Printf("Country: %v\n", person.address.country)
}

Name: James Bond
Age: 34
City: London
Country: UK

Run this code in Go Playground

Promoted fields

When the struct has another struct as an anonymous field then fields of anonymous structs are called promoted fields. This means we can access the fields of the nested struct without using the object of the nested struct, we can access them just by using the parent struct.

For example:

package main

import "fmt"

type Person struct {
    name string
    age  int
    Address
}

type Address struct {
    city, country string
}

func main() {
    person := &Person{
        name: "James Bond",
        age:  34,
        Address: Address{
            city:    "London",
            country: "UK",
        },
    }

    fmt.Printf("Name: %v\n", person.name)
    fmt.Printf("Age: %v\n", person.age)
    fmt.Printf("City: %v\n", person.city) // Instead of person.address.city we used person.city
    fmt.Printf("Country: %v\n", person.country) // Instead of person.address.country we used person.country
}

Name: James Bond
Age: 34
City: London
Country: UK

Run this code in Go Playground

Only unique fields of nested anonymous struct gets promoted.

If the parent struct and nested anonymous struct have the same name field then that field will not be promoted.

package main

import "fmt"

type Person struct {
    name string
    age  int
    City
}

type City struct {
    name, country string
}

func main() {
    person := &Person{
        name: "James Bond",
        age:  34,
        City: City{
            name:    "London",
            country: "UK",
        },
    }

    fmt.Printf("Name: %v\n", person.name)
    fmt.Printf("Age: %v\n", person.age)
    fmt.Printf("City: %v\n", person.City.name)
    fmt.Printf("Country: %v\n", person.country)
}

Run this code in Go Playground

In this example, we have City a nested anonymous struct, whose fields are name and country. The name the field is also available in the Person struct. So when we try person.name then the compiler will give us access to the Person's name field by default hence to access the name field from the City struct we've to do person.City.name. The country field from City struct is unique here so we can just access it by using person.country.

Comparing struct

Structs in Go are value type and so they can be compared.

Two struct values may be equal if:

• They're of the same type.

• Their corresponding fields are equal.

• Their corresponding fields should be comparable.

For example:

package main

import "fmt"

type Person struct {
    name string
    age  int
}

func main() {
    p1 := Person{
        name: "James Bond",
        age:  34,
    }

    p2 := Person{
        name: "James Bond",
        age:  34,
    }

    fmt.Println(p1 == p2) // true
}

Run this code in Go Playground

Comparing pointers to the struct will always be false, we need to compare dereferenced pointer values.

package main

import "fmt"

type Person struct {
    name string
    age  int
}

func main() {
    p1 := &Person{
        name: "James Bond",
        age:  34,
    }

    p2 := &Person{
        name: "James Bond",
        age:  34,
    }
    fmt.Println(p1 == p2) // false
    fmt.Println(*p1 == *p2) // true
}

Run this code in Go Playground

If structs contain incomparable values then struct values can not be compared using == operator, it will throw an error.

package main

import "fmt"

type Person struct {
    name     string
    age      int
    measures map[string]float32
}

func main() {
    p1 := Person{
        name: "James Bond",
        age:  34,
        measures: map[string]float32{
            "Height": 183,
            "Weight": 76,
        },
    }

    p2 := Person{
        name: "James Bond",
        age:  34,
        measures: map[string]float32{
            "Height": 183,
            "Weight": 76,
        },
    }
    fmt.Println(p1 == p2)
}

./prog.go:30:18: invalid operation: p1 == p2 (struct containing map[string]float32 cannot be compared)

In the above code, a map is used as a field in a struct and a map is an incomparable type. To compare such structs we can use reflect.DeepEqual() function.

package main

import (
    "fmt"
    "reflect"
)

type Person struct {
    name     string
    age      int
    measures map[string]float32
}

func main() {
    p1 := Person{
        name: "James Bond",
        age:  34,
        measures: map[string]float32{
            "Height": 183,
            "Weight": 76,
        },
    }

    p2 := Person{
        name: "James Bond",
        age:  34,
        measures: map[string]float32{
            "Height": 183,
            "Weight": 76,
        },
    }
    fmt.Println(reflect.DeepEqual(p1, p2)) // true
}

Run this code in Go Playground

Structs and methods/receiver function

Golang supports both function and method. A method is a function that is defined for a particular type or with a receiver. A method in Golang is also called a receiver function. Following is the example.

package main

import "fmt"

type Person struct {
    name string
    age  int
}

func (p Person) GetInfo() string {
    return fmt.Sprintf("\"%v\" is \"%v\" years old.", p.name, p.age)
}

func main() {
    p := Person{
        name: "James Bond",
        age:  34,
    }

    fmt.Println(p.GetInfo())
}

"James Bond" is "34" years old.

Run this code in Go Playground

We can also use a pointer as the receiver of the method. The difference between value as receiver and pointer as a receiver is, golang passes everything as value and hence in value receiver the function will get a copy of the struct and function will not touch the original struct whereas in pointer as a receiver function will get a copy of a pointer which will be pointing to an original struct.

The below examples illustrate the difference between a pointer and a value as a receiver.

package main

import "fmt"

type Person struct {
    name string
    age  int
}

// Value as receiver
func (p Person) UpdateAge(age int) {
    p.age = age
}

// Pointer as receiver
func (p *Person) UpdateName(name string) {
    p.name = name
}

func main() {
    p := Person{
        name: "James Bond",
        age:  34,
    }

    // Value as receiver example
    fmt.Println("Age before update: ", p.age)
    p.UpdateAge(24)
    fmt.Println("Age after update: ", p.age)

    fmt.Println()

    // Pointer as receiver
    fmt.Println("Name before update: ", p.name)
    p.UpdateName("Jon Snow")
    fmt.Println("Name after update: ", p.name)
}

In above example UpdateAge() is using value as the receiver and UpdateName() is using pointer as a receiver.

Age before update:  34
Age after update:  34

Name before update:  James Bond
Name after update:  Jon Snow

Run this code in Go Playground

Empty Struct

In Golang, we can have an empty struct. A struct without any field is called an empty struct. Below is the signature of an empty struct.

type T struct{}
var s struct{}

Empty struct does not have any field so it does not occupy any memory i.e it occupies zero bytes of storage.

var s struct{}
fmt.Println(unsafe.Sizeof(s)) // prints 0

We can create an array of the empty struct and still it occupies zero bytes.

var arr [100000]struct{}
fmt.Println(unsafe.Sizeof(arr)) // prints 0

The slice of structs will consume some bytes just to store the pointer, length and capacity of an underlying array but structs still will be of zero bytes.

sls := make([]struct{}, 100000)
fmt.Println(unsafe.Sizeof(sls)) // prints 24

package main

import (
    "fmt"
    "unsafe"
)

func main() {
    var s struct{}
    fmt.Println("Size of an empty struct: ", unsafe.Sizeof(s)) // prints 0

    var arr [100000]struct{}
    fmt.Println("Size of an array of an empty struct: ", unsafe.Sizeof(arr)) // prints 0

    sls := make([]struct{}, 100000)
    fmt.Println("Size of a slice of an empty struct: ", unsafe.Sizeof(sls)) // prints 24
}

Size of an empty struct:  0
Size of an array of an empty struct:  0
Size of a slice of an empty struct:  24

Run this code in Go Playground

Read more about the empty struct and its use cases at Dave Cheney's blog.

Array/Slice of structs

The Array/Slice is a collection of the same type of element in a contiguous memory location. We can create an array/slice of structs.

package main

import "fmt"

type Person struct {
    name string
    age  int
}

func newPerson(name string, age int) *Person {
    return &Person{
        name: name,
        age:  age,
    }
}

func main() {
    people := make([]*Person, 0) // slice of a struct Person with initial length 0

    people = append(people, newPerson("James Bond", 34))
    people = append(people, newPerson("Jon Snow", 24))
    people = append(people, newPerson("Joey Tribbiani", 32))

    for _, person := range people {
        fmt.Println(person)
    }

    fmt.Println("Name of friends character: ", people[2].name)
}

&{James Bond 34}
&{Jon Snow 24}
&{Joey Tribbiani 32}
Name of friends character:  Joey Tribbiani

Run this code in Go Playground

Thank you for reading this blog, and please give your feedback in the comment section below.

A struct is a sequence of named elements, called fields, each of which has a name and a type. Field names may be specified explicitly (IdentifierList) or implicitly (EmbeddedField). Within a struct, non-blank field names must be unique. From golang docs.

In simple words, a struct is a user-defined type that allows the collection of different types of elements. These elements are called fields. Structs can be used to keep certain data together. A struct is a very popular and widely used user-defined type in golang.

Struct Declaration and Initialization

A struct is defined using keywords type and struct. The type keyword is used to define user-defined data types and the struct keyword specifies that it's a struct.

type Person struct {
    name    string
    age     int
}

To use the struct we create a struct object.

var p Person or shorthand p := Person{} will create an object of struct Person and will initialize its field with the zero-value of their type.

package main

import "fmt"

type Person struct {
    name    string
    age     int
}

func main() {
    var p Person
    fmt.Printf("%#v", p)

    p1 := Person{}
    fmt.Printf("%#v\n", p1)
}

main.Person{name:"", age:0}
main.Person{name:"", age:0}

%#v a Go-syntax representation of the value.

Run this code in Go Playground

Struct literals

Creating a struct object with specifying field names

p := Person{name: "Jon Snow", age: 24}
p1 := Person{
    name: "Jon Snow",
    age:  24,
}

The order of the field does not matter when specifying field names

p := Person{age: 24, name: "Jon Snow"}

Creating a struct object without specifying field names

p := Person{"Jon Snow", 24}
p1 := Person{
  "Jon Snow",
  24,
}

package main

import "fmt"

type Person struct {
    name string
    age  int
}

func main() {
    p := Person{name: "Jon Snow", age: 24}
    fmt.Printf("%#v\n", p)

    p1 := Person{"Jon Snow", 24}
    fmt.Printf("%#v\n", p1)

    p2 := Person{
        name: "Jon Snow",
        age:  24,
    }
    fmt.Printf("%#v\n", p2)

    p3 := Person{
        "Jon Snow",
        24,
    }
    fmt.Printf("%#v\n", p3)
}

Run this code in Go Playground

Accessing struct fields

To access individual fields of the struct, . (dot) operator is used. e.g.struct.fieldname.

To use the value present in a struct field.

value := struct.fieldname

To assign a new value to the struct field

struct.fieldname = value

The below example demonstrates how to access the struct fields.

package main

import "fmt"

type Person struct {
    name string
    age  int
}

func main() {
    p := Person{name: "Jon Snow", age: 24}
    fmt.Printf("Name of the person: %v\n", p.name)
    fmt.Printf("Age of the person: %v\n", p.age)

    p.age = 30
    fmt.Printf("Updated age of the person: %v\n", p.age)
}

Name of the person: Jon Snow
Age of the person: 24
Age of the person: 30

Run this code in Go Playground

Pointer to the struct

Pointers are special variable that stores the address of another variable. We can store the address of a struct object in a pointer by passing the memory address using & operator.

package main

import "fmt"

type Person struct {
    name string
    age  int
}

func main() {
    // First way of creating pointer to struct
    personPtr := &Person{name: "James Bond", age: 32}
    fmt.Println(personPtr)
    fmt.Println(*personPtr) // Dereferencing the struct pointer

    fmt.Printf("Age of \"%v\" is \"%v\" \n", (*personPtr).name, (*personPtr).age)

    fmt.Println()
    // Second way of creating pointer to struct
    person := Person{name: "Jon Snow", age: 24}
    ptr := &person
    fmt.Println(ptr)
    fmt.Println(*ptr) // Dereferencing the struct pointer

    fmt.Printf("Age of \"%v\" is \"%v\" \n", (*ptr).name, (*ptr).age)
}

&{James Bond 32}
{James Bond 32}
Age of "James Bond" is "32" 

&{Jon Snow 24}
{Jon Snow 24}
Age of "Jon Snow" is "24"

Run this code in Go Playground

In the above program, we're accessing the struct field by dereferencing the pointer (*ptr).name, (*ptr).age which reduces the readability and makes a program a little unkempt. The Golang also allow us to access fields of the struct without dereferencing the pointer as shown in the below example.

package main

import "fmt"

type Person struct {
    name string
    age  int
}

func main() {
    // First way of creating pointer to struct
    person := &Person{name: "James Bond", age: 32}
    fmt.Println(person)
    fmt.Printf("Age of \"%v\" is \"%v\" \n", person.name, person.age)
}

&{James Bond 32}
Age of "James Bond" is "32"

Run this code in Go Playground

In the above program, we're accessing the field using person.name, person.age.

Anonymous Struct and anonymous fields

Anonymous Struct

In Golang we're allowed to create a struct without a name such a struct is called an anonymous struct. This kind of struct is useful if we want to use the struct only once in the program. We can create a struct using the following syntax:

variable := struct{
    // field
}{
    // field value
}

// OR

PtrVariable := &struct{
    // field
}{
    // field value
}

Below is an example of an anonymous struct.

package main

import "fmt"

func main() {
    person := struct {
        name string
        age  int
    }{
        name: "James Bond",
        age:  32,
    }
    fmt.Println(person)

    ptrPerson := &struct {
        name string
        age  int
    }{
        name: "Jon Snow",
        age:  24,
    }
    fmt.Println(ptrPerson)
}

{James Bond 32}
&{Jon Snow 24}

Run this code in Go Playground

Anonymous fields

In Golang we're allowed to define anonymous fields in a struct. Anonymous fields are fields without a name. We just need to define the type of the field and Go will use that type as the name of that field. Below is the syntax of anonymous fields

type structName struct{
    // value type
    string
    int
    bool
}

package main

import "fmt"

type Person struct {
    string
    int
}

func main() {
    person := &Person{
        "James Bond", 
        32,
    }
    fmt.Println(person)

    fmt.Printf("Age of \"%v\" is \"%v\" \n", person.string, person.int)
}

&{James Bond 32}
Age of "James Bond" is "32"

Run this code in Go Playground

In the above example, we access the anonymous fields by using value type as the name of the field person.string, person.int.

It is not allowed to define anonymous fields of the same type more than once.

Variables are used to store some type of data. All variables are assigned a particular memory where they store data and this memory has a memory address that is in hexadecimal format. The number that starts with 0x is hexadecimal like (0x14 which is equivalent to 20 in decimal). Golang allows us to store this memory address in variables but only pointers will understand that the stored value is pointing to some memory whereas other variables will treat it just as a value.

Declaring Pointer

The type *T is a pointer to a T value. Its zero value is <nil>.

var pointer_name *Data_Type
var p *int = &variable

In the above snippet, you can see two symbols * and &, which are two operators.

* Operator is also called dereferencing operator which is used to declare an operator and also to access the value stored at the memory address pointer pointing to.

& Operator this operator is used to access the memory address of a variable.

Below is an example demoing the use of * and &.

package main

import "fmt"

func main() {
  i := 42

  var p *int = &i

  fmt.Println("The value of i is: ", *p)
  fmt.Println("The memory address of i is", p)
}

The value of i is:  42
The memory address of i is 0xc00002c008

Run this code in Go Playground

Shorthand Declaration

In Golang shorthand declaration(:=) is used to narrow down the variable declaration. The Golang compiler will decide if the RHS variable is a pointer variable if we're assigning the memory address of the LHS variable using &.

i := 42
p := &i

Declaring pointer with the new function

Golang has a built-in allocating primitive function called new. The new(T) allocates memory, initializes it with a zero value of type T and returns the pointer to that memory. In Go terminology, it returns a pointer to a newly allocated zero value of type T.

What is the difference between var p *int and p := new(int)?

The expression var p *int only declares the pointer and does not initialize it with any memory address, i.e pointer does not point to any memory location. Whereas in new(T) function returns the pointer pointing to the memory location in the system.

package main

import "fmt"

func main() {
  var p *int
  fmt.Println("The value of p", p)

  p1 := new(int)
  fmt.Println("The value of *p1 is: ", *p1)
  fmt.Println("The value of p1", p1)
}

The value of p <nil>
The value of *p1 is:  0
The value of p1 0xc00002c008

In the above example, we can not dereference the pointer p because it has <nil> value. Trying to dereference it will throw an error.

panic: runtime error: invalid memory address or nil pointer dereference

Run this code in Go Playground

Passing a pointer to the function

We can pass a pointer to the function as we pass other variables. We can create a pointer to the variable and then pass it to the function or we can just pass an address of that variable using &.

In the below example, we initialize a variable i with the value 10. We have a function addTen(i *int) which takes a pointer as an argument and then adds 10 by dereferencing the pointer hence mutating the original value.

package main

import "fmt"

func addTen(i *int) {
  *i = *i + 10
}

func main() {
  i := 10
  p := &i
  fmt.Println(i)
  addTen(p) // Pass a pointer
  fmt.Println(i)
  addTen(&i) // Pass address using & operator
  fmt.Println(i)
}

10
20
30

Run this code in Go Playground

Pass-by-value vs Pass-by-pointer

When we write a function we decide parameters to be passed by-value or by-pointer.

Pass by value

Every time variable is passed as a parameter a new copy of that variable is created and passed to the function. This copy has a different memory location hence any changes to this copy will not affect the original variable.

In the below example, we pass the parameter by value.

package main

import "fmt"

func add(i int) {
  i = i + 10
  fmt.Println("Variable copy from add function:", i)
}

func main() {
  i := 10
  fmt.Println("Original variable:", i)
  add(i)
  fmt.Println("Original variable:", i)
}

Original variable: 10
Variable copy from add function: 20
Original variable: 10

Run this code in Go Playground

Pass by Pointer

When we pass the parameter by-pointer Go makes a copy of that pointer to the new location. This pointer copy has the same memory address stored in it hence it is pointing to the original variable and any changes done using this pointer will change the value of the original variable.

package main

import "fmt"

func add(i *int) {
  *i = *i + 10
  fmt.Println("Variable copy from add function:", *i)
}

func main() {
  i := 10
  fmt.Println("Original variable:", i)
  add(&i)
  fmt.Println("Original variable:", i)
}

Original variable: 10
Variable copy from add function: 20
Original variable: 20

Run this code in Go Playground

In some way, we can say that pass-by-pointer is an implementation of pass-by-value.

Container types(slices, maps etc) and pointers

package main

import (
    "fmt"
)

func modify(h map[int]int) {
    h[1] = 5
    fmt.Println("Modified map: ", h)

}

func main() {
    m := make(map[int]int)
    m[1] = 1
    m[2] = 2
    m[3] = 3
    fmt.Println("Original map: ", m)
    modify(m)
    fmt.Println("Original map: ", m)
}

In the above example, we're creating a map and passing it to the modify function. With the cursory look, it seems like we're passing an argument by-value because we're not passing the address of map m using & or by creating a pointer to map m. So this means the copy of map m should be created and the original map is untouched. But if we run this we get an output as follows.

Original map:  map[1:1 2:2 3:3]
Modified map:  map[1:5 2:2 3:3]
Original map:  map[1:5 2:2 3:3]

Run this code in Go Playground

We passed an argument by value then why did the original map was updated?

When we create a map using m := make(map[int]int) the compiler makes a call to the runtime.makemap a function whose signature is as func makemap(t *maptype, hint int, h *hmap) *hmap.

So as we see, the return type of runtime.makemap is a pointer to the runtime.hmap structure. So when we passed a map to the function we actually passed a pointer to the runtime.hmap structure of map m and hence the original map was modified.

Instead of mapping if we try the above program using slice we will get a similar output because the slice variable stores the pointer to an underlying array.

Thank you for reading this blog, and please give your feedback in the comment section below.

The closure is a special type of function value which references a variable declared outside its body. The purpose of this function is to close over a variable of the upper function to form a closure. The function may access and assign to the referenced variables; in this sense, the function is "bound" to the variables.

Let's see an example. In this example, we create a closure which keeps track of the page hit or as a counter.

package main

import "fmt"

func main() {
    hit := 0

    counter := func() int {
        hit += 1
        return hit
    }

    fmt.Println(counter())
    fmt.Println(counter())
    fmt.Println(counter())
}

Run this code in Go Playground

In the above example, we bound the closure to the hit variable which is not passed to it but accessed as a global variable.

The problem with the above code is, hit is a global variable. Hence another function has access to it. So any other operation can change the value of hit. To avoid this closure can isolate the data.

package main

import "fmt"

func main() {
    counter := Counter()
    fmt.Println(counter())
    fmt.Println(counter())
    fmt.Println(counter())
}

func Counter() func() int {
    hit := 0
    return func() int {
        hit++
        return hit
    }
}

Run this code in Go Playground

In the above example, closure is bound to or references to the hit variable which is still can be accessed after the function call. This means closure has access to the data and no other function has access to it hence this data can be tracked and isolated. This is one of the benefits of closure.

Some closure use cases

Isolating the data

Suppose we want to create a function that persists data after the functional call exists. For example, we create a Fibonacci series generator where we want to keep all variables away from the user's eye, so no one can manipulate it.

package main

import "fmt"

func fibonacci() func() int {
    n1 := 0
    n2 := 1
    return func() int {
        n1, n2 = n2, (n1 + n2)
        return n1
    }
}

func main() {
    f := fibonacci()
    fmt.Println(0)
    for i := 0; i < 10; i++ {
        fmt.Println(f())
    }
}

Run this code in Go Playground

Search in sorting package

A common use of Search is to find the index i for a value x in a sorted, indexable data structure such as an array or slice. In this case, the argument f, typically a closure, captures the value to be searched for, and how the data structure is indexed and ordered.

func Search(n int, f func(int) bool) int

package main

import (
    "fmt"
    "sort"
)

func main() {
    nums := []int{1, 3, 6, 8, 10, 15, 21, 28, 36, 45, 55}
    x := 8

    i := sort.Search(len(nums), func(i int) bool {
        return nums[i] >= x
    })
    fmt.Printf("Index of %d is %d", x, i)
}

Run this code in Go Playground

Thank you for reading this blog, and please give your feedback in the comment section below.

Declaring the anonymous function

The syntax is pretty straightforward and much similar to normal function.

func(parameter_list)(return_type){
  return
}()

Parameter list and return type are optional.

() this will invoke the function as soon as it is defined.

package main

import "fmt"

func main() {
    func() {
        fmt.Println("Golang Rocks!")
    }()
}

Run this code in Go Playground

Assigning an anonymous function to a variable

In Go, you can assign an anonymous function to a variable. The assigned variable will be of function type and it can be called as a regular function.

package main

import "fmt"

func main() {
    v := func() {
        fmt.Println("Golang Rocks!")
    }
    fmt.Printf("Type of variable v: %T\n", v)
    v()
}

Type of variable v: func()
Golang Rocks!

Run this code in Go Playground

Passing an argument to an anonymous function

An anonymous function can take any number of arguments similar to a regular function.

package main

import "fmt"

func main() {
    func(name string) {
        fmt.Println("Hello, ", name)
    }("Jack")
}

Run this code in Go Playground

With any number of trailing arguments similar to Variadic functions

package main

import "fmt"

func main() {
    func(i ...int) {
        fmt.Println(i)
    }(1, 2, 3, 4)
}

Run this code in Go Playground

Passing an anonymous function as an argument

You can pass an anonymous function as an argument to a regular function or an anonymous function.

• Anonymous functions as an argument to a regular function

package main

import "fmt"

func sayHello(af func(s string) string) {
    fmt.Println(af("Jack"))
}

func main() {

    sayHello(func(s string) string {
        return "Hello, " + s
    })
}

Run this code in Go Playground

• Anonymous function as an argument to an anonymous function

package main

import "fmt"

func main() {
    func(v string) {
        fmt.Println(v)
    }(func(s string) string {
        return "Hello, " + s
    }("Jack"))
}

Run this code in Go Playground

This above code looks a bit complicated and hard to fathom so another way we can achieve this is the following:

package main

import "fmt"

func main() {
    af := func(s string) string {
        return "Hello, " + s
    }

    func(af func(s string) string) {
        fmt.Println(af("Jack"))
    }(af)
}

Run this code in Go Playground

Return an anonymous function from another function

We can return an anonymous function from another function

• Returning from regular function

package main

import "fmt"

func sayHello() func(s string) string {
    r := func(s string) string {
        return "Hello, " + s
    }
    return r
}

func main() {
    f := sayHello()
    fmt.Printf("Type of variable f: %T\n", f)
    fmt.Println(f("Jack"))
}

Run this code in Go Playground

• Returning from the anonymous function

package main

import "fmt"

func main() {
    f := func() func(s string) string {
        r := func(s string) string {
            return "Hello, " + s
        }
        return r
    }

    fmt.Printf("Type of variable f: %T\n", f)
    c := f()

    fmt.Printf("Type of variable c: %T\n", c)
    fmt.Println(c("Jack"))
}

Run this code in Go Playground

Thank you for reading this blog, and please give your feedback in the comment section below.