# Как устроена разработка — сервер, клиент, БД

> [HTML-версия](https://learnvibecoding.ru/publiclessons/kak-ustroena-razrabotka-server-klient-bd) · [Индекс для LLM](https://learnvibecoding.ru/llms.txt) · [Политика использования материалов](https://learnvibecoding.ru/politika-materialov)
> Материалы защищены. Обучение LLM без согласия запрещено. При разрешённом использовании — обязательна прямая ссылка на страницу-источник.

**Курс:** Основы разработки

# Как устроена разработка — сервер, клиент, БД
## Что происходит за кулисами, когда ты используешь Instagram, YouTube, Gmail

Ты спроектировал свой продукт на предыдущих уроках. Теперь нужно понять, **как это всё работает технически**. Это знание не для того, чтобы ты сам писал код, а чтобы ты понимал, что возможно, что сколько стоит и как долго делается.

> **Маршрут модуля:** полная таблица уроков — в [INDEX.md](INDEX.md). Кратко: **Git** (теория) — **урок 9**, команды в терминале — **практика 10**; **окружение** (что ставить) — **урок 11**, установка и запуск — **практика 12**.

### Ты открываешь приложение Instagram

```
ТЫ (на телефоне) →  Открыл Instagram

Что ты видишь?
- Свой профиль
- Посты, которые ты постил
- Ленту от друзей
- Комментарии к своим постам
- Уведомления о лайках
```

### Что происходит за кулисами?

```
Шаг 1: Ты вводишь логин и пароль
├─→ Отправляются на серверы Instagram в облаке

Шаг 2: Серверы Instagram проверяют в БД
├─→ Есть ли такой пользователь?
├─→ Пароль верный?

Шаг 3: Если всё верно, сервер говорит: "Окей, это ты"
├─→ Даёт телефону специальный ключ (токен)

Шаг 4: Телефон запрашивает у сервера
├─→ "Покажи мне мою ленту"

Шаг 5: Сервер идёт в БД
├─→ Достаёт посты твоих друзей
├─→ Достаёт комментарии
├─→ Достаёт лайки
├─→ Отправляет всё на телефон

Шаг 6: Телефон показывает красивый интерфейс
├─→ Ты видишь ленту
```

### Почему нельзя было сделать это по-другому?

❌ **Вариант 1: Всё на телефоне**
```
Посты твоих друзей нужно как-то узнать.
Откуда их взять, если они на других телефонах?

Друг Коля → Его телефон
       ↓
    Его посты
       
Твой телефон не может общаться с телефоном Коли напрямую.
Нужен промежуточный сервер, который скажет:
"Коля, Маша хочет видеть твои посты. Вот они для неё"
```

❌ **Вариант 2: Один большой сервер, но без базы данных**
```
Сервер Instagram получает твой пост.
Хранит его в памяти RAM (временная память).

Но когда сервер перезагружается или падает → ВСЕ ДАННЫЕ ТЕРЯЮТСЯ!
Все твои посты, все фото, все комментарии → ПУФФ! Исчезнули.

Это катастрофа!
```

✅ **Вариант 3: Сервер + База данных**
```
Сервер Instagram получает твой пост.
Сохраняет его в БД (жёсткий диск).

БД хранит данные ПОСТОЯННО.
Даже если сервер падает 100 раз → данные не теряются.
```

---

## Блок 2: Три компонента, которые работают вместе

![Клиент, Сервер, База данных](https://nhvwqitwebmmswnjylop.supabase.co/storage/v1/object/public/Pictures%20for%20course/Product,%20AI%20product,%20vibecoding/client_server_db.png)

### Компонент 1: Клиент (то, что видит пользователь)

```
Клиент = то, что ты видишь на экране

Примеры:
- Instagram приложение на телефоне
- YouTube в браузере на компьютере
- Gmail приложение для почты
- Telegram на телефоне

Что делает клиент?
✅ Показывает информацию красиво
✅ Позволяет тебе вводить данные (нажимать кнопки, писать текст)
✅ Отправляет информацию на сервер ("Я нажал лайк!")
✅ Получает новые данные со сервера
```

### Компонент 2: Сервер (мозг приложения)

```
Сервер = компьютер в облаке, который работает 24/7

Примеры:
- Серверы Instagram (на самом деле сотни серверов)
- Серверы YouTube (огромный центр обработки данных)
- Серверы Gmail (Google облако)

Что делает сервер?
✅ Получает запрос от клиента
✅ Проверяет: "А кто ты? У тебя есть права на это?"
✅ Обрабатывает данные (например, подсчитывает лайки)
✅ Идёт в БД и берёт или сохраняет данные
✅ Отправляет результат обратно клиенту

Пример:
Ты нажимаешь "Лайк" под постом в Instagram
  ↓
Клиент отправляет серверу: "Этот пост лайкнул"
  ↓
Сервер проверяет: "Это правда ты? У тебя есть такой пост?"
  ↓
Сервер идёт в БД: "Добавь один лайк к этому посту"
  ↓
БД выполняет: "Ок, тут было 100 лайков, теперь 101"
  ↓
Сервер отправляет клиенту: "Готово! Теперь 101 лайк"
  ↓
Ты видишь на экране: "101 лайк" вместо "100 лайков"
```

### Компонент 3: База данных (память приложения)

```
БД = огромное хранилище всех данных

Примеры:
- Instagram БД содержит все посты, все комментарии, все лайки ВСЕХ 2 миллиардов пользователей
- YouTube БД содержит информацию о каждом видео, каждом просмотре, каждом лайке
- Gmail БД содержит каждое письмо каждого пользователя

Что хранит БД?
✅ Информацию о пользователях (имя, email, пароль в зашифрованном виде)
✅ Все данные, которые пользователь создал (посты, видео, письма)
✅ Все отношения между данными (кто подписан на кого, кто лайкнул что)
✅ Историю действий (когда был создан пост, когда последний раз пользователь входил)

Особенность БД:
- Она находится на ЖЁСТКОМ ДИСКЕ (не в памяти)
- Если сервер упадёт, данные не теряются
- БД специально оптимизирована для быстрого поиска нужных данных
```

---

## Блок 3: Архитектура на примере YouTube

```
ПОЛЬЗОВАТЕЛЬ (ты на компьютере или телефоне)
    ↓
    ├─→ Открываешь YouTube в браузере
    ├─→ Вводишь логин-пароль
    ├─→ Видишь рекомендованные видео
    ├─→ Нажимаешь на видео
    ├─→ Смотришь видео
    ├─→ Ставишь лайк или комментарий
    ├─→ Загружаешь своё видео
    
[КЛИЕНТ - то, что ты видишь на экране]
    ↓
    ├─→ Интерфейс YouTube (красивые кнопки, видеоплеер, комментарии)
    
[ИНТЕРНЕТ - связь между клиентом и сервером]
    ↓
    ├─→ Твоё действие → отправляется на сервер
    ├─→ Ответ сервера → приходит к тебе
    
[СЕРВЕР - мозг YouTube, находится в облаке]
    ↓
    ├─→ Получает твой логин
    ├─→ Проверяет в БД: есть ли такой пользователь?
    ├─→ Если ты нажал "Лайк" → проверяет правила
    ├─→ Обновляет БД: добавляет лайк
    ├─→ Отправляет обратно: "Готово, лайк учтён"
    
[БД - память YouTube, жёсткий диск]
    ↓
    ├─→ Таблица ПОЛЬЗОВАТЕЛИ (2 млрд записей)
    │   └─→ ID пользователя, имя, email, когда зарегистрировался...
    ├─→ Таблица ВИДЕО (4+ млрд записей)
    │   └─→ Название, описание, кто загрузил, когда, длительность...
    ├─→ Таблица ЛАЙКИ (десятки млрд записей)
    │   └─→ Кто лайкнул, какое видео, когда...
    ├─→ Таблица КОММЕНТАРИИ
    │   └─→ Текст комментария, кто написал, к какому видео...
```

---

## Блок 4: Локальный сервер (localhost) — где разработчик тестирует

### Проблема: Как разработчик тестирует своё приложение перед запуском?

```
Вариант 1 — Неправильный:
Написал код → сразу загрузил в интернет → люди начали тестировать
Результат: Баги в production! Люди видят ошибки!

Вариант 2 — Правильный:
Написал код → тестирую на своём компьютере → проверяю, всё ли работает
Результат: Исправляю баги локально → загружаю в интернет → люди видят рабочее приложение
```

### Что такое localhost?

```
localhost = твой собственный компьютер

Когда разработчик тестирует приложение:
1. На своём компьютере запускается сервер
   (это может быть тот же компьютер, на котором он пишет код)

2. Браузер открывает: http://localhost:3000
   (это значит: открой приложение, которое запущено НА ЭТОМ компьютере)

3. Всё работает локально, никто в интернете это не видит

Пример:
- Разработчик YouTube написал код нового плеера
- Запустил локальный сервер на своём компьютере
- Открыл http://localhost:3000
- Тестирует плеер: загружает видео, нажимает play, ставит лайк
- Всё работает? → Теперь загружает на настоящий сервер YouTube
- Люди в интернете видят новый плеер!

localhost = тестовая площадка, которую видит только разработчик
```

---

## Блок 5: Продакшен сервер и Deploy

![Localhost vs Deploy](https://nhvwqitwebmmswnjylop.supabase.co/storage/v1/object/public/Pictures%20for%20course/Product,%20AI%20product,%20vibecoding/localhost_vs_production.png)

### Что такое Deploy?

**Deploy** = загрузка приложения на настоящий сервер в интернете, чтобы люди могли его использовать.

### История развёртывания (на примере Telegram)

```
Этап 1: Локальное тестирование
├─→ Разработчик Telegram пишет код обновления (новые стикеры)
├─→ Запускает локальный сервер на своём компьютере
├─→ Открывает http://localhost:3000
├─→ Тестирует: отправляет сообщение, скачает стикер, всё работает?
├─→ Видит баг: стикер грузится медленно
├─→ Исправляет баг локально (меняет код, тестирует снова)

Этап 2: Staging (предпродакшен) сервер
├─→ Разработчик загружает код на тестовый сервер Telegram
├─→ Это не настоящий Telegram, а его копия
├─→ Тестирует ещё раз на "почти настоящем" сервере
├─→ Проверяет: работает ли быстро с реальной нагрузкой?
├─→ Проверяет: нет ли проблем с безопасностью?

Этап 3: Production Deploy
├─→ Если всё окей, разработчик делает deploy на настоящий Telegram
├─→ 1+ млрд пользователей Telegram видят новое обновление!
├─→ Если вдруг возникла проблема → откатывают обновление назад
```

### Где находится production сервер?

```
Вариант 1: Собственный сервер (дорого)
├─→ Компания покупает физический компьютер
├─→ Ставит его в центр обработки данных (data center)
├─→ Платит за электричество, охлаждение, интернет
├─→ Пример: больших компании обычно так делают (Facebook, Google)

Вариант 2: Облако (cloud) — дешевле и проще
├─→ Арендуешь сервер у облачного провайдера
├─→ AWS, Google Cloud, Azure, DigitalOcean, Heroku и т.д.
├─→ Платишь только за то, что используешь
├─→ Не нужно думать о охлаждении, электричестве, безопасности
├─→ Пример: индивидуальные разработчики и стартапы делают так
```

### Где запускать продукт: Vercel, Railway или VPS

Когда говорят "облако", на практике это три разных варианта:

```
Vercel — только фронтенд и serverless функции
├─→ Сделан для: Next.js, React, статичные сайты, SSR
├─→ Бэкенд работает как serverless (запрос → код запустился → выключился)
├─→ Нет постоянного сервера → нельзя держать WebSocket и долгие фоновые задачи
├─→ Cron jobs есть, но ограниченные: на бесплатном плане — раз в сутки, на Pro — любое расписание
├─→ БД — подключаешь отдельно (Supabase, PlanetScale)
├─→ Пример: лендинг, Next.js приложение без тяжёлого бэкенда

Railway / Render — фронт + бэк + БД всё вместе
├─→ Постоянный контейнер — сервер работает 24/7
├─→ Можно держать фронт, бэкенд, PostgreSQL, Redis, cron — в одном проекте
├─→ Нет cold starts на платных планах (на бесплатном Render засыпает через 15 мин и стартует ~1 минуту)
├─→ Деплой такой же простой — git push → задеплоилось
├─→ Пример: SaaS с базой данных, AI продукт с бэкендом, Telegram-бот

VPS (Virtual Private Server) — Hetzner, DigitalOcean, AWS EC2
├─→ Ты арендуешь "кусок" физического сервера в дата-центре
├─→ Получаешь голый Linux — устанавливаешь всё сам
├─→ Фронт + бэк + БД лежат на одной машине — всё под контролем
├─→ Дешевле всего: Hetzner от €4/месяц за нормальный сервер
├─→ Но: нужно самому настраивать, обновлять, следить за безопасностью
├─→ Инструменты типа Coolify или Dokploy делают VPS похожим на Railway — 
│   управляешь через UI, не через терминал
├─→ Пример: когда Railway/Render становятся дорогими, или нужен полный контроль
```

**VPS (Virtual Private Server)** = арендованный виртуальный сервер. Физически это один из виртуальных "кусков" мощного физического сервера в дата-центре.

```
Когда брать Vercel:
├─→ Твой продукт — фронтенд на Next.js или статичный сайт
├─→ Бэкенд-логики минимум или её нет

Когда брать Railway / Render:
├─→ AI-продукт, SaaS, Telegram-бот — нужен постоянный бэкенд
├─→ Нужна БД (PostgreSQL, Redis) рядом с кодом
├─→ Хочешь деплоить просто, без настройки серверов
├─→ Большинство AI-продуктов в 2026 запускают именно здесь

Когда брать VPS:
├─→ Счёт на Railway/Render вырос и хочешь платить меньше
├─→ Нужно несколько продуктов на одной машине
├─→ Coolify превращает VPS в такую же панель как Railway — одна команда в терминале
│   устанавливает всё (Docker, SSL, CI/CD), дальше деплоишь через UI без командной строки
│   (curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash — буквально одна строка)
```

**Вывод для основателя:** Для AI-продукта с бэкендом — Railway или Render. Vercel — только если делаешь фронтенд без постоянного сервера. VPS имеет смысл, когда вырастешь или хочешь держать несколько проектов на одной машине.

---

### Как работает Deploy на облаке (на примере Notion)

```
Разработчик Notion пишет код и закончивает работу
    ↓
    git push origin main (загружает код на GitHub)
    ↓
GitHub видит обновление
    ↓
Автоматически отправляет код на облако (Vercel, AWS)
    ↓
Облако скачивает код
    ↓
Облако запускает сервер
    ↓
Облако берёт БД (все данные пользователей)
    ↓
100 млн пользователей Notion видят новую версию!
```

---

## Блок 6: Что происходит при одновременных действиях (многопользовательская нагрузка)

### Пример: Трендовый твит в Twitter/X

```
Новый твит выложили, и он взлетел.
50 млн человек одновременно смотрят этот твит.

Что происходит?
```

### Почему один сервер не справляется

```
Один сервер может обработать ~10 000–50 000 простых HTTP запросов в секунду.
Для тяжёлых запросов (AI API + запросы в БД) — реально ~100–1000 в секунду в зависимости от задачи.
Если на твит смотрят 50 млн человек одновременно
  = 50 000 000 запросов в секунду
  = сервер сломается, все видят ошибку!

Решение: Много серверов, работающих вместе!
```

### Архитектура Twitter/X (упрощённо)

```
50 млн пользователей по всему миру

     USA                EUROPE              ASIA
      ↓                  ↓                   ↓
   Сервер #1          Сервер #2          Сервер #3
   (Нью-Йорк)         (Лондон)           (Токио)
      │                  │                   │
      └──────────────────┴───────────────────┘
                    ↓
        Одна БД или несколько копий БД
        (каждый сервер копирует нужные данные)
```

**Балансировка нагрузки:**
```
Пользователь в Америке → идёт на сервер #1 (Нью-Йорк, близко)
Пользователь в Европе → идёт на сервер #2 (Лондон, близко)
Пользователь в Азии → идёт на сервер #3 (Токио, близко)

Все серверы разговаривают с одной БД:
"Сколько сейчас лайков у этого твита?"

БД отвечает: "100 млн лайков"
```

---

## Блок 7: Микросервисы — разделение обязанностей

![Монолит vs Микросервисы](https://nhvwqitwebmmswnjylop.supabase.co/storage/v1/object/public/Pictures%20for%20course/Product,%20AI%20product,%20vibecoding/monolith_vs_microservices.png)

### Проблема: Один большой сервер

```
Один сервер управляет ВСЕМ:
- Авторизацией (логин/пароль) → медленно обновляется
- Лентой (какие посты показывать) → требует тяжелые вычисления
- Лайками (кто лайкнул) → постоянно обновляется
- Комментариями → постоянно обновляется
- Поиском → медленные запросы
- Рекомендациями → очень медленные вычисления (AI)
- Уведомлениями → должны быть быстрыми
- Платежами → критично безопасны

Если сломалась часть для рекомендаций → весь сервер медленный!
Все люди видят, что приложение тормозит.
```

### Решение: Микросервисы (на примере Instagram)

```
Вместо одного большого сервера → много маленьких сервисов

Микросервис #1: АВТОРИЗАЦИЯ
├─→ Отвечает только за логин/пароль
├─→ Быстрый и надёжный

Микросервис #2: ЛЕНТА
├─→ Отвечает только за то, какие посты показывать
├─→ Может быть медленный, но это не влияет на остальное

Микросервис #3: ЛАЙКИ
├─→ Отвечает только за учёт лайков
├─→ Очень быстрый, потому что только одна работа

Микросервис #4: ПОИСК
├─→ Отвечает только за поиск постов

Микросервис #5: РЕКОМЕНДАЦИИ (AI)
├─→ Отвечает только за рекомендованные посты
├─→ Может быть медленный, но это фоновая работа

Микросервис #6: УВЕДОМЛЕНИЯ
├─→ Отправляет push уведомления

Микросервис #7: ПЛАТЕЖИ (если есть подписка)
├─→ Обработка платежей, очень защищённо
```

### Как микросервисы общаются между собой (на примере лайка)

```
Ты нажимаешь "Лайк" в Instagram

Шаг 1: Клиент отправляет запрос на микросервис ЛАЙКИ
├─→ "Кто ты? (проверяет авторизацию)"

Шаг 2: Микросервис ЛАЙКИ связывается с микросервисом АВТОРИЗАЦИЯ
├─→ "Эта девушка правда зарегистрирована?"

Шаг 3: Микросервис АВТОРИЗАЦИЯ отвечает
├─→ "Да, это Маша, я её знаю"

Шаг 4: Микросервис ЛАЙКИ сохраняет в БД
├─→ "Маша лайкнула пост #12345"

Шаг 5: Микросервис ЛАЙКИ уведомляет микросервис УВЕДОМЛЕНИЯ
├─→ "Маша лайкнула пост автора Алисы"

Шаг 6: Микросервис УВЕДОМЛЕНИЯ отправляет Алисе push
├─→ "Маша лайкнула твой пост!"

Шаг 7: Клиент видит на экране
├─→ "101 лайк" вместо "100 лайков"
```

### Преимущество микросервисов

```
❌ Монолит (один большой сервер):
├─→ Если обновляем авторизацию → перезагружаем весь сервер
├─→ Без грамотного деплоя все пользователи видят даунтайм
│   (современные монолиты деплоятся через rolling/blue-green — без даунтайма)
├─→ Сложно масштабировать (если лайков много → нужно менять весь сервер)
├─→ Если один баг в рекомендациях → может упасть весь сервер

✅ Микросервисы:
├─→ Если обновляем авторизацию → перезагружаем только этот микросервис
├─→ Лайки работают, ленты работают, уведомления работают!
├─→ Легко масштабировать (если лайков много → добавляем ещё копию микросервиса ЛАЙКИ)
├─→ Если баг в рекомендациях → лайки всё равно работают
```

---

## Блок 8: Когда нужна сложная архитектура?

| Фаза | Архитектура | Примеры | Почему |
|------|-----------|---------|--------|
| **Разработка** | Один сервер на localhost | Пишешь и тестируешь на своём компьютере — никто в интернете не видит | Быстро пробовать, не нужна надёжность |
| **MVP (до 1000 юзеров)** | Один сервер на облаке + одна БД | Vercel, Railway, Render — простой deploy, реальные люди используют продукт | Просто делать, хватает для первых пользователей |
| **Рост (1K-100K юзеров)** | Один сервер на облаке + одна БД | Приложение в интернете, но обычно одного сервера хватает | Нужна надёжность |
| **Масштабирование (100K-1M юзеров)** | Несколько серверов, БД с replicas (копиями) | Instagram, Twitter переходили к этому | Нагрузка большая, нужна балансировка |
| **Enterprise (1M+ юзеров)** | Микросервисы, несколько БД, кэш, CDN | Netflix, Spotify, Uber, Amazon | Огромная сложность для надёжности и скорости |

---

## Блок 9: Типичные заблуждения

### Заблуждение 1: "Если я запустил localhost на своём компьютере, мой сервис уже в интернете"
**Правда:** localhost = только твой компьютер. В интернете его никто не видит. Нужен deploy на облако (Railway, Render, AWS), чтобы люди видели твой сервис.

### Заблуждение 2: "База данных — это как Excel таблица"
**Правда:** БД — это специализированное хранилище, оптимизированное для быстрого поиска миллионов записей. Excel не справится с 1 млрд строк.

### Заблуждение 3: "Сервер — это один компьютер"
**Правда:** Production сервер обычно много компьютеров (серверов), работающих вместе и распределяющих нагрузку.

### Заблуждение 4: "Микросервисы — это всегда хорошо"
**Правда:** Микросервисы добавляют сложность. Для стартапа с 10K юзеров это overkill. Начни с монолита (один сервер).

### Заблуждение 5: "Deploy — это нажать кнопку 'опубликовать'"
**Правда:** Deploy может быть просто (нажать кнопку в Heroku) или сложным (настраивать Docker, Kubernetes). Зависит от того, что используешь.

### Заблуждение 6: "Моему продукту нужна сложная архитектура с микросервисами"
**Правда:** Начни с простого. Большинство успешных стартапов начинали с одного сервера. Масштабируй, когда появится необходимость.

---

> 📝 **Практическое задание** выполни его в следующем уроке по пройденному материалу.

[Все уроки](https://learnvibecoding.ru/publiclessons.md) · HTML: https://learnvibecoding.ru/publiclessons