коротко

Почти любая система, с которой вы работаете, устроена по модели клиент-сервер: клиент (браузер, мобильное приложение, десктоп-программа) показывает интерфейс и отправляет запросы, сервер хранит данные и считает логику, отвечает по сети. Клиенты бывают «тонкие» (вся логика на сервере) и «толстые» (часть логики на устройстве). Браузер — это клиент, который умеет скачивать и рисовать веб-страницы и слать HTTP-запросы. Разбираться в этом надо, иначе требования к «приложению» окажутся требованиями непонятно к чему.

Можно семь лет писать требования и ни разу честно не ответить себе на вопрос «а где это вообще выполняется». Я видел ТЗ, где «сделать на странице» означало три разные вещи на трёх платформах — и никто этого не заметил, пока не дошло до разработки. Поэтому короткая база. Не весь интернет — только то, без чего дальше нельзя.

Что такое программа и компьютер (на пальцах)

Компьютер умеет ровно три вещи: хранить данные, выполнять над ними операции и обмениваться ими с другими компьютерами. Программа — это набор инструкций, которые говорят компьютеру, какие операции и в каком порядке делать. Всё, что вы проектируете, в конце сводится к этим трём вещам: где данные лежат, кто их обрабатывает и как они передаются. Это и есть взгляд на софт как на систему — набор связанных частей с границей и целью.

Когда программ и пользователей становится много, держать всё на одном устройстве неудобно. Поэтому работу делят между двумя сторонами — так появляется клиент-сервер.

Клиент и сервер: кто за что отвечает

Сервер — компьютер (обычно в дата-центре), который хранит данные и выполняет бизнес-логику. Он не знает в лицо своих пользователей и просто отвечает на запросы. Клиент — программа на устройстве пользователя, которая показывает интерфейс и отправляет запросы серверу. Между ними — сеть и протокол (чаще всего HTTP).

sequenceDiagram
  participant U as Пользователь
  participant C as Клиент (браузер/приложение)
  participant S as Сервер
  participant DB as База данных
  U->>C: нажал «Купить»
  C->>S: HTTP-запрос: создать заказ
  S->>DB: сохранить заказ
  DB-->>S: ок, id=123
  S-->>C: ответ: заказ создан
  C-->>U: показал «Спасибо за заказ»

Схема выше описывает обычный путь действия. Пользователь нажимает кнопку в клиенте. Клиент отправляет на сервер HTTP-запрос («создай заказ»). Сервер сохраняет заказ в базу данных, получает обратно идентификатор и возвращает клиенту ответ. Клиент рисует пользователю результат. Главное, что отсюда нужно вынести: интерфейс и данные живут в разных местах, и между ними всегда есть запрос по сети, который может быть медленным или упасть.

Какие бывают клиенты

Когда в задаче написано «приложение» — спросите, какой именно клиент имеется в виду. От этого зависит всё: ограничения, способ доставки обновлений, оффлайн-режим.

  • Веб-клиент — работает в браузере, ничего не нужно устанавливать. Обновляется мгновенно (перезагрузил страницу — новая версия).
  • Мобильный клиент — приложение под iOS/Android, ставится из стора. Обновление проходит через ревью стора и доходит не до всех сразу — отсюда требование обратной совместимости.
  • Десктоп-клиент — программа под Windows/macOS/Linux. Ставится локально, имеет доступ к файлам и железу.

Толстый и тонкий клиент

Тонкий клиент почти ничего не считает сам — вся логика на сервере, клиент только показывает (классический сайт). Толстый клиент держит часть логики и данных у себя и может работать оффлайн (мобильное приложение, редактор документов). Чем «толще» клиент, тем больше вопросов синхронизации и обратной совместимости вам как аналитику придётся закрывать.

Что на самом деле делает браузер

Браузер — это тоже клиент, просто универсальный. Он умеет три вещи: сходить по адресу (URL) и скачать страницу, нарисовать её (HTML — структура, CSS — оформление, JavaScript — поведение) и отправлять на серверы запросы по HTTP. Когда «веб-приложение тормозит», причина почти всегда в одном из трёх: медленный ответ сервера, тяжёлая отрисовка или много лишних запросов.

Откуда это взялось

Первый браузер написал Тим Бернерс-Ли в 1990 году (он назывался WorldWideWeb). Массовым веб сделал Mosaic в 1993-м — он первым показывал картинки прямо в тексте. С тех пор браузер из «смотрелки документов» превратился в полноценную платформу для приложений: сегодня в нём работают почты, таблицы, видеозвонки. Поэтому граница между «сайтом» и «приложением» давно стёрлась — и в требованиях это надо проговаривать явно.

Фронтенд и бэкенд

Отсюда же растёт деление разработчиков. Фронтенд — то, что выполняется на стороне клиента: интерфейс, его поведение. Бэкенд — то, что на сервере: бизнес-логика, работа с базой, интеграции. Фулстек — и то, и другое. Когда вы пишете требование, полезно сразу понимать, чья это зона: «валидировать поле» на фронте (быстро, но обходится) — это не то же самое, что валидация на бэке (надёжно, но требует запроса).

Теперь, когда понятно, где что выполняется, можно говорить предметно: что именно мы требуем от системы. С этого начинается разговор про требования.

Частые вопросы

Что такое клиент-серверная архитектура простыми словами?

Это модель, где работа поделена между двумя программами: клиент (на устройстве пользователя) показывает интерфейс и отправляет запросы, а сервер (в дата-центре) хранит данные и выполняет логику, отвечая на эти запросы по сети. Браузер, мобильное приложение и десктоп-программа — всё это клиенты одного сервера.

Чем тонкий клиент отличается от толстого?

Тонкий клиент почти не содержит логики — он только отображает то, что посчитал сервер (обычный сайт). Толстый клиент держит часть логики и данных на устройстве, может работать оффлайн и синхронизироваться позже (мобильные приложения, редакторы). Чем толще клиент, тем больше задач по синхронизации и обратной совместимости.

Зачем аналитику понимать, как работает браузер?

Чтобы корректно писать требования к веб-клиенту: где валидировать данные (на клиенте или сервере), почему страница «тормозит», что обновляется мгновенно, а что нет. Браузер сегодня — полноценная платформа приложений, и граница между «сайтом» и «приложением» в требованиях должна проговариваться явно.