Архитектура веб-приложений
Архитектура веб-приложений
Введение
Прежде чем тестировать веб-приложение, нужно понять, как оно устроено внутри. Зная архитектуру, ты сможешь быстро определить, в каком слое возникла ошибка: в браузере, на сервере или в базе данных. Это экономит время и делает тебя более ценным специалистом.
Основная архитектура веб-приложения
Типичное веб-приложение состоит из нескольких слоёв:
Браузер (клиент)
↓↑ HTTP/HTTPS запросы
Веб-сервер (Nginx, Apache)
↓↑
Сервер приложений (Node.js, Java, Python)
↓↑
База данных (PostgreSQL, MySQL, MongoDB)
Браузер (клиент) — то, что видит пользователь. HTML, CSS, JavaScript выполняются здесь.
Веб-сервер — принимает входящие запросы, отдаёт статические файлы (HTML, CSS, JS, картинки).
Сервер приложений — содержит бизнес-логику: авторизацию, обработку данных, работу с БД.
База данных — хранит данные: пользователей, заказы, товары.
Типы веб-приложений
| Тип | Описание | Пример |
|---|---|---|
| Традиционное (MPA) | Каждый переход — полная перезагрузка страницы | Wordpress-сайты |
| SPA (Single Page App) | JS обновляет страницу динамически без перезагрузки | Gmail, Trello |
| PWA (Progressive Web App) | Работает офлайн, можно установить как приложение | Twitter Lite |
SPA — особый случай для тестировщика: URL может не меняться при переходе между разделами, история браузера может работать иначе, контент загружается асинхронно.
CDN и балансировщик нагрузки
CDN (Content Delivery Network) — сеть серверов по всему миру, которая отдаёт статические файлы (картинки, CSS, JS) с ближайшего к пользователю сервера. Это ускоряет загрузку.
Балансировщик нагрузки (Load Balancer) — распределяет входящий трафик между несколькими серверами приложений. Если один сервер падает, трафик переходит на другой.
Слои кэширования
В веб-приложениях кэш есть на каждом уровне:
| Слой | Где хранится | Что кэшируется |
|---|---|---|
| Браузерный кэш | В браузере пользователя | JS, CSS, картинки |
| CDN кэш | На CDN-серверах | Статические файлы |
| Серверный кэш | В памяти сервера (Redis) | Результаты запросов к БД |
| Кэш БД | В СУБД | Частые SQL-запросы |
Почему архитектура важна для тестировщика
Понимание архитектуры помогает:
- Локализовать баги: ошибка в консоли браузера → проблема на клиенте; 500 ошибка → проблема на сервере; медленный ответ → проблема с БД или сетью
- Формулировать баг-репорты: "сервер вернул 503" гораздо информативнее, чем "сайт не работает"
- Понимать, где воспроизвести: баг только на prod? Возможно, другая конфигурация сервера или разные данные в БД
- Задавать правильные вопросы разработчику: в каком сервисе логика обработки формы?
Частые ошибки понимания
- ❌ "Сервер — это один компьютер" → на самом деле это может быть десятки машин за балансировщиком
- ❌ "Если сайт работает в Chrome, значит всё ок" → браузер — лишь один из слоёв, сервер может отдавать неправильные данные
- ❌ "Кэш — только в браузере" → кэш есть на всех уровнях, это важно при тестировании обновлений
Что мы запомним
- Веб-приложение состоит из 4 слоёв: браузер → веб-сервер → сервер приложений → БД
- MPA перезагружает страницу полностью, SPA обновляет её динамически через JS
- CDN ускоряет загрузку статики, балансировщик распределяет нагрузку
- Кэш есть на каждом уровне — при тестировании учитывай это
- Знание архитектуры помогает быстро локализовать баги и общаться с разработчиками