Отличие от монолитной архитектуры

Отличие от монолитной архитектуры

Введение

Прежде чем стала популярной клиент-серверная модель, приложения строились иначе. Чтобы понять, почему клиент-серверный подход победил, нужно познакомиться с тем, от чего отказались — монолитной архитектурой.

Что такое монолит

Монолитное приложение — это когда весь код живёт в одном большом проекте:

• Интерфейс (UI)
• Бизнес-логика
• Работа с базой данных

Всё это собирается в один исполняемый файл и разворачивается как единое целое.

Пример: Старый банковский сайт, где страницы генерировались прямо на сервере и отправлялись браузеру целиком в виде готового HTML. Никакого разделения — один сервер делал всё.

Клиент-серверная архитектура: разделение ответственности

В клиент-серверной модели каждый компонент живёт отдельно:

Клиент (Frontend)          Сервер (Backend)          База данных
[ React-приложение ]  ←→  [ Node.js / Python ]  ←→  [ PostgreSQL ]

• Frontend — отдельное приложение в браузере
• Backend — отдельный сервис, принимает API-запросы
• База данных — отдельный сервер хранения данных

Преимущества клиент-серверной модели

Недостатки: что усложняется

• Зависимость от сети: если сеть упала — приложение не работает
• Задержки (latency): каждый запрос занимает время на передачу по сети
• Более сложное тестирование: нужно тестировать и UI, и API, и их интеграцию
• Сложная отладка: ошибка могла произойти на клиенте, на сервере или в сети

Что изменилось для тестировщика

Именно разделение на слои — главная новость для тебя как тестировщика:

В монолите ты тестировал только UI: нажал кнопку → увидел результат.

В клиент-серверной модели у тебя появляются новые возможности:

• Протестировать API напрямую, минуя UI
• Найти баги, которые воспроизводятся только через API, но скрыты в UI
• Изолировать: "это баг фронтенда или бэкенда?"
• Создавать тестовые данные через API быстрее, чем через интерфейс

Пример: Форма регистрации на UI не даёт отправить email без @. Но если отправить запрос напрямую к API — возможно, бэкенд такого ограничения не имеет. Это критический баг безопасности, который виден только при API-тестировании.

Типичные ошибки в понимании

• "Монолит — это плохо" — нет, для небольших проектов монолит проще и надёжнее
• "Если тест UI прошёл, значит API тоже работает" — неверно, UI может скрывать проблемы API
• "Разделение всегда помогает" — нет, оно добавляет сложность интеграции

Что мы запомним

• Монолит = всё в одном: UI + логика + БД собраны вместе
• Клиент-сервер = компоненты разделены и общаются через сеть
• Разделение даёт масштабируемость и независимость, но усложняет тестирование
• Тестировщик теперь может тестировать API отдельно от UI — это мощный инструмент
• Знание архитектуры помогает изолировать дефекты по слоям