DEV Community: Nikita Rykhlov

⚙️ Go Tools: Password Hashing with Argon2 Instead of bcrypt

Nikita Rykhlov — Fri, 20 Jun 2025 10:46:31 +0000

Storing passwords securely is one of the most critical security tasks in modern applications. Many developers still rely on time-tested algorithms like bcrypt, but technology doesn't stand still. In this article, we'll explore Argon2 — a modern and secure password hashing algorithm that serves as an excellent alternative to bcrypt. We'll also look at how to implement it in Go (Golang).

Why Argon2?

A Quick Recap on bcrypt

bcrypt is a cryptographic algorithm specifically designed for password hashing. It resists brute-force attacks thanks to the use of "salt" and a tunable cost factor that increases computational complexity.

However, over time new threats have emerged — especially those involving specialized hardware such as GPUs and ASICs for password cracking. This is where bcrypt starts to fall short compared to more modern solutions.

What Is Argon2?

Argon2 is the winner of the Password Hashing Competition (PHC), a competition organized by the cryptographic community to find a new standard for secure password hashing. It was developed by a team of cryptographers from the University of Luxembourg: Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich.

Argon2 was chosen for its resistance to various types of attacks, including:

Timing attacks
GPU/ASIC-based attacks
Memory-hard attacks

Argon2 offers three different modes:

Argon2d — provides maximum protection against hardware attacks but is vulnerable to timing attacks.
Argon2i — resistant to timing attacks but weaker against hardware-based attacks.
Argon2id — a hybrid mode combining the best features of both.

For most practical purposes, Argon2id is recommended.

Why Argon2 Is Better Than bcrypt

Feature	bcrypt	Argon2
Protection against GPU attacks	Weak	Strong
Configurable memory usage	No	Yes
Parallelism support	No	Yes
Resistance to timing attacks	Yes	Yes

In short, Argon2 is a more flexible, modern, and secure solution.

Using Argon2 in Go

The package golang.org/x/crypto/argon2 provides a solid implementation of the Argon2 algorithm.

In this example, we'll use Argon2id (IDKey), which combines the strengths of Argon2i and Argon2d: it's resistant to side-channel attacks and protected against time-memory trade-off attacks.

Installation

go get golang.org/x/crypto/argon2

Example Code

package main

import (
    "crypto/rand"
    "crypto/subtle"
    "fmt"
    "golang.org/x/crypto/argon2"
)

// Recommended RFC parameters for most applications
const (
    saltLength = 16       // length of salt in bytes
    keyLength  = 32       // length of derived key (e.g., for AES-256)
    time       = 1        // number of iterations
    memory     = 64 << 10 // memory cost in KiB (~64MB)
    threads    = 4        // number of parallel threads
)

func generateSalt(length int) ([]byte, error) {
    salt := make([]byte, length)
    _, err := rand.Read(salt)
    if err != nil {
        return nil, err
    }

    return salt, nil
}

func hashPassword(password string) ([]byte, []byte, error) {
    salt, err := generateSalt(saltLength)
    if err != nil {
        return nil, nil, err
    }

    hashed := argon2.IDKey([]byte(password), salt, time, memory, threads, keyLength)

    return hashed, salt, nil
}

func verifyPassword(password string, salt []byte, expectedHash []byte) bool {
    newHash := argon2.IDKey([]byte(password), salt, time, memory, threads, keyLength)

    return subtleCompare(newHash, expectedHash)
}

// Prevent timing attacks
func subtleCompare(a, b []byte) bool {
    return subtle.ConstantTimeCompare(a, b) == 1
}

func main() {
    password := "mySecureP@ssw0rd"

    // Step 1: Hash the password
    hashed, salt, err := hashPassword(password)
    if err != nil {
        panic(err)
    }

    fmt.Printf("Hashed password: %x\n", hashed)

    // Step 2: Verify correct password
    if verifyPassword(password, salt, hashed) {
        fmt.Println("✅ Password is valid")
    } else {
        fmt.Println("❌ Password is invalid")
    }

    // Step 3: Verify incorrect password
    if verifyPassword("wrongPass", salt, hashed) {
        fmt.Println("❌ Incorrect password was accepted!")
    } else {
        fmt.Println("✅ Verification rejected incorrect password")
    }
}

🔐 Tip: Never use fixed salt values. Always generate a new random salt before each password hashing.

Recommended Parameters

Parameter	Value	Description
`time`	1	Number of passes through memory
`memory`	64 * 1024	Amount of memory used in KiB (~64 MB)
`threads`	4	Number of threads to use
`keyLength`	32	Length of the resulting key in bytes
`saltLength`	16	Random salt to prevent collisions

These values are suitable for most web applications. Adjust them based on your system's capabilities or specific requirements (e.g., mobile devices).

Conclusion

While bcrypt remains a solid choice, Argon2 offers superior protection against modern threats, particularly GPU and ASIC-based attacks. With its flexibility and efficient resource usage, it is becoming the de-facto standard for password hashing in new projects.

If you're developing in Go, integrating Argon2 is straightforward using existing libraries. Just remember to choose appropriate parameters for your application load and always store the salt and metadata correctly.

📎 Useful Links

📌 What do you think?

Have you already switched from bcrypt to Argon2 in your projects — or still sticking with the classic?

What password hashing strategy do you use in Go — and how do you manage security vs. performance?

👇 Share your thoughts and experience in the comments — I’d love to learn from you!

👍 If you enjoyed this article, don’t forget to like and share it — help others upgrade their password security the right way!

📣 Follow me and read my content on other platforms:

Check out this and other articles on my pages:

🔗 LinkedIn
📚 Medium
📘 Facebook
✈️ Telegram
🐦 X

Oh, almost forgot — my personal website.

🔔 Follow me not to miss new articles and guides on hot topics!

🏗️ Architecture: How to Visualize System Interaction - Use Case Diagram

Nikita Rykhlov — Mon, 16 Jun 2025 11:15:04 +0000

A Use Case Diagram emerged as part of the Unified Modeling Language (UML), which was developed in the mid-1990s. The core concept was proposed by specialists Grady Booch, James Rumbaugh, and Ivar Jacobson, who worked at Rational Software at that time. By combining their approaches to object-oriented analysis and design, they created UML — a standard that became a universal tool for describing software system architecture. The Use Case Diagram became an important part of this language because it allowed visualizing how users interact with the system even at the requirements gathering stage.

What Is a Use Case Diagram?

A Use Case Diagram is one of the types of diagrams in UML that shows how different participants (actors) interact with the functionalities of a system. It helps visualize the main goals of users and define what actions the system must support to fulfill those goals.

Main Elements of a Use Case Diagram:

Actor — An external entity that interacts with the system. This can be a person, another system, or even time.

Use Case — A functionality or action provided by the system to the actor.

Relationships between actors and use cases — Indicate who participates in which action.

Relationships between use cases — Such as include, extend, and inheritance, which describe complex behavioral scenarios.

Why Use Use Case Diagrams?

Simplify communication with clients and stakeholders.
Help define the boundaries of the system.
Serve as a foundation for further design and testing.
Provide a high-level view of the system's behavior without diving into implementation details.

Example:

Imagine you are developing a platform for online food ordering. Your system should support features such as registration, menu browsing, placing orders, tracking deliveries, and rating orders. The actors may include: customer, courier, and restaurant.

Here’s how the textual description of this diagram might look:

PlantUML

@startuml
left to right direction
actor "Customer" as client
actor "Courier" as courier
actor "Restaurant" as restaurant

rectangle "Food Delivery Service" {
  client -- (Registration)
  client -- (Browse Menu)
  client -- (Place Order)
  client -- (Track Order)
  client -- (Rate Order)

  restaurant -- (Receive Order)
  restaurant -- (Prepare Order)

  courier -- (Receive Order for Delivery)
  courier -- (Deliver Order)
}

(Place Order) .> (Receive Order) : include
(Deliver Order) .> (Track Order) : extend
@enduml

How to Read This Diagram?

Customer can:
- Register in the app,
- Browse restaurant menus,
- Place orders,
- Track delivery status,
- Rate completed orders.
Restaurant is responsible for:
- Receiving order information,
- Preparing meals for delivery.
Courier is involved in:
- Receiving the order for delivery,
- Delivering the meal to the customer.

The include relationship shows that when a customer places an order, the restaurant always receives the order.
The extend relationship indicates that delivering the order may optionally be part of the tracking process.

Conclusion

A Use Case Diagram is a powerful tool for analyzing requirements and modeling system behavior in the early stages of development. It allows you to foresee key product features and understand how different users will interact with the system.

Use use case diagrams to better structure requirements, improve team communication, and create a clear vision of what your system should do.

📌 What do you think?

Have you ever created a Use Case Diagram for your projects?

What tools or notations do you prefer for modeling system behavior — PlantUML, draw.io, or something else?

👇 Share your thoughts and experience in the comments — I’d love to learn from you!

👍 If you enjoyed this article, don’t forget to like and share it — help others discover how to use Use Case Diagrams effectively!

📣 Follow me and read my content on other platforms:

Check out this and other articles on my pages:

🔗 LinkedIn
📚 Medium
📘 Facebook
✈️ Telegram
🐦 X

Oh, almost forgot — my personal website.

🔔 Follow me not to miss new articles and guides on hot topics!

⚙️ Go Tools: Yet Another Configuration Tool for Go Applications — zerocfg

Nikita Rykhlov — Tue, 03 Jun 2025 14:39:54 +0000

Configuration management is an essential part of any application development. In Go, the standard flag package provides a convenient way to work with command-line flags. However, in practice, there is often a need to support not only CLI arguments but also other sources such as YAML files, environment variables, and more.

zerocfg is a lightweight library that preserves the simplicity and familiar interface of the flag package while adding support for YAML, environment variables (env), and custom configuration sources.

✅ Key Features

🛠️ Intuitive API, similar to flag
🧼 Minimizes boilerplate code
🔍 Detects unknown keys in the configuration
📚 Supports multiple sources: CLI, YAML, ENV, and others
🔐 Hides sensitive data (e.g., passwords) when printing configurations
🧩 Extensible: supports custom types and providers

🚀 Usage Example

package main

import (
    "fmt"
    zfg "github.com/chaindead/zerocfg"
    "github.com/chaindead/zerocfg/env"
)

var (
    databaseHost         = *zfg.Str("db.host", "postgres", "database host")
    databasePort         = *zfg.Uint("db.port", 5678, "database port")
    databaseUserName     = *zfg.Str("db.username", "postgres", "database user name")
    databaseUserPassword = *zfg.Str("db.password", "", "database user password", zfg.Required(), zfg.Secret())
    databaseName         = *zfg.Str("db.name", "app", "database name")
)

func main() {
    err := zfg.Parse(env.New())
    if err != nil {
        panic(err)
    }

    fmt.Println(zfg.Show())

    databaseDSN := fmt.Sprintf("postgres://%s:%s@%s:%d/%s?sslmode=disable", databaseUserName, databaseUserPassword, databaseHost, databasePort, databaseName)

    _ = databaseDSN
}

🔁 Configuration Source Priority

Priorities determine which values will be used if they are defined in multiple sources:

Command-line flags (highest priority)
Additional providers (in the order they are listed)
Default values (lowest priority)

This mechanism allows flexible parameter configuration and overrides depending on the application’s runtime context.

📦 Supported Sources

CLI (command-line flags)
ENV (environment variables)
YAML (configuration files)

CLI Example

go run main.go --db.host localhost --db.port 6432 --db.username admin --db.password pass --db.name postgres

ENV Example

DB_HOST=localhost DB_PORT=6432 DB_USERNAME=admin DB_PASSWORD=pass DB_NAME=postgres go run main.go

YAML Example

To use a YAML file, you need to slightly modify the source code:

package main

import (
    "fmt"
    zfg "github.com/chaindead/zerocfg"
    "github.com/chaindead/zerocfg/env"
    "github.com/chaindead/zerocfg/yaml"
)

var (
    path                 = zfg.Str("config.path", "", "configuration file path", zfg.Alias("c"))
    databaseHost         = *zfg.Str("db.host", "postgres", "database host")
    databasePort         = *zfg.Uint("db.port", 5678, "database port")
    databaseUserName     = *zfg.Str("db.username", "postgres", "database user name")
    databaseUserPassword = *zfg.Str("db.password", "", "database user password", zfg.Required(), zfg.Secret())
    databaseName         = *zfg.Str("db.name", "app", "database name")
)

func main() {
    err := zfg.Parse(env.New(), yaml.New(path))
    if err != nil {
        panic(err)
    }

    fmt.Println(zfg.Show())

    databaseDSN := fmt.Sprintf("postgres://%s:%s@%s:%d/%s?sslmode=disable", databaseUserName, databaseUserPassword, databaseHost, databasePort, databaseName)

    _ = databaseDSN
}

Create a config.yml file with the following content:

db:
  host: "postgres"
  port: 5432
  username: "postgres"
  password: "postgres_pass"
  name: "app"

Then run the app like this:

go run main.go -c config.yml

📋 Additional Options

Fields marked with zfg.Secret() are hidden when printed via zfg.Show() — useful for passwords and tokens.
Fields with zfg.Required() are considered mandatory — if they are not provided in any source, an error will be returned.

Example:

databaseUserPassword = *zfg.Str("db.password", "", "database user password", zfg.Required(), zfg.Secret())

🧱 Extensibility

The library supports custom data types and custom configuration providers, making it flexible and adaptable to any project needs.

📝 Conclusion

The zerocfg library offers a simple yet powerful way to manage configuration in Go applications. While preserving the familiar interface of the standard flag package, it extends its capabilities with support for YAML files, environment variables, and custom configuration sources. Its intuitive API, minimal boilerplate, unknown key detection, and sensitive data masking make it an excellent choice for modern applications.

If you're looking for a lightweight and extensible configuration management library for Go — zerocfg is a great fit for your project.

More about zerocfg

📌 What do you think?

Have you tried zerocfg or other configuration management tools in Go yet?

What libraries or approaches do you use in your projects to handle application settings?

👇 Leave a comment below — I’d love to hear your experience!

👍 Don’t forget to like and share if you found this helpful — so more people can benefit from it too!

📣 Follow me and read my content on other platforms:

Check out this and other articles on my pages:

🔗 LinkedIn
📚 Medium
📘 Facebook
✈️ Telegram
🐦 X

Oh, almost forgot — my personal website.

🔔 Follow me not to miss new articles and guides on hot topics!

Architecture: Document architecture in a way that everyone understands

Nikita Rykhlov — Tue, 27 May 2025 16:56:39 +0000

In the world of backend development and designing complex systems, it's not enough just to write good code — it's equally important to clearly communicate architectural ideas to your team, clients, or new developers joining the project. One of the most effective tools for this is the C4 Model — a simple yet powerful way to document and visualize software architecture.

Created by Simon Brown, the C4 model offers a hierarchical approach to diagramming, allowing you to gradually zoom in from broad concepts to detailed implementation. The model consists of four levels:

System Context
Containers
Components
Code

What makes it especially convenient is that C4 is often used together with PlantUML, a powerful text-based tool for creating UML diagrams. This allows you to describe your system structure directly in code, easily keep diagrams up to date, and automate their rendering.

Let’s explore each level and provide examples using PlantUML.

1. System Context Diagram

At the highest level of abstraction, we see the whole system within its environment. The goal of this level is to show:

What system is being built
Who interacts with it (users, external systems)
How it connects to other systems

Example:

Suppose you're building a food delivery platform . The diagram would include: the core service itself, users (customers, couriers, restaurant owners, admins), payment gateways, SMS services, geolocation APIs, and analytics systems — everything your platform interacts with externally to function effectively.

PlantUML:

@startuml
title System Context Diagram: Food Delivery Service

skinparam rectangle {
    roundCorner 20
}

actor "User" as user
actor "Courier" as courier
actor "Admin" as admin
actor "Restaurant Owner" as restaurant_owner

[Food Delivery Service] as foodservice

user --> foodservice : Orders food, views menu
courier --> foodservice : Receives tasks, updates status
restaurant_owner --> foodservice : Manages menu, accepts orders
admin --> foodservice : Administers system, analytics, moderation

foodservice --> [Payment Gateway] : Payment processing
foodservice --> [SMS Service] : Sends notifications
foodservice --> [Geolocation API] : Location detection
foodservice --> [Analytics System] : Sends metrics

note right of foodservice
  A full-featured food delivery platform
  supporting multiple restaurants, users,
  couriers and analytics.
end note

@enduml

2. Container Diagram

At this level, we look inside the system and show its main containers — these are separate processes or hosts that communicate with each other. A container can be:

A web application (e.g., Node.js API)
A database (PostgreSQL, MongoDB)
A message broker (RabbitMQ, Kafka)
Microservices
Frontend app (React)

Example:

In a food delivery platform, possible containers could be:
API Gateway — routes incoming requests to the appropriate services
Order Service — manages order lifecycle (creation, modification, queueing)
Restaurant Service — handles restaurant and menu data
User Service — manages user profiles and authentication
Notification Service — sends alerts and updates via SMS or push
Payment Service — processes payments through an external gateway
Location Service — integrates with geolocation APIs for couriers and users
Analytics Service — collects and analyzes system metrics
PostgreSQL Cluster — stores core data like users, orders, and restaurants
Redis Cache — improves performance by caching frequently accessed data
RabbitMQ — handles internal service communication via events
Kafka — logs all events for analytics and system recovery

PlantUML:

@startuml
title Container Diagram: Food Delivery Service

package "Food Delivery Service" {
  [API Gateway] as gateway
  [Order Service] as orderservice
  [Restaurant Service] as restaurantservice
  [User Service] as userservice
  [Notification Service] as notificationservice
  [Payment Service] as paymentservice
  [Location Service] as locationservice
  [Analytics Service] as analyticsservice
  [PostgreSQL Cluster] as database
  [Redis Cache] as cache
  [RabbitMQ] as messagebroker
  [Kafka] as eventlog

  note bottom of orderservice
    Manages order lifecycle:
    creation, modification, queueing.
  end note

  note bottom of messagebroker
    Used for internal communication
    between services via events.
  end note

  note bottom of eventlog
    Stores all system events
    for analytics and recovery.
  end note
}

gateway --> orderservice
gateway --> restaurantservice
gateway --> userservice
gateway --> paymentservice
gateway --> locationservice

orderservice --> database
orderservice --> messagebroker
orderservice --> cache

restaurantservice --> database
restaurantservice --> cache

userservice --> database

paymentservice --> [Payment Gateway]

locationservice --> [Geolocation API]

notificationservice <-- messagebroker
analyticsservice <-- eventlog

@enduml

3. Component Diagram

Now we go one level deeper and look at what components reside inside each container. At this point, developer-level design decisions begin to emerge:

Which modules, services, repositories are used
How they interact with each other
Which frameworks and technologies are involved

Example:

Inside the Order Service container, there might be these components:
HTTP Handler — receives and routes incoming HTTP requests
Order Use Case — contains core business logic for creating, updating, and retrieving orders
Order Repository — interacts with the database to persist and retrieve order data
Event Publisher — publishes events (e.g., “OrderCreated”) to the message broker
Config Manager — provides configuration values to all components
Validator — ensures input data is valid before processing
Metrics Collector — gathers performance and usage metrics for monitoring

PlantUML:

@startuml
title Component Diagram: Order Service

package "OrderService" {
  [HTTP Handler] as handler
  [Order Use Case] as usecase
  [Order Repository] as repo
  [Event Publisher] as publisher
  [Config Manager] as config
  [Validator] as validator
  [Metrics Collector] as metrics

  note right of usecase
    Contains business logic for creating,
    updating and retrieving orders.
  end note

  note bottom of validator
    Validates order data before
    performing any operations.
  end note
}

handler --> usecase : Create / Get order
usecase --> validator : Validates input data
usecase --> repo : Works with DB
usecase --> publisher : Publishes event
usecase --> metrics : Logs metrics

config -down-> handler
config -down-> usecase
config -down-> repo
config -down-> publisher

@enduml

4. Code Diagram

This is the lowest level — the source code level. Here you can show:

Class diagrams
Object interactions
Method or function calls

However, code diagrams can quickly become outdated if not maintained. They’re best used to explain key algorithms or complex parts of the logic that are hard to understand without visual representation.

Example:

A diagram demonstrating the internal structure of the OrderUsecase, showing how it interacts with core components like OrderRepository, EventPublisher, and Validator. This UML diagram clarifies the flow of operations during order creation — from validation and persistence to event publishing, helping developers understand the logic and dependencies at the code level.

PlantUML:

@startuml
title Code Diagram: Order Usecase

class OrderUsecase {
  +CreateOrder(*Order) error
  +GetOrder(string) (*Order, error)
}

class OrderRepository {
  +Save(*Order) error
  +FindByID(string) (*Order, error)
}

class EventPublisher {
  +Publish(event Event) error
}

class Validator {
  +ValidateOrder(*Order) error
}

OrderUsecase --> OrderRepository : Uses
OrderUsecase --> EventPublisher : On create
OrderUsecase --> Validator : Before save

note right of OrderUsecase
  Executes business logic for order creation,
  calls repository and event publisher.
end note

@enduml

Why Use the C4 Model?

The C4 model is valuable because it:

Simplifies communication between developers, analysts, testers, and managers.
Allows you to see the big picture while having the ability to zoom into specific areas.
Improves architecture documentation — especially important in long-term projects.
Eases onboarding of new team members.
Helps with risk assessment, threat modeling, and architectural reviews.

How to Start Using C4 and PlantUML

If you want to start applying C4 in your work, here are some steps:

Start with the System Context level — define who interacts with what.
Move to the Containers level — show the main technical blocks.
Add the Components level for key containers — reveal their internal structure.
Use the Code level when necessary — only where it adds real value.
Write diagrams in PlantUML — this will help you maintain them easily.
Integrate into documentation — for example, via Markdown or Confluence with PlantUML support.

Conclusion

The C4 model is more than just a set of diagrams — it's a structured approach to understanding and describing architecture. It helps everyone on the project — from technical specialists to business stakeholders — speak the same language.

If you're working on complex backend systems, microservices, or simply want to better organize your thoughts during design, the C4 model will be a great addition to your toolkit. And using PlantUML will make working with diagrams easy, repeatable, and well-documented.

More about C4

More about PlantUML

📌 What do you think?

Have you tried C4 or PlantUML yet?

What tools or methods do you use to document your system architecture?

👇 Leave a comment below — I’d love to hear your experience!

👍 Don’t forget to like and share if you found this helpful — so more people can benefit from it too!

📣 Follow me and read my content on other platforms:

Check out this and other articles on my pages:

🔗 LinkedIn
📚 Medium
📘 Facebook
✈️ Telegram
🐦 X

Oh, almost forgot — my personal website.

🔔 Follow me not to miss new articles and guides on hot topics!

⚙️ Go Tools: Code Generation from OpenAPI Specs in Go with oapi-codegen

Nikita Rykhlov — Thu, 22 May 2025 13:05:00 +0000

When developing web applications in Go, especially when building RESTful APIs, documentation and strict adherence to a specification play a crucial role. For these purposes, the OpenAPI (Swagger) format is often used. However, manually maintaining both code and specification can lead to inconsistencies and errors.

The oapi-codegen tool helps automate the creation of part of the code based on an OpenAPI specification.

🔗 GitHub Repository: oapi-codegen

What is oapi-codegen?

oapi-codegen is a powerful open-source code generator designed for Go projects. It accepts an OpenAPI 3.0 specification in YAML or JSON format and generates ready-to-use Go code that implements server interfaces, client libraries, data models, routes, and other API components.

This significantly reduces the amount of boilerplate code required to build HTTP servers and clients, while ensuring consistency between the specification and the actual implementation.

Key Features

✅ Data Model Generation: Create Go structs based on schemas defined in the OpenAPI spec.

✅ Server Interface Creation: Automatically generate handler methods for request processing.

✅ Client SDK Support: Generate client packages for interacting with the API.

✅ Input Validation: Validate query parameters, headers, request bodies, etc., according to the spec.

✅ Framework Integration: Works with popular HTTP routers and frameworks like Chi, Echo, Gin, Fiber, Gorilla Mux, Iris, and even standard net/http.

✅ Extensibility: Supports custom templates and imports for tailored generation.

Installation

You can install the tool using the standard Go command:

go install github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@latest

Example Usage

Suppose you have a file openapi.yaml that describes a simple user management API:

openapi: 3.0.3
info:
  title: User API
  version: 1.0.0
paths:
  /users/{id}:
    get:
      summary: Get user by ID
      operationId: getV1GetUserByID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
            example: "123"
      responses:
        '200':
          description: User response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
components:
  schemas:
    User:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: integer
        name:
          type: string

Create a configuration file config.yaml:

package: api
generate:
  chi-server: true
  models: true
output: server_interface.gen.go

Run the generator:

oapi-codegen --config config.yaml openapi.yaml

The generated file will contain:

Data structures (User)
A ServerInterface interface with methods for each endpoint
Route setup and middleware implementation for the selected framework (Chi in this case)

Now you can implement your handler logic without worrying about routing or parsing requests manually.

Framework Integration

oapi-codegen supports integration with many popular HTTP libraries:

Framework	Support
Chi	✅
Echo	✅
Fiber	✅
Gin	✅
gorilla/mux	✅
Iris	✅
net/http	✅ (Go 1.22+)

Each framework has its own set of generated helpers and example implementations.

Why Use oapi-codegen?

✅ Specification-Code Consistency

Generating code from an OpenAPI spec ensures that your API always matches the documentation, reducing the risk of mismatches and bugs.

✅ Time Savings

You save time writing routes, validation logic, models, and other repetitive code elements.

✅ Scalable for Large APIs

Ideal for large-scale APIs where maintaining clean, structured code and making frequent changes is essential.

✅ Design-First API Development

oapi-codegen fits perfectly into a Design-First API workflow, where the specification is written before development begins. This makes the API design process consistent and aligned with the original plan.

Conclusion

oapi-codegen is a powerful tool for automating code generation from OpenAPI specifications in Go. It allows developers to focus on business logic rather than setting up routes and validations manually. If you're working on an API in a team or striving for clean, well-documented code, this utility is an excellent choice.

📣 Follow me and read my content on other platforms:

Check out this and other articles on my pages:

🔗 LinkedIn
📚 Medium
📘 Facebook
✈️ Telegram
🐦 X

Oh, almost forgot — my personal website.

🔔 Follow me not to miss new articles and guides on hot topics!

📌 Design-First API: Why It Matters for Complex Systems

Nikita Rykhlov — Tue, 20 May 2025 13:53:48 +0000

Over the years, I’ve learned that a good API doesn’t start with code — it starts with thoughtful design.

Design-First API is an approach where you define the API contract before writing any implementation code — typically using specifications like OpenAPI (Swagger). This lets teams agree on the shape and behavior of the API early in the development process.

It’s especially powerful in microservice architectures, where clear, stable interfaces between services are critical.

✅ Why this approach works:

Clear separation of concerns
Early alignment on requirements across frontend, backend, and cross-functional teams
Automation: generate clients, server stubs, validation logic (tools like oapi-codegen help a lot)
Living documentation that stays up-to-date with the actual implementation

💡 From my experience:

On previous projects — including a B2B wholesale platform and a document templating system — applying the Design-First approach helped us:

Speed up development by enabling parallel workstreams
Reduce integration bugs
Keep service contracts clean and consistent

Would you like me to share some practical examples from real-world implementations? Let me know 👇

Hello! This Is My Technical Blog

Nikita Rykhlov — Tue, 20 May 2025 13:15:53 +0000

Hi! My name is Nikita Rykhlov, and I’m a Senior Backend Developer with over 5 years of experience building scalable, fault-tolerant, and high-performance systems.

This blog is where I share my technical knowledge, dive into real-world use cases, and explore how to build robust backend solutions.

💻 What I Do

Over the past few years, I’ve worked on projects ranging from monolithic applications to distributed microservice architectures.

My main tech stack includes:

Go, PostgreSQL, Redis, Kafka, Kubernetes, gRPC, DDD, CI/CD, and other modern backend technologies.

🔍 What I’m Focusing On Now

Right now, I'm deepening my knowledge in:

Software Architecture
System Design
Distributed Systems
Service Mesh (Istio)
Cloud-native Development

At the same time, I'm growing as a technical writer and mentor — publishing articles, helping junior developers, and sharing practical tips from everyday engineering tasks.

💡 Why I'm Doing This

Because I want to:

Structure and deepen my own knowledge
Help others grow alongside me
Keep learning consistently
Make a small but useful contribution to the developer community

📚 What You’ll Find Here

In-depth breakdowns of architectural patterns
Practical Golang guides
Tool and library reviews
System design tips
Personal insights on teamwork and leadership
Real-world case studies

🚀 The blog has just begun

This is the very first post — and only the beginning. There’s a lot more coming, for both beginners and experienced developers alike.

If you want to understand how to build reliable backend systems, grow as an engineer, and stay up-to-date with modern practices — welcome aboard!

Subscribe and stay tuned for updates.