DEV Community: Hamed Naeemaei

Start monitoring like a pro, learn the heartbeat of your services, Part 1

Hamed Naeemaei — Thu, 17 Jul 2025 23:03:13 +0000

🟡 Why Monitoring Matters

In today’s digital world, software services run 24/7. And when something goes wrong, seconds can cost businesses money, trust, and peace of mind. Monitoring is not just about catching errors — it’s about understanding your systems in motion.
That’s where Prometheus and Grafana step in.

This multi-part article series will walk you through the practical implementation of a full monitoring stack using Prometheus for metrics collection and Grafana for visualization — with real Web API services and real metrics.

🟡 What We’ll Build? (Overview)

Spin up multiple Web API instances
Collect realistic metrics from them
Store those metrics in Prometheus
Build beautiful and functional dashboards in Grafana
Explore PromQL and alerting scenarios
Learn through hands-on, containerized environments

The full code is available on GitHub:
👉 https://github.com/naeemaei/MonitoringExample

Just run this from the project root:

docker-compose -f Prometheus/docker-compose.yml up -d --build

🟡 What You’ll Need

Visual Studio Code
Docker and Docker Compose

🟡 What is a Time Series Database (TSDB)?

A Time Series Database (TSDB) is a specialized type of database optimized for storing, retrieving, and managing time-stamped data. Unlike traditional relational databases, TSDBs are designed to efficiently handle sequences of data points indexed in time order. With examples from the real world, we can clarify the matter better:

Take a look at your smartwatch. It continuously displays your heart rate in real time. Now, imagine you want to store that heart rate data over an extended period, say, a full month. How should we structure that data?
At the core, we have a primary dimension: time (our key), and a value, which is the heart rate at that specific timestamp. This structure is a timestamp paired with a single numeric value should remind you of a time series model.
But that’s just the beginning.
We might also want to associate additional context with each data point. For instance:
The city where the user is located in?
The user’s activity state: sleeping, awake, walking, or working out
With this richer dataset, we can ask powerful questions, like:
What’s the average heart rate of a person while sleeping in a coastal city compared to a mountain region?
How does the heart rate fluctuate at the onset of sleep, during deep sleep, and upon waking?
What was the average heart rate in the past hour?
Sound familiar? It should — modern smartwatches and smartphones already collect this kind of data. They track your steps, your sleep cycles, and your movement, and then generate daily summaries and health insights.
But here’s the real question:
How can we store and structure this kind of data so that it’s not only easy to monitor in real-time, but also easy to analyze, visualize, and report?
The answer lies in using a Time Series Database (TSDB) — and that’s exactly where Prometheus excels.

🟡 How Prometheus Stores Metrics?

Each metric in Prometheus has 4 parts:
Metric Name, Timestamp, Labels (Tags), Value. For example:

2021/07/14 14:17:25.1000 → heart_rate{city="Shiraz", state="sleep"} 103

In the above example, the metric name is heart_rate, the time is 2021/07/14 14:17:25.1000, the labels are city and state, and the value is 103.
This data means that the heart rate was recorded on 2021/07/14 14:17:25.1000 in the city of Shiraz, and the sleep state was 103.
In general, it should be said that in Time Series Databases, the main and key axis is time. Pay attention to this image:

As you can see in this image, we have a series of time points from t0 to t6, at each of which metric information is stored. For example, the number of search requests that have entered the Android application up to moment t3 (first row from the bottom) is 18, and by time t5 this number reaches 22, meaning that in (t5 - t3) seconds, 5 new search requests have arrived on the Android service.
Traditional relational databases can store time-stamped data, but they're not designed for the scale, speed, and analytical nature of time series workloads.

🟡 What is Prometheus?

Prometheus is an open-source monitoring and alerting toolkit, designed for time series data collection, especially in cloud-native, containerized environments.

📦 Prometheus core components

✅ Prometheus Server (Core Engine)

The core engine has these responsibilities:

Scrapes metrics from targets (applications/services).
Stores time series data locally.
Executes queries using PromQL.
Evaluates rules and triggers alerts.
TSDB (Time Series DB): Embedded time series database optimized for speed, compression, and retention.
Label-based Storage: Each time series is uniquely identified by a metric name + key-value labels.

✅ Exporters (Metric Endpoints)

Exporters are agents or libraries that expose metrics in Prometheus format, and Prometheus fetches metrics from exporters.
The interesting thing is that many third-party libraries provide Exporters for different types of services. Need to monitor a Microsoft SQL Server instance? Just search for the appropriate MSSQL Exporter. Want insights into your Windows OS metrics? Use the official Windows Exporter. The Prometheus ecosystem is incredibly rich. There’s an exporter for virtually every major service or system you can think of. From databases and message queues to web servers and operating systems, most come with prebuilt exporters that expose useful metrics in a Prometheus-compatible format.
Prometheus mainly works on a pull-based model to scrape exporter metrics. It scrapes (pulls) metrics from exporters at regular intervals. This is configurable via scrape_configs in Prometheus.

scrape_configs:
  - job_name: 'aspnet_core_api'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:5000']

In rare cases (e.g., short-lived jobs), Prometheus can receive pushed metrics via Pushgateway.

✅ Service Discovery

Service discovery dynamically discovers targets in modern environments (Kubernetes, EC2, Consul, Docker Swarm), but static configs are possible.

✅ PromQL (Prometheus Query Language)

It is used for querying and aggregating time series ,and writing alerting rules.

✅ Alertmanager

Decoupled service that handles alerts fired by Prometheus.

📦 Understanding Prometheus Metric Types

Prometheus supports four core types of metrics: Counter, Gauge, Histogram, and Summary. Each serves a distinct purpose in monitoring and analyzing the behavior of systems and services.

🔢 Counter

A Counter is a metric that only increases over time. It’s ideal for tracking cumulative values, like the number of requests received, errors encountered, or jobs completed.

Example use case:
Tracking the number of HTTP requests to a product detail endpoint.

# TYPE application_request_counter counter
application_request_counter{endpoint="product-detail-page", responsecode="200"} 532

In the example above, 532 requests have been received so far. The next incoming request will increment this to 533.
💡 Counters never decrease — if you see a reset, it usually means the application has restarted.

📏 Gauge

A Gauge represents a metric that can go up or down. Use it to track values like current memory usage, CPU load, or request duration.

Example use case:
Tracking how long a product list page request takes.

# TYPE application_request_duration gauge
application_request_duration{endpoint="product-list-page"} 845

This means the current request took 845 milliseconds to complete. Unlike counters, gauges are momentary snapshots.

📊 Histogram

A Histogram collects observations (like response durations) and organizes them into buckets. It also tracks the total count and sum of all observed values, allowing you to calculate averages, percentiles, and latency distributions.

# TYPE application_request histogram
application_request_bucket{le="50"}    502
application_request_bucket{le="100"}   954
application_request_bucket{le="180"}   1166
application_request_bucket{le="250"}   1296
application_request_bucket{le="400"}   1383
application_request_bucket{le="800"}   1424
application_request_bucket{le="2000"}  1429
application_request_bucket{le="+Inf"}  1429

application_request_sum   25465
application_request_count 1429

This means:
502 requests took ≤ 50ms
954 took ≤ 100ms
...
All 1429 requests fell within the +Inf bucket
From sum and count, you can calculate the average latency.

🧮 Summary

A Summary also tracks sum and count, but adds quantiles, such as the 50th, 95th, or 99th percentiles — very useful for latency analysis.

# TYPE application_request_duration summary
application_request_duration_sum{app="MonitoringExample.Api"}   95743
application_request_duration_count{app="MonitoringExample.Api"} 1429
application_request_duration{app="MonitoringExample.Api", quantile="0.5"}  114
application_request_duration{app="MonitoringExample.Api", quantile="0.75"} 132
application_request_duration{app="MonitoringExample.Api", quantile="0.95"} 146
application_request_duration{app="MonitoringExample.Api", quantile="0.99"} 152

This tells us:
50% of requests completed in ≤ 114ms
95% of requests completed in ≤ 146ms
99% completed in ≤ 152ms

📦 Histogram vs. Summary

Histogram and Summary are often misunderstood metric types. Both Histogram and Summary are used to observe and analyze distributions of values, like response durations or payload sizes. However, they differ in how they collect, aggregate, and present data.
A Histogram samples observations (like durations or sizes) and counts how many fall into predefined buckets. Each bucket is defined by an upper bound (le, or "less than or equal to"). In addition, a Histogram always provides *_count(total number of observations) and *_sum(sum of all observed values). These let you calculate averages.
A Summary calculates and exports precomputed quantiles, like the 50th (median), 95th, or 99th percentile — along with *_sum and *_count. When you need to monitor user experience and answer these questions: How fast are most of the requests? Or what's the typical latency for 99% of users? Should use Summary

🟡 What’s Next?

Integrating Prometheus with our ASP.NET Core API
Exposing custom metrics using prometheus-net
Deep dive into metric labeling strategies
Creating our first Prometheus query
Designing a working dashboard in Grafana

Golang Web API: Project configuration management using Viper

Hamed Naeemaei — Sun, 15 Oct 2023 13:57:13 +0000

In this section, I create separate config files (yaml) for the development environment and docker environment, then make a config package to read configuration from yaml files.
To see this session project you can visit Session 4 GitHub repo URL.

Create config files

In the first step, we need to make three config files for the docker, production, and development environments in src/config path:

1. config-development.yml

server:
  internalPort: 5005
  externalPort: 5005
  runMode: debug
logger:
  filePath: ../logs/
  encoding: json
  level: debug
  logger: zap
cors:
  allowOrigins: "*"
postgres:
  host: localhost
  port: 5432
  user: postgres
  password: admin
  dbName: car_sale_db
  sslMode: disable
  maxIdleConns: 15
  maxOpenConns: 100
  connMaxLifetime: 5
redis:
  host: localhost
  port: 6379
  password: password
  db: 0
  dialTimeout: 5
  readTimeout: 5
  writeTimeout: 5
  poolSize: 10
  poolTimeout: 15
  idleCheckFrequency: 500
password:
  includeChars: true
  includeDigits: true
  minLength: 6
  maxLength: 64
  includeUppercase: true
  includeLowercase: true
otp:
  expireTime: 120
  digits: 6
  limiter: 100
jwt:
  secret: "mySecretKey"
  refreshSecret: "mySecretKey"
  accessTokenExpireDuration: 1440
  refreshTokenExpireDuration: 60

2. config-docker.yml

server:
  internalPort: 5000
  externalPort: 0
  runMode: release
logger:
  filePath: /app/logs/
  encoding: json
  level: debug
  logger: zap
cors:
  allowOrigins: "*"
postgres:
  host: postgres_container
  port: 5432
  user: postgres
  password: admin
  dbName: car_sale_db
  sslMode: disable
  maxIdleConns: 15
  maxOpenConns: 100
  connMaxLifetime: 5
redis:
  host: redis_container
  port: 6379
  password: password
  db: 0
  dialTimeout: 5
  readTimeout: 5
  writeTimeout: 5
  poolSize: 10
  poolTimeout: 15
  idleCheckFrequency: 500
password:
  includeChars: true
  includeDigits: true
  minLength: 6
  maxLength: 64
  includeUppercase: true
  includeLowercase: true
otp:
  expireTime: 120
  digits: 6
  limiter: 100
jwt:
  secret: "mySecretKey"
  refreshSecret: "mySecretKey"
  accessTokenExpireDuration: 60
  refreshTokenExpireDuration: 60

3. config-production.yml

server:
  internalPort: 5010
  externalPort: 5010
  runMode: release
logger:
  filePath: logs/
  encoding: json
  level: debug
  logger: zap
cors:
  allowOrigins: "*"
postgres:
  host: localhost
  port: 5432
  user: postgres
  password: admin
  dbName: car_sale_db
  sslMode: disable
  maxIdleConns: 15
  maxOpenConns: 100
  connMaxLifetime: 5
redis:
  host: localhost
  port: 6379
  password: password
  db: 0
  dialTimeout: 5
  readTimeout: 5
  writeTimeout: 5
  poolSize: 10
  poolTimeout: 15
  idleCheckFrequency: 500
password:
  includeChars: true
  includeDigits: true
  minLength: 6
  maxLength: 64
  includeUppercase: true
  includeLowercase: true
otp:
  expireTime: 120
  digits: 6
  limiter: 100
jwt:
  secret: "mySecretKey"
  refreshSecret: "mySecretKey"
  accessTokenExpireDuration: 1440
  refreshTokenExpireDuration: 60

4. Config structure in go

All configuration of the project must be placed in config-{env}.yml files. For now, server, logger, postgres, cors, and Redis configurations are placed in this file and will be completed later.
Now it's time to start making config.go file to the central point of the project environment the configuration management. this file is placed in src/config directory. First, we need to create structs corresponding to the config sections:

type Config struct {
    Server   ServerConfig
    Postgres PostgresConfig
    Redis    RedisConfig
    Password PasswordConfig
    Cors     CorsConfig
    Logger   LoggerConfig
    Otp      OtpConfig
    JWT      JWTConfig
}

type ServerConfig struct {
    InternalPort    string
    ExternalPort    string
    RunMode string
}

type LoggerConfig struct {
    FilePath string
    Encoding string
    Level    string
    Logger   string
}

type PostgresConfig struct {
    Host            string
    Port            string
    User            string
    Password        string
    DbName          string
    SSLMode         string
    MaxIdleConns    int
    MaxOpenConns    int
    ConnMaxLifetime time.Duration
}

type RedisConfig struct {
    Host               string
    Port               string
    Password           string
    Db                 string
    DialTimeout        time.Duration
    ReadTimeout        time.Duration
    WriteTimeout       time.Duration
    IdleCheckFrequency time.Duration
    PoolSize           int
    PoolTimeout        time.Duration
}

type PasswordConfig struct {
    IncludeChars     bool
    IncludeDigits    bool
    MinLength        int
    MaxLength        int
    IncludeUppercase bool
    IncludeLowercase bool
}

type CorsConfig struct {
    AllowOrigins string
}

type OtpConfig struct {
    ExpireTime time.Duration
    Digits     int
    Limiter    time.Duration
}

type JWTConfig struct {
    AccessTokenExpireDuration  time.Duration
    RefreshTokenExpireDuration time.Duration
    Secret                     string
    RefreshSecret              string
}

5. Config functions

In this project, we use viper package to manage configurations. So first we should install the Viper package go get -u github.com/spf13/viper. Then run go mod tidy command to ensure that all imports are satisfied.
At this stage, we need some functions

5.1 Get config file path

this function returns a file path based environment.

func getConfigPath(env string) string {
    if env == "docker" {
        return "/app/config/config-docker"
    } else if env == "production" {
        return "/config/config-production"
    } else {
        return "/config/config-development"
    }
}

5.2 Load config file with Viper

After the config file was found, we needed to load the config file with Viper based specified file type.

func LoadConfig(filename string, fileType string) (*viper.Viper, error) {
    v := viper.New()
    v.SetConfigType(fileType)
    v.SetConfigName(filename)
    v.AddConfigPath(".")
    v.AutomaticEnv()

    err := v.ReadInConfig()
    if err != nil {
        log.Printf("Unable to read config: %v", err)
        if _, ok := err.(viper.ConfigFileNotFoundError); ok {
            return nil, errors.New("config file not found")
        }
        return nil, err
    }
    return v, nil
}

5.3 Parse Viper config

In this section, we should Unmarshal Viper config to the custom Config type declared in section 4. If this instruction was successful means the file is parsed and can be used.

func ParseConfig(v *viper.Viper) (*Config, error) {
    var cfg Config
    err := v.Unmarshal(&cfg)
    if err != nil {
        log.Printf("Unable to parse config: %v", err)
        return nil, err
    }
    return &cfg, nil
}

5.4 Get config file from other layers

Finally, we write a function that is exposed to other layers to using config struct. This function returns a pointer of the config struct. Furthermore, some swagger port settings are handled in this function and I will explain about it in the next sections.

func GetConfig() *Config {
    cfgPath := getConfigPath(os.Getenv("APP_ENV"))
    v, err := LoadConfig(cfgPath, "yml")
    if err != nil {
        log.Fatalf("Error in load config %v", err)
    }

    cfg, err := ParseConfig(v)
    envPort := os.Getenv("PORT")
    if envPort != ""{
        cfg.Server.ExternalPort = envPort
        log.Printf("Set external port from environment -> %s", cfg.Server.ExternalPort)
    }else{
        cfg.Server.ExternalPort = cfg.Server.InternalPort
        log.Printf("Set external port from environment -> %s", cfg.Server.ExternalPort)
    }
    if err != nil {
        log.Fatalf("Error in parse config %v", err)
    }

    return cfg
}

This is the final version of the config.go file:

package config

import (
    "errors"
    "log"
    "os"
    "time"

    "github.com/spf13/viper"
)

type Config struct {
    Server   ServerConfig
    Postgres PostgresConfig
    Redis    RedisConfig
    Password PasswordConfig
    Cors     CorsConfig
    Logger   LoggerConfig
    Otp      OtpConfig
    JWT      JWTConfig
}

type ServerConfig struct {
    InternalPort    string
    ExternalPort    string
    RunMode string
}

type LoggerConfig struct {
    FilePath string
    Encoding string
    Level    string
    Logger   string
}

type PostgresConfig struct {
    Host            string
    Port            string
    User            string
    Password        string
    DbName          string
    SSLMode         string
    MaxIdleConns    int
    MaxOpenConns    int
    ConnMaxLifetime time.Duration
}

type RedisConfig struct {
    Host               string
    Port               string
    Password           string
    Db                 string
    DialTimeout        time.Duration
    ReadTimeout        time.Duration
    WriteTimeout       time.Duration
    IdleCheckFrequency time.Duration
    PoolSize           int
    PoolTimeout        time.Duration
}

type PasswordConfig struct {
    IncludeChars     bool
    IncludeDigits    bool
    MinLength        int
    MaxLength        int
    IncludeUppercase bool
    IncludeLowercase bool
}

type CorsConfig struct {
    AllowOrigins string
}

type OtpConfig struct {
    ExpireTime time.Duration
    Digits     int
    Limiter    time.Duration
}

type JWTConfig struct {
    AccessTokenExpireDuration  time.Duration
    RefreshTokenExpireDuration time.Duration
    Secret                     string
    RefreshSecret              string
}

func GetConfig() *Config {
    cfgPath := getConfigPath(os.Getenv("APP_ENV"))
    v, err := LoadConfig(cfgPath, "yml")
    if err != nil {
        log.Fatalf("Error in load config %v", err)
    }

    cfg, err := ParseConfig(v)
    envPort := os.Getenv("PORT")
    if envPort != ""{
        cfg.Server.ExternalPort = envPort
        log.Printf("Set external port from environment -> %s", cfg.Server.ExternalPort)
    }else{
        cfg.Server.ExternalPort = cfg.Server.InternalPort
        log.Printf("Set external port from environment -> %s", cfg.Server.ExternalPort)
    }
    if err != nil {
        log.Fatalf("Error in parse config %v", err)
    }

    return cfg
}

func ParseConfig(v *viper.Viper) (*Config, error) {
    var cfg Config
    err := v.Unmarshal(&cfg)
    if err != nil {
        log.Printf("Unable to parse config: %v", err)
        return nil, err
    }
    return &cfg, nil
}
func LoadConfig(filename string, fileType string) (*viper.Viper, error) {
    v := viper.New()
    v.SetConfigType(fileType)
    v.SetConfigName(filename)
    v.AddConfigPath(".")
    v.AutomaticEnv()

    err := v.ReadInConfig()
    if err != nil {
        log.Printf("Unable to read config: %v", err)
        if _, ok := err.(viper.ConfigFileNotFoundError); ok {
            return nil, errors.New("config file not found")
        }
        return nil, err
    }
    return v, nil
}

func getConfigPath(env string) string {
    if env == "docker" {
        return "/app/config/config-docker"
    } else if env == "production" {
        return "/config/config-production"
    } else {
        return "/config/config-development"
    }
}

In the end, I want to load the config from the config file and read the webserver port from the config instead of hard-coding.
For example, I made some changes in src/api/api.go file. First append cfg := config.GetConfig() to start of InitServer function and then load the webserver port from config r.Run(fmt.Sprintf(":%s", cfg.Server.Port)).
This is the final version of api.go file:

package api

import (
    "fmt"

    "github.com/gin-gonic/gin"
    "github.com/naeemaei/golang-clean-web-api/api/routers"
    "github.com/naeemaei/golang-clean-web-api/config" // Added
)


func InitServer(){
    cfg := config.GetConfig()  // Added
    r := gin.New()
    r.Use(gin.Logger(), gin.Recovery())

    v1 := r.Group("/api/v1/")
    {
        health := v1.Group("/health")
        routers.Health(health)
    }

    if err := r.Run(fmt.Sprintf(":%s", cfg.Server.InternalPort)); err != nil {
        panic(err)
    } // Added
}

Now we can run the project with the go run cmd/main.go command from src directory.

In the next article, I will make a simple endpoint and explain how to validate the requests and how works validators in gin.

Project until here: Configuration management usingViper

Golang Web API Course: Create starter project with a simple health check endpoint

Hamed Naeemaei — Fri, 13 Oct 2023 17:18:29 +0000

After I explained the project structure in the previous section, we can create the project and get into the code environment.

Requirements

Before this, we should setup the environment, so follow these steps:

I'm using VSCode as the development IDE so you should install VSCode or another IDE/code editor.
After choosing your IDE, we should install golang from this link.
To check if golang was installed or not run go version command.
So to use golang debug tools, we should install DELVE with go install github.com/go-delve/delve/cmd/dlv@latest command
(Optional) If you are not familiar with golang and using VSCode, you can install some of this VSCode extensions to develop and debug easier with golang:
code --install-extension aaron-bond.better-comments code --install-extension christian-kohler.path-intellisense code --install-extension ckolkman.vscode-postgres code --install-extension cweijan.vscode-redis-client code --install-extension donjayamanne.githistory code --install-extension esbenp.prettier-vscode code --install-extension formulahendry.code-runner code --install-extension golang.go code --install-extension HookyQR.beautify code --install-extension IBM.output-colorizer code --install-extension mhutchie.git-graph code --install-extension ms-azuretools.vscode-docker code --install-extension PKief.material-icon-theme code --install-extension premparihar.gotestexplorer code --install-extension streetsidesoftware.code-spell-checker code --install-extension VisualStudioExptTeam.vscodeintellicode code --install-extension vscode-icons-team.vscode-icons code --install-extension wmaurer.change-case

Create project

Initialize module

At this moment, we need to create our project module in src directory (not in root dir) with go mod init github.com/naeemaei/golang-clean-web-api command.

Install gin package

To install gin package run these command: go get -u github.com/gin-gonic/gin. After the installation is finished go.mod and go.sum files should updated.

Create a health check simple handler

Go to src/api/handlers directory and create health.go file (see here) as in the example below :

package handlers

import (
    "net/http"

    "github.com/gin-gonic/gin"
)

type HealthHandler struct {
}

func NewHealthHandler() *HealthHandler {
    return &HealthHandler{}
}

func (h *HealthHandler) Health(c *gin.Context) {
    c.JSON(http.StatusOK, "Working!")
}

This file has a constructor to initiate HealthHandler in the router package and can have one or more methods to handle HTTP requests.

Create health router

Go to src/api/routers directory and create health.go file as in the example below:

package routers

import (
    "github.com/gin-gonic/gin"
    "github.com/naeemaei/golang-clean-web-api/api/handlers"
)

func Health(r *gin.RouterGroup) {
    handler := handlers.NewHealthHandler()

    r.GET("/", handler.Health) // Call hanlder.Health method
}

This file instantiates a new handler and call methods based on route and HTTP verbs.

Config web server

Now it's time to config the web server. For this, we need to create api.go file in src/api:

package api

import (
    "github.com/gin-gonic/gin"
    "github.com/naeemaei/golang-clean-web-api/api/routers"
)

func InitServer() {
    r := gin.New()
    r.Use(gin.Logger(), gin.Recovery())

    v1 := r.Group("/api/v1/")
    {
        health := v1.Group("/health")
        routers.Health(health)
    }

    r.Run(":5005")
}

As you can see in this file, after creating the web server we added two gin default middlewares including logger middleware to logging requests and recovery to handle internal panics.
Then create a router group api/v1 and assign health handler to health route. Finally, run the web server on the 5005 port.

Create main.go file

the main.go file is the start point of each golang project.
Go to src/cmd directory and create main.go file here with this content:

package main

import "github.com/naeemaei/golang-clean-web-api/api"

func main(){
    api.InitServer()
}

In the next section, using Viper to make project environment configuration

Now we can run the project and test the health check endpoint, first go to main.go file and press F5 to run. If everything is okay you can test http://localhost:5005/api/v1/health/ url to check health check works or not, but if didn't run we need to create launch.json in VSCode.

Of course, if you are familiar with it, it is better to make the launch.json, and if not, I will explain it to you further

Golang project launch.json in VSCode

On the root create a .vscode directory then go to it and create launch.json file(see here) with this content (Of course, there is an easier way for it, if you are a beginner, you may make a error):

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Package",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program": "${workspaceFolder}/src/cmd"
        }
    ]
}

Golang Web API Course: Project structure

Hamed Naeemaei — Thu, 12 Jan 2023 23:45:42 +0000

Before entering the code environment, in this section, we will get to know the project's structure.
One of the points that must be observed in project architecture is the principle of separation of responsibilities. In this project, we have considered a specific responsibility for each layer, and the layers operate independently. For example, you can use another framework instead of the gin framework or not use the framework.

In general, the project consists of several main parts:

1. API

This layer is the only part of the project where the gin framework is used, and this layer only manages concepts related to web API such as routing, validation, middleware, etc.

1.1 API.go file

Registration of middlewares, routes, validators, and all web server configurations is handled in this file. Functions of this file are called from main.go

1.2 DTO

All DT objects that transfer data between the API layer and the business layer are defined in this directory.

1.3 Routers

The starting point of receiving the request is in the router package. this package checks route sections and HTTP verbs then sends requests to handlers.

1.4 Handlers

This package gets requests from the router package and sends them to the service layer. swagger configs set in this package

1.5 Middlewares

All middlewares including authentication, authorization, CORS, rate limiters, Prometheus, request logger and etc are defined here

2. SERVICES

Business logic and services are written in this layer. this package was called by handlers and called the data layer to work with the database.

3. DATA

In this layer, all the work of connecting with the database(postgres and redis) and working with data is done. This package is called from the service layer.

Other sections

4. CMD(main.go)

This is the starting point of service execution in this section. The main.go file after initializing cache, database, and logger, call api.go file.

5. COMMON

Useful and widely used functions are defined in this layer.

6. CONFIG

Project configurations and their management are located in this section.

7. CONSTANTS

Project constants are defined here.

8. DOCS

Swagger information and settings are located in this section.

9. PKG

External packages are located in this section.

10. TEST

Project tests are written in this section.

11. Docker

In this section, there is a Docker compose file of the main project, Prometheus, Grafana, Elasticsearch, Kibana, filebeat, Postgres, and Redis. To run the project, it is enough to up the Docker Compose file.

Golang Web API Course: Intro

Hamed Naeemaei — Thu, 12 Jan 2023 23:43:14 +0000

In this collection of articles, I want to develop a real web API project using Golang
During the development process, we will use many useful tools such as:

Gin as the web framework
JWT for authentication and authorization
Redis for caching
Elasticsearch for logging database
Beat for log shipping
Kibana as a log viewer
Postgresql as the main database engine
PgAdmin as a database management tool
Prometheus for metric database
Grafana for metric dashboards
Validator for endpoint input validation
Viper for configurations
Zap for logging
Zerolog for logging
Gorm as ORM
Swagger for documentation
Docker compose for running project with all dependencies in docker

You can see the source code of the project on Github: golang web API project and if you like this repo or found it helpful, please give it a star. Thanks!

In the next sections, I will explain the project structure and steps for implementing project