Архітектура клієнт-серверних систем та основи Go

Архітектурний контекст та еволюція клієнт-серверних систем

Проблема локальних монолітів минулого

На ранніх етапах розвитку обчислювальної техніки та комерційного програмного забезпечення домінуючим підходом було створення автономних локальних застосунків (standalone applications). У такій парадигмі графічний інтерфейс користувача (User Interface, UI), бізнес-правила обробки інформації (Business Logic) та файлове сховище даних знаходилися в межах одного виконуваного процесу, запущеного на конкретному персональному комп'ютері.

Подібний підхід створював непереборні інженерні обмеження для розподілених організацій та корпоративних систем:

1. Відсутність єдиного джерела істини (Single Source of Truth): Якщо кілька працівників одночасно модифікували локальні копії бази даних на різних машинах, виникав нерозв'язний конфлікт синхронізації та порушення цілісності даних.
2. Неможливість централізованого оновлення: Будь-яка зміна алгоритму (наприклад, формули нарахування податків або схеми знижок) вимагала фізичного оновлення файлів програми на кожному робочому комп'ютері підприємства.
3. Критичні ризики безпеки: Прямий доступ користувацького застосунку до фізичних файлів сховища дозволяв зловмиснику скопіювати або відредагувати конфіденційні записи в обхід будь-якої авторизації.

Вирішенням цієї кризи стала клієнт-серверна архітектура (client-server architecture) — розподілена обчислювальна модель, у якій функціональні обов'язки чітко розмежовуються між постачальниками обчислювальних ресурсів або послуг (серверами) та споживачами цих послуг (клієнтами).

Багаторівневі моделі: від 2-Tier до N-Tier

Еволюція клієнт-серверної парадигми супроводжувалася поступовим винесенням окремих зон відповідальності на спеціалізовані архітектурні рівні (tiers).

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 13
skinparam packageFontSize 14
skinparam rectangleFontSize 13
skinparam sequenceMessageAlign center

package "2-Tier Архітектура (Дворівнева)" #F8FAFC {
    rectangle "Товстий клієнт (UI + Бізнес-логіка)\n[Desktop App]" as c2 #DBEAFE
    database "СУБД (PostgreSQL / Oracle)\n[Збереження даних]" as db2 #DCFCE7
    c2 <--> db2 : Пряме SQL-з'єднання\n(Порт 5432 / 1521)
}

package "3-Tier Архітектура (Трирівнева)" #F8FAFC {
    rectangle "Тонкий / Товстий клієнт (UI)\n[Web / Mobile / Desktop]" as c3 #DBEAFE
    rectangle "Сервер застосунків (Application Server)\n[Go Backend / Бізнес-логіка]" as s3 #FEF3C7
    database "СУБД (PostgreSQL)\n[Збереження даних]" as db3 #DCFCE7
    c3 <--> s3 : HTTP REST / gRPC
    s3 <--> db3 : Пул з'єднань (Connection Pool)
}

package "N-Tier / Розподілена Архітектура" #F8FAFC {
    rectangle "Гетерогенні клієнти\n(Web, iOS, Android, Desktop, CLI)" as cn #DBEAFE
    rectangle "API Gateway / Reverse Proxy\n(Nginx / Envoy / Traefik)" as gw #E2E8F0
    rectangle "Мікросервіс автентифікації\n[Go Service]" as ms1 #FEF3C7
    rectangle "Мікросервіс замовлень\n[Go Service]" as ms2 #FEF3C7
    queue "Брокер повідомлень\n(RabbitMQ / Kafka)" as q #FCE7F3
    database "PostgreSQL Cluster" as dbn #DCFCE7
    database "Redis Cache" as cache #FEE2E2

    cn <--> gw : HTTPS / WSS
    gw --> ms1
    gw --> ms2
    ms2 <--> cache : Швидкий кеш
    ms2 --> q : Асинхронні події
    ms2 <--> dbn : Реляційні дані
}
@enduml

Розглянемо фундаментальні характеристики кожної архітектурної моделі:

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 13

actor "Користувач / Адміністратор" as User

package "Гетерогенне клієнтське оточення" #F1F5F9 {
    rectangle "Desktop Client\n(JavaFX / C# Avalonia)" as Desktop #DBEAFE
    rectangle "Mobile Client\n(React Native / Swift)" as Mobile #FEF3C7
    rectangle "Web Client\n(Vue / Nuxt / React)" as Web #DCFCE7
    rectangle "CLI Утиліта\n(Go / Bash скрипти)" as CLI #FCE7F3
}

package "Серверна інфраструктура (Go Backend)" #FFFFFF {
    rectangle "Єдиний REST / gRPC API Контракт" as API #E2E8F0
    rectangle "Бізнес-логіка та сервіси" as Core #DCFCE7
    database "PostgreSQL" as DB #DBEAFE
}

User --> Desktop
User --> Mobile
User --> Web
User --> CLI

Desktop --> API : JSON over HTTPS / TCP
Mobile --> API : Оптимізований JSON / Gzip
Web --> API : JSON / WebSocket
CLI --> API : Token Auth / JSON Streams

API --> Core
Core --> DB
@enduml

::

Спектр платформ та їхні мережеві вимоги

При проєктуванні архітектури серверних API необхідно враховувати фундаментальні відмінності клієнтських середовищ:

Мережевий фундамент: Модель OSI та стек TCP/IP

Для побудови надійних клієнт-серверних застосунків розробник повинен чітко розуміти шлях, який долають байти інформації від користувацького інтерфейсу до операційної системи сервера.

Зіставлення моделі OSI та стеку TCP/IP

Теоретична еталонна модель взаємодії відкритих систем (OSI — Open Systems Interconnection) описує 7 рівнів абстракції. На практиці глобальна мережа Інтернет функціонує на базі більш лаконічного 4-рівневого стеку протоколів TCP/IP:

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 13

title Зіставлення моделі OSI та стеку TCP/IP

rectangle "7. Прикладний (Application)\n6. Представлення (Presentation)\n5. Сеансовий (Session)" as osi_app #DBEAFE
rectangle "4. Транспортний (Transport)" as osi_trans #FEF3C7
rectangle "3. Мережевий (Network)" as osi_net #DCFCE7
rectangle "2. Канальний (Data Link)\n1. Фізичний (Physical)" as osi_phys #F1F5F9

rectangle "Прикладний рівень (Application Layer)\n[HTTP/1.1, HTTP/2, gRPC, WebSocket, DNS, SMTP]" as tcp_app #DBEAFE
rectangle "Транспортний рівень (Transport Layer)\n[TCP (Transmission Control), UDP (User Datagram)]" as tcp_trans #FEF3C7
rectangle "Мережевий / Міжмережевий рівень (Internet Layer)\n[IP (IPv4, IPv6), ICMP]" as tcp_net #DCFCE7
rectangle "Рівень мережевого доступу (Network Access Layer)\n[Ethernet, Wi-Fi, Оптоволокно]" as tcp_phys #F1F5F9

osi_app .right.> tcp_app : Об'єднуються
osi_trans .right.> tcp_trans : Пряма відповідність
osi_net .right.> tcp_net : Пряма відповідність
osi_phys .right.> tcp_phys : Об'єднуються

@enduml

Механізм інкапсуляції та деінкапсуляції даних

Коли клієнт (наприклад, мобільний застосунок) надсилає JSON-документ на сервер, дані проходять через процес інкапсуляції (encapsulation): кожен рівень стеку додає до корисного навантаження (payload) свій службовий заголовок (header).

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 12

title Інкапсуляція даних при передачі по мережі

rectangle "Прикладні дані (HTTP Request / JSON Payload)" as payload #E2E8F0

rectangle "TCP Сегмент" as tcp_seg #FEF3C7 {
    rectangle "TCP Заголовок\n(Source Port: 54321, Dest Port: 80, Seq, Ack)" as tcp_h #FDE68A
    rectangle "HTTP Payload" as p1 #E2E8F0
}

rectangle "IP Пакет" as ip_pkt #DCFCE7 {
    rectangle "IP Заголовок\n(Source IP: 192.168.1.50, Dest IP: 93.184.216.34)" as ip_h #BBF7D0
    rectangle "TCP Сегмент" as p2 #FEF3C7
}

rectangle "Ethernet Кадр (Frame)" as eth_frame #DBEAFE {
    rectangle "Ethernet Заголовок\n(MAC Source, MAC Dest)" as eth_h #BFDBFE
    rectangle "IP Пакет" as p3 #DCFCE7
    rectangle "FCS (CRC)" as eth_fcs #BFDBFE
}

payload -down-> tcp_seg : Транспортний рівень
tcp_seg -down-> ip_pkt : Мережевий рівень
ip_pkt -down-> eth_frame : Канальний рівень

@enduml

Коли сигнал надходить на мережеву карту сервера, операційна система виконує зворотний процес — деінкапсуляцію (de-encapsulation):

1. Мережева карта зчитує Ethernet-кадр, перевіряє контрольну суму (CRC) та передає вміст вище.
2. Драйвер мережевого рівня знімає IP-заголовок, перевіряючи, чи збігається IP-адреса призначення з адресою хоста.
3. Транспортний рівень стеку ядра ОС знімає TCP-заголовок, збирає сегменти в правильному порядку за номерами послідовності (sequence numbers) та визначає цільовий сокет за номером порту.
4. Програма на Go отримує чистий байтовий потік прикладних даних.

Анатомія сокета Берклі: від абстракції ОС до байтових буферів

Для прикладного програміста мережа починається не з транзисторів мережевої карти, а з абстракції операційної системи, яка має назву сокет Берклі (Berkeley Sockets API / POSIX Sockets). Цей стандарт був розроблений в Каліфорнійському університеті в Берклі у 1983 році для операційної системи BSD Unix і став загальноприйнятим стандартом для всіх сучасних операційних систем (Linux, macOS, Windows).

Щоб зрозуміти сокет, потрібно згадати фундаментальний принцип Unix-подібних систем: «Усе є файлом» (Everything is a file).

Внутрішня будова сокета в пам'яті ядра ОС

Коли програма створює сокет, операційна система виділяє в просторі ядра (Kernel Space) спеціальну структуру даних, яка містить системні буфери, черги та метадані з'єднання.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 12

package "Простір користувача (User Space)" #F8FAFC {
    rectangle "Go Застосунок\n(Серверний код)" as App #DCFCE7
}

package "Простір ядра операційної системи (Kernel Space)" #FFFFFF {
    rectangle "Сокетний дескриптор (File Descriptor 7)\n---\n• Тип: AF_INET / SOCK_STREAM (TCP)\n• Стан: ESTABLISHED\n• 5-Tuple ідентифікатор" as SockFD #DBEAFE

    rectangle "Буфер прийому (RX Buffer)\n[Черга вхідних байтів від клієнта]" as RX #FEF3C7
    rectangle "Буфер відправки (TX Buffer)\n[Черга вихідних байтів до клієнта]" as TX #FEE2E2

    queue "SYN Queue (Напіввідкриті)" as SynQ #E2E8F0
    queue "Accept Queue (Готові з'єднання)" as AccQ #DCFCE7
}

package "Апаратний рівень" #F1F5F9 {
    rectangle "Мережева карта (NIC / Ethernet / Wi-Fi)" as NIC #DBEAFE
}

App --> SockFD : Системні виклики (read / write / close)
SockFD --> RX : Читання (Read копіює дані)
App --> TX : Запис (Write копіює дані)

NIC --> RX : Прямий доступ до пам'яті (DMA)
TX --> NIC : Передача кадрів у мережу

NIC --> SynQ : Пакет SYN
SynQ --> AccQ : 3-Way Handshake завершено
AccQ --> App : net.Listener.Accept()
@enduml

Розглянемо ключові внутрішні компоненти сокета:

Типи сокетів та адресні сімейства

При створенні сокета в операційній системі визначаються два базові параметри: сімейство адрес та тип передачі даних.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 13

package "Сокети в системі POSIX" #F8FAFC {
    package "Адресні сімейства (Address Family / Domain)" #DBEAFE {
        rectangle "AF_INET\n(IPv4 адресація)" as inet #BFDBFE
        rectangle "AF_INET6\n(IPv6 адресація)" as inet6 #BFDBFE
        rectangle "AF_UNIX / AF_LOCAL\n(Локальний IPC між процесами)" as unix #BFDBFE
    }

    package "Типи передачі (Socket Types)" #DCFCE7 {
        rectangle "SOCK_STREAM\n(TCP: потоковий, надійний, зі збереженням порядку)" as stream #BBF7D0
        rectangle "SOCK_DGRAM\n(UDP: датаграмний, без з'єднання, швидкий)" as dgram #BBF7D0
        rectangle "SOCK_RAW\n(Прямий доступ до мережевих IP/ICMP пакетів)" as raw #BBF7D0
    }
}
@enduml

Життєвий цикл сокетів: Слухаючий сокет проти Сокета даних

Найпоширеніша плутанина серед студентів: «Якщо сервер слухає порт 8080, то всі клієнти спілкуються через цей самий сокет?»

Відповідь: Ні. У серверному застосунку існують сокети двох принципово різних типів:

1. Слухаючий сокет (Listening Socket / Master Socket):
   • Створюється викликом net.Listen("tcp", ":8080").
   • Не передає прикладних даних. Його єдина задача — «сидіти на порту 8080» і приймати нові запити на підключення від клієнтів.
2. Сокет даних / Сокет з'єднання (Connected / Data Socket):
   • Створюється ядром операційної системи у момент завершення 3-Way Handshake.
   • Повертається викликом listener.Accept() як об'єкт net.Conn.
   • Має свій власний незалежний номер дескриптора (наприклад, #7), власні буфери RX/TX і служить виключно для обміну повідомленнями з цим конкретним клієнтом.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam sequenceMessageAlign center
autonumber

participant "Клієнтський процес" as Client #DBEAFE
participant "Ядро ОС (Kernel)" as OS #E2E8F0
participant "Серверний процес (Go)" as Server #DCFCE7

note over Server
  1. Ініціалізація сервера:
  socket(AF_INET, SOCK_STREAM) -> fd #3
  bind(fd #3, 0.0.0.0:8080)
  listen(fd #3, backlog=128)
end note

Server -> OS : listener.Accept() [Блокується в очікуванні]

Client -> OS : socket() + connect(192.168.1.1:8080)
OS <-> Client : TCP 3-Way Handshake (SYN -> SYN-ACK -> ACK)

note over OS
  Ядро створює НОВИЙ сокет з'єднання!
  Client: 192.168.1.50:54321
  Server: 192.168.1.1:8080
  Новий дескриптор: fd #4
end note

OS --> Server : Accept() розблоковується, повертає fd #4 (net.Conn)
Server -> Server : go handleConnection(conn) [Окрема горутина]
Server -> OS : listener.Accept() [Знову чекає на наступного клієнта]

Client -> OS : write(fd, "GET / HTTP/1.1")
OS -> Server : conn.Read(buf) [Читання з RX буфера fd #4]
Server -> OS : conn.Write(buf) [Запис у TX буфер fd #4]
OS -> Client : TCP Data Segment (HTTP 200 OK)

Client -> OS : close() -> FIN
Server -> OS : conn.Close() -> FIN
note over OS : Звільнення fd #4 та буферів
@enduml

Як Go працює з сокетами під капотом: Магія Runtime Netpoller

У класичному сокетному програмуванні на C або C++ існує дилема:

• Блокуючі сокети (Blocking I/O): Виклик read() зупиняє весь потік ОС до приходу даних. Щоб обслужити 10 000 клієнтів, потрібно 10 000 важких потоків ОС, що призводить до вичерпання пам'яті.
• Неблокуючі сокети з мультиплексуванням (Non-blocking I/O + epoll/kqueue): Складний асинхронний код на базі функцій зворотного виклику (callbacks) або кінцевих автоматів (як у Node.js або Nginx), де дуже складно читати та налагоджувати код.

Рішення мови Go — Netpoller: Go поєднує простоту синхронного блокуючого коду з надзвичайною швидкістю неблокуючого введення/виведення.

1. Коли ви пишете net.Listen або net.Dial, Go відкриває сокет у системі завжди в неблокуючому режимі (O_NONBLOCK).
2. Коли горутина викликає conn.Read(buf), а в буфері ядра RX ще немає даних, операційна система повертає статус EAGAIN («даних немає»).
3. Замість того, щоб зависнути або повернути помилку розробнику, середовище виконання Go автоматично реєструє дескриптор сокета в системному мультиплексорі ядра (epoll у Linux, kqueue у macOS) і присипляє поточну горутину.
4. Потік процесора ОС миттєво перемикається на виконання іншої корисної роботи!
5. Як тільки мережева карта отримує байти і epoll сигналізує про готовність, внутрішній планувальник Netpoller миттєво будить сплячу горутину, і виклик Read() прозоро повертає прочитані байти.

Для розробника на Go код виглядає як звичайний послідовний синхронний код, але під капотом він працює з максимальною ефективністю сучасного асинхронного ядра ОС.

Чому саме Go для бекенд-систем? Інженерний аналіз

У сучасному ІТ-секторі існує чимало мов програмування: Java, C#, Python, JavaScript (Node.js), Rust. Чому ж компанії масштабу Google, Uber, Cloudflare, Netflix та тисячі інших обирають саме Go (Golang) для побудови мережевої інфраструктури, мікросервісів та високонавантажених API?

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 13

package "Філософія та сила Go" #F8FAFC {
    rectangle "Надзвичайна простота\n• 25 ключових слів\n• Відсутність наслідування\n• Качина типізація" as Simplicity #DBEAFE
    rectangle "Висока швидкодія\n• Нативна компіляція\n• Холодний старт (5–20 мс)\n• Низьколатентний GC" as Performance #DCFCE7
    rectangle "CSP Конкурентність\n• Горутини (2 КБ стек)\n• Типізовані канали\n• Планувальник GMP" as Concurrency #FEF3C7
}
@enduml

Архітектурне порівняння: Go vs Java (JVM) vs Python

Порівняння створення мінімального HTTP-сервера

Порівняємо реалізацію найпростішого HTTP-ендпоінта мовами Java та Go:

package main

import (
    "encoding/json"
    "log"
    "net/http"
)

type HealthResponse struct {
    Status  string `json:"status"`
    Service string `json:"service"`
}

func healthHandler(w http.ResponseWriter, r *http.Request) {
    resp := HealthResponse{
        Status:  "OK",
        Service: "Client-Server Demo API",
    }

    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusOK)
    if err := json.NewEncoder(w).Encode(resp); err != nil {
        log.Printf("Помилка серіалізації: %v", err)
    }
}

func main() {
    http.HandleFunc("/api/v1/health", healthHandler)

    log.Println("Сервер запущено на порту :8080...")
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatalf("Помилка запуску сервера: %v", err)
    }
}

package com.college.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.Map;

@SpringBootApplication
@RestController
public class Application {

    @GetMapping("/api/v1/health")
    public Map<String, String> health() {
        return Map.of(
            "status", "OK",
            "service", "Client-Server Demo API"
        );
    }

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Зверніть увагу: у прикладі на Go не використовується жодних сторонніх фреймворків чи рефлексивних анотацій — стандартна бібліотека net/http є повноцінним, промисловим, високоефективним сервером із підтримкою HTTP/2 «з коробки».

Інструментарій: Go CLI та модульна система

Якщо ви раніше працювали з іншими мовами програмування, ви, напевно, звикли до необхідності встановлювати десятки розрізнених утиліт: збирач проєкту (Maven/Gradle у Java, Webpack/Vite у JS), менеджер пакетів (npm, pip, nuget), тестовий раннер (JUnit, pytest, Jest), лінтер (ESLint) та інструмент форматування (Prettier).

У світі Go філософія інша: все необхідне для повного життєвого циклу розробки постачається разом із компілятором в одній-єдиній утиліті командного рядка — go.

Еволюція організації коду: від $GOPATH до Go Modules

Щоб зрозуміти сучасну структуру проєктів, корисно знати, від якої проблеми відштовхувалися розробники Go:

Відмінність між Пакетом (Package) та Модулем (Module)

Початківці часто плутають ці два фундаментальні терміни:

1. Пакет (Package):
   • Кожен файл із кодом на Go обов'язково починається з першого рядка: package <ім'я>. Цей рядок оголошує, до якої саме логічної коробки (пакета) належить цей файл.
   • Залізне правило компілятора Go: Усі .go файли, які лежать в одній і тій самій папці, повинні мати абсолютно однакове ім'я пакету в першому рядку (зазвичай ім'я пакету збігається з назвою самої папки).
   • Як це працює на практиці: Уявіть, що у вас є папка service/, а всередині два файли — order.go та payment.go. Обидва файли першим рядком пишуть package service. Компілятор Go об'єднує їх в єдине ціле: функція processPayment(), написана у файлі payment.go, буде миттєво доступна у файлі order.go без будь-яких імпортів чи підключень!
   • Особливий пакет package main: Якщо папка містить package main і функцію func main(), компілятор розуміє: «Це не просто бібліотека, це виконувана програма, яку треба скомпільувати у бінарний файл».
   • Інкапсуляція (Public vs Private): Якщо назва функції чи змінної починається з великої літери (наприклад, CalculateTotal), вона є публічною і буде доступна іншим пакетам через import. Якщо з малої літери (наприклад, validateCard) — вона є приватною і видима лише всередині файлів цього конкретного пакета.
2. Модуль (Module):
   • Це цілий проєкт або бібліотека, яка складається з дерева багатьох таких пакетів (папок), що мають єдину версію та керуються через файл go.mod.
   • Корінь модуля визначається наявністю файлу go.mod. Всі імпорти внутрішніх пакетів проєкту починаються з назви цього модуля.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 13

package "Go Модуль: github.com/student/ecommerce" #F8FAFC {
    file "go.mod [Паспорт модуля]" as Mod #DBEAFE
    file "go.sum [Криптографічні хеші]" as Sum #DBEAFE

    package "cmd/server (Пакет main)" #FEF3C7 {
        file "main.go" as Main
    }

    package "internal/service (Пакет service)" #DCFCE7 {
        file "order.go" as Ord
        file "payment.go" as Pay
    }

    package "internal/database (Пакет database)" #FCE7F3 {
        file "postgres.go" as DB
    }
}

Main ..> Ord : import "github.com/student/ecommerce/internal/service"
Ord ..> DB : import "github.com/student/ecommerce/internal/database"
@enduml

Стандартна структура каталогів (Standard Go Project Layout)

Хоча компілятор Go не нав'язує жорсткої структури папок, інженерне співтовариство використовує загальноприйнятий стандарт організації коду для бекенд-застосунків:

Анатомія конфігураційних файлів: go.mod та go.sum

Розглянемо вміст файлів маніфесту модуля на конкретному прикладі:

module github.com/student/my-backend

go 1.22

require (
    github.com/google/uuid v1.6.0
    github.com/gorilla/mux v1.8.1 // direct
    golang.org/x/crypto v0.21.0 // indirect
)

github.com/google/uuid v1.6.0 h1:NIvaJDMOfo6...
github.com/google/uuid v1.6.0/go.mod h1:TIym...
github.com/gorilla/mux v1.8.1 h1:TuBL49tXwIGFiU...
github.com/gorilla/mux v1.8.1/go.mod h1:TIym...

Розберемо детально призначення кожного елемента:

1. Директива module: Вказує канонічний шлях імпорту. Коли всередині вашого проєкту ви хочете підключити власний внутрішній пакет internal/service, рядок імпорту починається саме з цього шляху:

   import "github.com/student/my-backend/internal/service"
   

2. Директива go 1.22: Вказує мінімальну версію синтаксису мови Go, необхідну для збірки проєкту.
3. Блок require: Перелік зовнішніх сторонніх бібліотек із фіксованими семантичними версіями (Semantic Versioning: MAJOR.MINOR.PATCH).
   • Позначка // indirect означає непряму (транзитивну) залежність — це пакет, який потрібен не вашому коду напряму, а потрібен одній із підключених вами бібліотек.
4. Файл go.sum: Для кожного стороннього пакета тут зберігаються два 256-бітні криптографічні хеші: хеш вихідного коду бібліотеки (h1:...) та хеш її власного файлу go.mod.

Робота з Go CLI: Повний довідник інструментів

Уся розробка, тестування та компіляція здійснюється через вбудовані підкоманди утиліти go.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 13

package "Утиліта Go CLI (`go`)" #F8FAFC {
    rectangle "Керування залежностями\n• go mod init : Створити модуль\n• go get : Додати/оновити пакет\n• go mod tidy : Очистити залежності" as ModCmd #DBEAFE
    rectangle "Розробка та налагодження\n• go run : Запуск без створення файлу\n• go fmt : Стандартизація форматування\n• go vet : Статичний пошук багів" as DevCmd #FEF3C7
    rectangle "Збірка та тестування\n• go test : Автоматичні тести\n• go build : Компіляція у бінарник\n• go install : Встановлення у систему" as BuildCmd #DCFCE7
}
@enduml

Розглянемо практичне призначення та синтаксис кожної базової команди:

::

Порівняння Go CLI з іншими екосистемами

Для тих, хто приходить з інших мов програмування, корисно побачити аналогії команд:

Ваша перша програма: Анатомічний розбір Hello World

Перед тим як переходити до складних багатокомпонентних сервісів, створимо та розберемо найпростішу базову програму на мові Go.

Створіть файл main.go з наступним вмістом:

package main

import "fmt"

func main() {
    fmt.Println("Привіт, клієнт-серверний світе на Go! 🚀")
}

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 13

package "Анатомія файлу main.go" #F8FAFC {
    rectangle "1. package main\n• Оголошує пакет як виконувану точку входу" as Pkg #DBEAFE
    rectangle "2. import \"fmt\"\n• Підключає стандартний пакет форматування та вводу/виводу" as Imp #DCFCE7
    rectangle "3. func main()\n• Головна функція, з якої операційна система починає виконання" as Fn #FEF3C7
    rectangle "4. fmt.Println(...)\n• Виводить рядок у стандартний вивід (stdout)" as Out #FCE7F3
}

Pkg -down-> Imp
Imp -down-> Fn
Fn -down-> Out
@enduml

Розберемо детально призначення кожного рядка цього коду:

Глибоке занурення: Директива import та пакет fmt (Довідник I/O)

Для інженера клієнт-серверних систем пакет fmt є одним із найбільш часто використовуваних інструментів: від логування станів сервера до динамічної генерації SQL-запитів, JSON-рядків та форматування мережевих відповідей.

Синтаксис та можливості директиви import

У Go існує кілька способів підключення пакетів:

package main

// Спосіб 1: Груповий блок імпортів (Фабричний стандарт)
import (
    "fmt"                    // Стандартна бібліотека: форматування
    "net/http"               // Стандартна бібліотека: вебсервер
    "time"                   // Стандартна бібліотека: час

    myjson "encoding/json"   // Імпорт з псевдонімом (Alias) для уникнення конфліктів імен
    _ "github.com/lib/pq"    // Анонімний імпорт (Blank Import): запускає лише функцію init() драйвера БД
)

Архітектура та класифікація функцій пакету fmt

Усі функції пакету fmt спроєктовані за чіткою та логічною префіксною системою імен. Їх можна розділити на чотири головні сімейства:

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam defaultFontSize 12

package "Стандартний пакет `fmt`" #F8FAFC {
    rectangle "1. Консольне виведення (stdout)\n• Print() : Без переносу рядка\n• Println() : З пробілами та \\n\n• Printf() : За шаблоном %v" as StdoutGrp #DBEAFE
    rectangle "2. Форматування у рядок (String)\n• Sprint() : Повертає string\n• Sprintln() : З переносом рядка\n• Sprintf() : Форматує рядок за шаблоном" as StrGrp #DCFCE7
    rectangle "3. Запис у потік (io.Writer)\n• Fprint(w, ...)\n• Fprintln(w, ...)\n• Fprintf(w, format, ...) -> До сокета/файлу" as FileGrp #FEF3C7
    rectangle "4. Створення помилок та зчитування\n• Errorf() : Створює тип error\n• Scan() / Sscanf() / Fscanf() : Парсинг" as ErrGrp #FCE7F3
}
@enduml

Розглянемо кожну групу детально:

Група 1: Виведення у термінал (Stdout)

• fmt.Print(...) — послідовно виводить аргументи у консоль без додавання переносу рядка.
• fmt.Println(...) — виводить аргументи через пробіл і завжди завершує рядок символом \n.
• fmt.Printf(template, ...) — форматує виведення відповідно до специфікаторів форматування (наприклад, %d для чисел, %s для рядків).

Група 2: Форматування у рядок (S = String)

Функції цієї групи нічого не друкують у консоль, а повертають результат у вигляді готової змінної типу string:

• fmt.Sprintf("http://%s:%d/api", host, port) — фундаментальна функція для конструювання динамічних рядків, URL, SQL-запитів та повідомлень.

Група 3: Запис у довільний потік (F = File / io.Writer)

Найважливіша група для мережевого програмування. Першим аргументом вони приймають будь-який об'єкт, що реалізує інтерфейс io.Writer (мережевий TCP-сокет net.Conn, HTTP-відповідь http.ResponseWriter, відкритий файл на диску *os.File або буфер bytes.Buffer):

• fmt.Fprintf(w, "HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nHello!")

Група 4: Створення помилок

• fmt.Errorf("не вдалося підключитися до хоста %s: %w", host, err) — генерує новий об'єкт помилки, що реалізує стандартний інтерфейс error, із підтримкою пакування першопричин через специфікатор %w.

Довідник специфікаторів форматування (Format Verbs)

Специфікатори (або «верби») вказують функції Printf / Sprintf, як саме інтерпретувати та відображати значення:

Практичний демонстраційний лістинг роботи з fmt

package main

import (
    "fmt"
    "os"
)

type ServerConfig struct {
    Host string
    Port int
    TLS  bool
}

func main() {
    cfg := ServerConfig{Host: "127.0.0.1", Port: 8443, TLS: true}

    // 1. Різниця між %v, %+v та %#v
    fmt.Printf("Звичайне %%v:  %v\n", cfg)
    fmt.Printf("З полями %%+v: %+v\n", cfg)
    fmt.Printf("Go-код %%#v:   %#v\n", cfg)
    fmt.Printf("Тип змінної %%T: %T\n\n", cfg)

    // 2. Створення рядка через Sprintf (без виведення в консоль)
    serviceURL := fmt.Sprintf("https://%s:%d/health", cfg.Host, cfg.Port)
    fmt.Println("Згенерований URL:", serviceURL)

    // 3. Форматування чисел та байтів
    latency := 0.045678
    fmt.Printf("Затримка мережі: %.2f мс (Двійковий порт: %b)\n", latency*1000, cfg.Port)

    // 4. Запис у потік помилок os.Stderr через Fprintf
    fmt.Fprintf(os.Stderr, "[LOG WARN] Тестове повідомлення у потік помилок\n")
}

Два способи запуску програми через термінал

Після того як файл main.go збережено, розробник має два основні сценарії роботи з ним:

# Знаходимося в папці з файлом main.go
go run main.go

Привіт, клієнт-серверний світе на Go! 🚀

# Компілюємо виконуваний файл з ім'ям 'app'
go build -o app main.go

# Запускаємо скомпільований бінарник (на macOS / Linux):
./app

# (На Windows виконайте: app.exe)

Привіт, клієнт-серверний світе на Go! 🚀

Покроковий практичний воркфлоу створення бекенду

Погляньмо, як виглядає реальний цикл створення нового проєкту з нуля у терміналі:

mkdir -p my-server/cmd/server
cd my-server
go mod init github.com/student/my-server

go get github.com/google/uuid

package main

import (
    "fmt"
    "net/http"

    "github.com/google/uuid"
)

func main() {
    http.HandleFunc("/api/v1/token", func(w http.ResponseWriter, r *http.Request) {
        newID := uuid.New().String()
        fmt.Fprintf(w, `{"token": "%s"}`, newID)
    })

    fmt.Println("Сервер слухає на порту :8080...")
    http.ListenAndServe(":8080", nil)
}

go fmt ./...
go mod tidy
go run cmd/server/main.go

Кроскомпіляція (Cross-Compilation): як створювати бінарники під будь-яку ОС

У багатьох мовах програмування (наприклад, C++) збірка програми для іншої операційної системи (наприклад, збірка під Linux на комп'ютері з macOS) є вкрай складним завданням, що вимагає налаштування спеціальних віртуальних машин або складних наборів інструментів (Toolchains).

Компілятор Go має вбудовану підтримку генерації машинного коду під будь-яку операційну систему та процесор безпосередньо з коробки. Для цього достатньо встановити дві змінні середовища перед викликом команди go build:

• GOOS (Target Operating System): цільова ОС (linux, darwin, windows, freebsd).
• GOARCH (Target Architecture): цільова архітектура процесора (amd64 для x86_64, arm64 для Apple Silicon / AWS Graviton, arm для Raspberry Pi).

# Збірка під 64-бітний Linux без динамічних C-бібліотек (чистий автономний бінарник)
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -ldflags="-s -w" -o bin/server-linux-amd64 cmd/server/main.go

# Збірка під 64-бітні ARM сервери
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -ldflags="-s -w" -o bin/server-linux-arm64 cmd/server/main.go

# Збірка виконуваного файлу для ОС Windows
GOOS=windows GOARCH=amd64 go build -o bin/server.exe cmd/server/main.go

# Збірка для процесорів Apple M1/M2/M3
GOOS=darwin GOARCH=arm64 go build -o bin/server-macos-arm64 cmd/server/main.go

Передбачення запитань та аналіз підводних каменів («А що, якщо...?»)

Підсумки лекції та перевірка знань

Запитання для самоконтролю