Еволюція веброзробки та модель клієнт-сервер

Історичний контекст: шлях від документів до застосунків

Всесвітня павутина (World Wide Web), створена Тімом Бернерсом-Лі у 1989 році в CERN, спочатку задумувалася як проста система обміну науковими документами між дослідниками. Перші вебсайти складалися виключно зі статичних HTML-файлів (HyperText Markup Language), що зберігалися на сервері та передавалися клієнту без жодних змін. Вебсервер виконував примітивну роль файлового сховища: отримавши запит на певний документ, він лише зчитував відповідний файл з диска та відправляв його браузеру у незмінному вигляді.

Така модель ідеально підходила для публікації академічних статей, технічної документації та інформаційних ресурсів, проте вона не передбачала жодної інтерактивності. Користувач міг лише переглядати готові сторінки, переходячи за гіперпосиланнями, але не міг впливати на їхній вміст, здійснювати пошук, відправляти форми або отримувати персоналізовану інформацію. У цій парадигмі вебсервер був пасивним учасником комунікації — він не виконував обчислень та не приймав рішень щодо того, які дані показувати конкретному користувачеві.

Поява динамічної генерації вмісту

Революційний зрушення у веброзробці відбувся із запровадженням технологій серверного скриптингу (server-side scripting). У 1993 році з'являється CGI (Common Gateway Interface) — стандарт, що дозволяв вебсерверу викликати зовнішні програми (написані на Perl, C або інших мовах) для генерації HTML-коду «на льоту». Натомість статичного файлу сервер виконував програму, яка зчитувала параметри з HTTP-запиту, виконувала необхідну логіку (наприклад, пошук у базі даних), формувала результуюче HTML-представлення та повертала його клієнту.

Незабаром з'явилися спеціалізовані мови програмування та платформи для веброзробки: PHP (Personal Home Page, згодом PHP: Hypertext Preprocessor) у 1995 році, ASP (Active Server Pages) від Microsoft у 1996-му, JSP (JavaServer Pages) у 1999-му. Ці технології вбудовували код безпосередньо в HTML-шаблони, що спрощувало створення динамічних сторінок, проте призводило до тісного переплетення логіки відображення (presentation logic) та бізнес-правил.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF

rectangle "1991–1995\nСтатичні HTML-сайти\n--\nСервер повертає готові\nHTML-файли без змін.\nЖодної інтерактивності." as Static #E2E8F0
rectangle "1996–2003\nДинамічні сторінки (CGI, PHP, ASP)\n--\nСервер виконує скрипти,\nгенерує HTML за запитом.\nПоява баз даних." as Dynamic #DBEAFE
rectangle "2004–2010\nВебзастосунки (AJAX, SPA)\n--\nАсинхронні запити,\nбагатий UI у браузері.\nREST API." as WebApps #DCFCE7
rectangle "2011–нині\nМікросервіси та JAMstack\n--\nРозподілені системи,\nserverless, контейнеризація,\nAPI Gateway." as Modern #FDE68A

Static -down-> Dynamic : розвиток
Dynamic -down-> WebApps : розвиток
WebApps -down-> Modern : розвиток
@enduml

Ера вебзастосунків: AJAX та Single Page Applications

На початку 2000-х років домінуючою парадигмою залишалася модель, де кожна взаємодія користувача з інтерфейсом (клік на посилання, відправка форми) призводила до повного перезавантаження сторінки. Браузер надсилав новий HTTP-запит, сервер повертав цілісний HTML-документ, і браузер замінював весь вміст вікна. Це створювало неприємний досвід користування: інтерфейс «блимав», втрачалося прокручування, а навіть незначна зміна частини сторінки вимагала повторного завантаження всіх ресурсів.

Прорив відбувся із популяризацією технології AJAX (Asynchronous JavaScript and XML) після публікації статті Джессі Джеймса Гаррета у 2005 році. AJAX не був новою технологією — він об'єднував існуючі можливості браузера (об'єкт XMLHttpRequest, JavaScript, DOM-маніпуляції) у новий підхід до побудови інтерфейсів. Ключова ідея полягала в тому, що JavaScript-код, що виконується у браузері, може асинхронно надсилати HTTP-запити до сервера у фоновому режимі, отримувати дані (зазвичай у форматі XML, згодом JSON) та динамічно оновлювати лише ті частини сторінки, які цього потребують, без повного перезавантаження.

Ця парадигма дала поштовх розвитку односторінкових застосунків (Single Page Applications, SPA), де HTML-каркас завантажується один раз, а весь подальший обмін даними відбувається через AJAX-виклики до серверних API. Браузер перетворився на повноцінну платформу виконання додатків, здатну підтримувати складну бізнес-логіку на клієнтській стороні. З'явилися JavaScript-фреймворки — Angular (2010), Backbone.js (2010), Ember.js (2011), React (2013), Vue.js (2014) — що спрощували побудову таких застосунків та впроваджували архітектурні патерни (MVC, MVVM, компонентний підхід) у фронтенд-розробку.

Мікросервісна архітектура та безсерверні обчислення

Наприкінці 2000-х — на початку 2010-х років великі технологічні компанії (Amazon, Netflix, LinkedIn) зіткнулися з обмеженнями монолітної архітектури, де весь серверний код працював як єдиний застосунок у межах одного процесу або кластера ідентичних серверів. Масштабування монолітів вимагало реплікації всього застосунку, навіть якщо навантаження зростало лише на окремі функції (наприклад, пошук або рекомендаційну систему). Розгортання змін у монолітах було ризикованим — помилка в одній підсистемі могла «покласти» весь сервіс.

Відповіддю на ці виклики стала мікросервісна архітектура (microservices architecture), де застосунок розбивається на набір невеликих, автономних сервісів, кожен з яких відповідає за чітко окреслену бізнес-можливість (наприклад, «керування користувачами», «обробка платежів», «відправка повідомлень»). Кожен мікросервіс має власну базу даних, розгортається незалежно і спілкується з іншими через легковагові протоколи (HTTP REST, gRPC, черги повідомлень). Така декомпозиція дозволяє різним командам розробників працювати паралельно, вибирати різні технологічні стеки для різних сервісів та масштабувати лише ті компоненти, які цього потребують.

Паралельно розвивалася концепція безсерверних обчислень (serverless computing), де розробник пише лише бізнес-логіку у вигляді функцій (Functions as a Service, FaaS), а хмарна платформа (AWS Lambda, Google Cloud Functions, Azure Functions) автоматично керує виділенням ресурсів, масштабуванням та високою доступністю. У безсерверній моделі розробник не управляє віртуальними машинами чи контейнерами — платформа запускає функцію у відповідь на подію (HTTP-запит, зміну у базі даних, повідомлення у черзі) та стягує плату лише за фактичний час виконання коду.

Фундаментальні принципи архітектури клієнт-сервер

Архітектура клієнт-сервер є базовою моделлю побудови розподілених систем, у якій обчислювальні завдання та дані розподіляються між двома типами учасників: клієнтами (clients), що ініціюють запити, та серверами (servers), що обробляють ці запити та надають відповіді. Ця модель виникла задовго до появи веб — вона використовувалася у файлових системах (NFS), базах даних (клієнт-серверні СУБД на кшталт Oracle або PostgreSQL), електронній пошті (протоколи SMTP, POP3, IMAP) та багатьох інших прикладних областях.

Асиметрія ролей: ініціатор та постачальник

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

Сервер, як правило, є довготривалим процесом (long-running process), що постійно працює на певному вузлі мережі, прослуховує вказаний мережевий порт та обслуговує множину клієнтів одночасно. Клієнти, навпаки, можуть бути короткочасними: вони запускаються, коли користувач відкриває застосунок або вебсторінку, виконують необхідні дії та завершують роботу.

Централізація ресурсів та логіки

Одна із головних переваг клієнт-серверної архітектури полягає у централізації даних та бізнес-правил. Замість того, щоб зберігати копії даних на кожному клієнтському пристрої та синхронізувати їх вручну, дані зберігаються на сервері у централізованій базі даних. Це забезпечує консистентність (consistency): усі клієнти бачать актуальний стан інформації, а зміни, внесені одним клієнтом, негайно стають доступними іншим (після оновлення запиту).

Бізнес-логіка — правила обробки даних, валідації, авторизації, обчислень — також зосереджена на сервері. Це дозволяє уникнути дублювання коду між різними клієнтськими платформами (веббраузер, мобільний iOS-застосунок, Android-застосунок, десктопна програма) та спрощує оновлення логіки: достатньо модифікувати серверний код, і всі клієнти автоматично отримують нову поведінку без необхідності їхнього оновлення.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
autonumber

actor "Користувач" as User #E2E8F0
participant "Клієнт\n(Браузер)" as Client #DBEAFE
participant "Сервер\n(Backend)" as Server #DCFCE7
database "База даних" as DB #FEF3C7

User -> Client : Відкриває сторінку /products
Client -> Server : HTTP GET /api/v1/products
activate Server
Server -> DB : SELECT * FROM products WHERE active = true
DB --> Server : Результат запиту (список товарів)
Server --> Client : HTTP 200 OK + JSON (масив товарів)
deactivate Server
Client -> Client : Рендеринг списку товарів у DOM
Client --> User : Відображення інтерфейсу
@enduml

Масштабованість та ізоляція відмов

Клієнт-серверна модель спрощує горизонтальне масштабування (horizontal scaling) серверної частини. Коли кількість користувачів зростає, можна розгорнути кілька ідентичних примірників сервера та розподілити навантаження між ними за допомогою балансувальника навантаження (load balancer). Кожен запит клієнта направляється на один із доступних серверів, що дозволяє обслуговувати тисячі або мільйони одночасних користувачів без зміни архітектури застосунку.

Водночас, централізація створює єдину точку відмови (single point of failure): якщо сервер недоступний (через технічні несправності, атаки DDoS, перевантаження), усі клієнти втрачають доступ до сервісу. Для забезпечення високої доступності (high availability) використовуються методи резервування: розгортання серверів у різних центрах обробки даних, реплікація баз даних, автоматичне перемикання на резервні вузли.

Багатошарова архітектура: розділення відповідальності

Реальні вебзастосунки рідко обмежуються простою двокомпонентною структурою «клієнт — сервер». Замість цього вони організовуються як багатошарова (multi-layer) архітектура, де кожен шар (layer) відповідає за чітко визначену категорію завдань та взаємодіє лише з сусідніми шарами через формалізовані інтерфейси. Найпоширенішою є тришарова архітектура (three-layer architecture), що складається із шарів представлення, бізнес-логіки та доступу до даних.

Шар представлення (Presentation Layer)

Шар представлення (presentation layer, інколи називається UI layer або client layer) відповідає за взаємодію з користувачем. Цей шар включає веббраузер із завантаженим HTML, CSS та JavaScript-кодом, мобільний застосунок або десктопну програму. Його завдання полягає у відображенні інформації у зручному для користувача форматі, прийомі введених даних (через форми, кнопки, жести) та передачі цих даних на наступний рівень для обробки.

У контексті веброзробки шар представлення реалізується фронтенд-застосунком, написаним на JavaScript (або TypeScript) із використанням фреймворків на кшталт React, Angular, Vue.js або Svelte. Цей код виконується безпосередньо у браузері користувача та спілкується із сервером через HTTP-запити (зазвичай у форматі JSON через REST API або GraphQL).

Ключові обов'язки шару представлення:

• Рендеринг інтерфейсу: побудова DOM-дерева, застосування стилів, анімації, перехідні ефекти.
• Обробка подій користувача: реакція на кліки, введення тексту, прокручування, зміну розміру вікна.
• Валідація на стороні клієнта: перевірка формату email, довжини пароля, числових діапазонів перед відправкою даних на сервер (для покращення досвіду користувача, але не як основний механізм безпеки).
• Управління станом: збереження локального стану застосунку (поточний користувач, обраний продукт, вміст кошика) у пам'яті браузера або LocalStorage.
• Асинхронна комунікація: виконання AJAX-запитів до API, обробка відповідей, відображення індикаторів завантаження, помилок мережі.

Шар бізнес-логіки (Business Logic Layer)

Шар бізнес-логіки (business logic layer або application layer) містить ядро функціональності застосунку — правила, процедури та алгоритми, що визначають, як саме система обробляє дані та приймає рішення. Цей шар виконується на серверній стороні та ізольований від користувача. Він отримує запити від шару представлення, виконує необхідні обчислення, взаємодіє із шаром даних для читання та запису інформації, та повертає результати назад клієнту.

Приклади бізнес-логіки:

• Створення нового користувача: перевірка унікальності email, хешування пароля, збереження у базі даних, відправка підтверджувального листа.
• Оформлення замовлення: перевірка наявності товарів на складі, обчислення загальної вартості з урахуванням знижок та податків, резервування товарів, ініціювання платіжної транзакції, оновлення статусу замовлення.
• Авторизація доступу до ресурсу: перевірка JWT-токена, витягування ідентифікатора користувача, перевірка ролей та прав доступу, дозвіл або заборона операції.

Цей шар зазвичай реалізується у вигляді набору сервісів (services), класів або функцій, організованих відповідно до певного архітектурного патерну (наприклад, Domain-Driven Design, Clean Architecture, Hexagonal Architecture). У фреймворках на кшталт NestJS бізнес-логіка зосереджена у провайдерах (providers) та сервісних класах, що впроваджуються у контролери через механізм ін'єкції залежностей (dependency injection).

Шар доступу до даних (Data Access Layer)

Шар доступу до даних (data access layer, DAL) відповідає за взаємодію із системами зберігання інформації — реляційними базами даних (PostgreSQL, MySQL), NoSQL-сховищами (MongoDB, Redis), файловими системами, зовнішніми API. Його основне завдання — абстрагувати деталі роботи з конкретною технологією зберігання від шару бізнес-логіки, надаючи останньому простий інтерфейс для операцій читання, запису, оновлення та видалення даних.

Цей шар реалізується через патерн Repository (сховище), де для кожної сутності предметної області (користувач, продукт, замовлення) створюється клас-репозиторій, що інкапсулює SQL-запити або виклики ORM (Object-Relational Mapping). Наприклад, UserRepository може містити методи findById(id: string), findByEmail(email: string), create(user: User), update(user: User), delete(id: string). Бізнес-логіка викликає ці методи, не знаючи, як саме дані зберігаються фізично — у таблиці PostgreSQL, документі MongoDB чи навіть у пам'яті.

Переваги шару доступу до даних:

• Ізоляція змін: якщо потрібно змінити СУБД (наприклад, мігрувати з MySQL на PostgreSQL) або додати кешування запитів через Redis, достатньо модифікувати лише репозиторії, не торкаючись бізнес-логіки.
• Тестованість: бізнес-логіку можна тестувати ізольовано, підставляючи замість справжніх репозиторіїв їхні макети (mocks), що повертають заздалегідь визначені дані без звернення до реальної бази.
• Контроль транзакцій: шар DAL керує початком, фіксацією та відкатом транзакцій, забезпечуючи консистентність даних при складних операціях, що охоплюють кілька таблиць.
• Оптимізація запитів: репозиторії можуть використовувати складні запити із з'єднаннями (joins), індексами, пагінацією, не розкриваючи ці деталі вищим шарам.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam componentStyle rectangle

package "Presentation Layer (Шар представлення)" #E2E8F0 {
    [Веббраузер\n(React, Vue)] as Browser
    [Мобільний застосунок\n(iOS, Android)] as Mobile
}

package "Business Logic Layer (Шар бізнес-логіки)" #DBEAFE {
    [HTTP API\n(REST / GraphQL)] as API
    [Сервіси\n(Обробка замовлень,\nАутентифікація)] as Services
}

package "Data Access Layer (Шар доступу до даних)" #DCFCE7 {
    [Репозиторії\n(UserRepo, OrderRepo)] as Repos
    [ORM\n(TypeORM, Prisma)] as ORM
}

database "База даних\n(PostgreSQL)" as DB #FEF3C7
database "Кеш\n(Redis)" as Cache #FEF3C7

note bottom of "Presentation Layer (Шар представлення)"
  Логічний шар: UI та взаємодія з користувачем.
  Може виконуватися на клієнтських пристроях
  (фізично окремий tier).
end note

note bottom of "Business Logic Layer (Шар бізнес-логіки)"
  Логічний шар: бізнес-правила та оркестрація.
  Зазвичай виконується на серверах застосунків
  (application tier).
end note

note bottom of "Data Access Layer (Шар доступу до даних)"
  Логічний шар: абстракція над СУБД.
  Може бути на тому ж сервері застосунків
  або окремо (database tier).
end note

Browser -down-> API : HTTP/HTTPS
Mobile -down-> API : HTTP/HTTPS
API -down-> Services : виклик методів
Services -down-> Repos : запит даних
Repos -down-> ORM : побудова SQL
ORM -down-> DB : виконання запитів
Repos -down-> Cache : читання/запис кешу
@enduml

Розмежування понять Backend та Frontend

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

Frontend: клієнтська частина застосунку

Frontend (фронтенд, дослівно «передня частина») охоплює все, що виконується на стороні користувача — у браузері, мобільному застосунку або десктопній програмі. Це шар представлення із попереднього розділу, але у ширшому розумінні frontend включає також екосистему інструментів для розробки інтерфейсів: системи збирання (Webpack, Vite, Rollup), транспілятори (Babel, TypeScript), CSS-препроцесори (Sass, Less), фреймворки компонентного UI (React, Vue, Svelte), бібліотеки управління станом (Redux, Zustand, Pinia).

Основні обов'язки frontend-розробника:

• Побудова інтерфейсу користувача: створення сторінок, форм, навігаційних меню, модальних вікон, адаптивного дизайну для різних розмірів екранів (responsive design).
• Забезпечення доступності (Accessibility, a11y): підтримка клавіатурної навігації, зчитувачів екрану (screen readers), семантичної розмітки HTML, контрастності кольорів.
• Оптимізація продуктивності: зменшення розміру JavaScript-пакетів (code splitting), ледаче завантаження (lazy loading), кешування ресурсів, мінімізація часу до інтерактивності (time-to-interactive).
• Інтеграція з API: виконання HTTP-запитів до backend-сервісів, обробка станів завантаження, успіху та помилок, відображення індикаторів прогресу.

Backend: серверна частина застосунку

Backend (бекенд, «задня частина») є серверною частиною системи, що виконує бізнес-логіку, управляє даними, забезпечує безпеку та інтегрується із зовнішніми сервісами. Backend реалізується на серверних мовах програмування (JavaScript/TypeScript на платформі Node.js, Python, Java, Go, C#, Ruby, PHP) та розгортається на віддалених серверах або у хмарних середовищах (AWS, Google Cloud, Azure, DigitalOcean).

Основні обов'язки backend-розробника:

• Проєктування та реалізація API: створення REST, GraphQL або gRPC-інтерфейсів, визначення ендпоінтів, методів HTTP, форматів запитів та відповідей.
• Робота з базами даних: моделювання схеми даних, написання складних запитів, оптимізація індексів, керування транзакціями, міграції схеми.
• Автентифікація та авторизація: реалізація реєстрації, входу, відновлення пароля, видачі токенів (JWT, OAuth 2.0), перевірка ролей та дозволів.
• Безпека: захист від SQL-ін'єкцій, XSS, CSRF, валідація вхідних даних, шифрування чутливої інформації, налаштування HTTPS, CORS, заголовків безпеки.
• Масштабованість та продуктивність: проєктування архітектури, що витримує високі навантаження (кешування, балансування навантаження, асинхронна обробка через черги, горизонтальне масштабування).
• Інтеграції: взаємодія з платіжними системами (Stripe, PayPal), поштовими сервісами (SendGrid, AWS SES), сторонніми API (соціальні мережі, геолокація, аналітика).
• Фонові завдання: планування періодичних задач (генерація звітів, очищення застарілих даних), обробка черг повідомлень (RabbitMQ, Kafka), відправка email та push-нотифікацій.

Взаємодія Frontend та Backend: API як контракт

Frontend та backend взаємодіють через чітко визначений програмний інтерфейс (Application Programming Interface, API), що виступає формальним контрактом між обома сторонами. Найпоширенішим стилем API у веброзробці є REST (Representational State Transfer) — архітектурний підхід, що використовує стандартні HTTP-методи (GET, POST, PUT, PATCH, DELETE) для операцій над ресурсами, представленими у форматі JSON.

Приклад REST API для керування користувачами:

• GET /api/v1/users — отримання списку всіх користувачів (з пагінацією).
• GET /api/v1/users/:id — отримання даних конкретного користувача за ідентифікатором.
• POST /api/v1/users — створення нового користувача (тіло запиту містить JSON із даними).
• PUT /api/v1/users/:id — повне оновлення користувача (заміна всіх полів).
• PATCH /api/v1/users/:id — часткове оновлення користувача (зміна окремих полів).
• DELETE /api/v1/users/:id — видалення користувача.

Frontend-застосунок викликає ці ендпоінти через JavaScript-функції (наприклад, fetch() або бібліотеку axios), надсилаючи токен автентифікації у заголовку Authorization, та обробляє відповіді, оновлюючи інтерфейс відповідно до результату.

Роль серверної частини у сучасних вебзастосунках

Незважаючи на зростання можливостей клієнтських технологій та появу концепцій на кшталт JAMstack (JavaScript, APIs, Markup), де значна частина логіки переноситься у браузер та статичні генератори сайтів, backend залишається незамінним компонентом будь-якої серйозної системи. Розглянемо ключові сфери відповідальності серверної частини, які неможливо делегувати клієнту з міркувань безпеки, продуктивності чи функціональності.

Єдине джерело істини для даних

Backend є авторитетним джерелом даних (single source of truth). Усі критичні інформаційні активи — користувацькі акаунти, фінансові транзакції, історія замовлень, конфіденційні документи — зберігаються на сервері у контрольованому середовищі. Клієнт може мати локальні копії для відображення, проте рішення про дійсність цих даних (чи є баланс достатнім для операції, чи має користувач право переглядати документ) завжди приймається на сервері.

Якщо довіряти клієнту приймати рішення про дозволи або обчислювати вартість, зловмисник може змінити JavaScript-код у браузері (через інструменти розробника або проксі-перехоплювач на кшталт Burp Suite), підробити результати та здійснити несанкціоновані дії (купити товар за нульову ціну, отримати доступ до чужих даних).

Виконання ресурсомістких обчислень

Деякі завдання вимагають значних обчислювальних потужностей, доступу до спеціалізованого апаратного прискорення (GPU для машинного навчання) або великих обсягів пам'яті. Приклади таких завдань:

• Генерація звітів: агрегація мільйонів записів транзакцій за місяць, побудова складних графіків, експорт у форматі PDF або Excel.
• Обробка зображень та відео: перекодування відео у різні роздільності та формати, розпізнавання облич, автоматичне обрізання та стиснення зображень.
• Машинне навчання: виконання інференсу нейронних мереж для рекомендаційних систем, класифікації контенту, генерації тексту або зображень.
• Складні бізнес-розрахунки: маршрутизація логістичних маршрутів, оптимізація розкладу, симуляції фінансових моделей.

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

Інтеграція із зовнішніми сервісами

Backend виступає посередником між фронтенд-застосунком та зовнішніми API третіх сторін. Наприклад, при обробці платежу backend взаємодіє з платіжним шлюзом (Stripe, PayPal), надсилаючи секретні API-ключі, які ніколи не повинні потрапити на клієнта. Аналогічно, для відправки email backend інтегрується з поштовим сервісом (SendGrid, AWS SES), передаючи автентифікаційні токени, що зберігаються у безпечних змінних оточення сервера.

Таке проксіювання запитів дозволяє:

• Захистити облікові дані: API-ключі, паролі, сертифікати зберігаються на сервері, а не у коді, доступному користувачеві.
• Абстрагувати складність: frontend викликає простий ендпоінт POST /api/v1/payments, а backend керує всією складною логікою взаємодії із платіжною системою (retry-логіка, обробка webhook, відкат транзакції при помилці).
• Контролювати витрати: деякі зовнішні сервіси стягують плату за кожен запит. Backend може кешувати результати, агрегувати запити або впроваджувати rate limiting, щоб запобігти зловживанням.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF

actor "Користувач" as User #E2E8F0
participant "Frontend" as FE #DBEAFE
participant "Backend API" as BE #DCFCE7
participant "База даних" as DB #FEF3C7
participant "Stripe API" as Stripe #E2E8F0
participant "SendGrid API" as Email #E2E8F0

User -> FE : Натискає "Оплатити"
FE -> BE : POST /api/v1/payments\n{orderId, paymentMethod}
activate BE
BE -> DB : Перевірка статусу замовлення
DB --> BE : Замовлення підтверджено
BE -> Stripe : POST /v1/charges\n{amount, currency, token}\n(Секретний API-ключ)
Stripe --> BE : Платіж успішний\n{chargeId}
BE -> DB : Оновлення статусу замовлення\n(PAID)
BE -> Email : POST /v3/mail/send\n(Секретний API-ключ)\nВідправлення чека клієнту
Email --> BE : Email відправлено
BE --> FE : 200 OK {orderId, status: "paid"}
deactivate BE
FE --> User : "Платіж успішний!"
@enduml

Забезпечення безпеки та комплаєнсу

Backend є останнім рубежем захисту у системі. Усі вхідні дані, що надходять від клієнта, мають розглядатися як недовірені (untrusted input) та проходити суворе валідування, санітизацію та перевірку авторизації на сервері. Навіть якщо frontend виконує валідацію форм (перевірка формату email, мінімальної довжини пароля), backend повинен дублювати цю валідацію, оскільки зловмисник може надіслати HTTP-запит безпосередньо, обійшовши інтерфейс.

Крім того, backend відповідає за дотримання нормативних вимог (compliance), таких як GDPR (захист персональних даних у Європейському Союзі), HIPAA (конфіденційність медичних записів у США), PCI DSS (безпека обробки платіжних карт). Це включає шифрування даних у спокої (data at rest) та при передачі (data in transit), аудит доступу, право на забуття (right to be forgotten), анонімізацію логів.

Підсумок

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

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

Контрольні питання для самоперевірки

1. Опишіть основні етапи еволюції веброзробки від статичних сторінок до мікросервісів. Які технологічні зрушення спричинили кожен перехід?
2. Поясніть різницю між клієнтом і сервером в архітектурі клієнт-сервер. Хто ініціює комунікацію та чому ця асиметрія є принциповою?
3. Охарактеризуйте три шари багатошарової архітектури (презентація, бізнес-логіка, доступ до даних). Наведіть конкретні приклади відповідальності кожного шару.
4. Чому валідація вхідних даних повинна виконуватися і на клієнті, і на сервері? Яка роль кожної валідації?
5. Поясніть, чому критичні обчислення вартості замовлення або перевірки прав доступу не можна довірити клієнтській частині застосунку.
6. Наведіть приклад ситуації, коли backend виступає посередником між frontend та зовнішнім API. Які переваги надає таке проксіювання?
7. У чому полягає різниця між монолітною та мікросервісною архітектурою? За яких умов доцільно переходити до мікросервісів?

Додаткові матеріали для поглибленого вивчення