Стоп. Железо ни при чём. Речь про слои логики — кто рисует кнопку, кто проверяет права, кто хранит заказ.
Я сам когда-то на собесе нёс эту дичь про серверную стойку. Мидл ставил галочку "не догоняет архитектуру". Стыдно. Поэтому разложу так, чтобы кивали, а не вздыхали.
Раньше слоёв было два, теперь почти всегда три.
Раньше — двухслойка
Клиент и БД. Между ними ничего.
Клиент тут "толстый" — полноценное приложение на компе со всей логикой внутри. Например Delphi-десктоп в банке году в 2003-м. Знает строку подключения к Oracle, сам пишет SQL, лезет в базу. Часть правил — в коде клиента, часть — в хранимках (код, лежащий внутри БД и исполняемый ею самой).
Так жили 1С, банковские АРМы (Автоматизированные Рабочие Места), заводские учётки.
Бтв двухслойка не умерла. SQL Management Studio, DBeaver, Power BI, Excel с прямым коннектом — всё это она.
Откуда у трёхслойки растут ноги
Двухслойка треснула, как только из локалки полезли в большой интернет.
1. Интернет. Публиковать Oracle наружу — самоубийство. Любой школьник перебирает пароли по протоколу БД.
2. Масштаб. Сто клиентов — сто коннектов. Сто тысяч — БД упирается в
max_connections, жрёт память и задыхается до запросов.3. Обновления. Поменяли формулу скидки — а в полях 5000 АРМов. Половина обновится через месяц, половина никогда. База в один день считает разное. БУХГАЛТЕРИЯ В УЖАСЕ.
4. Безопасность. В коде клиента — пароль от БД. Декомпилировал .exe — забрал всё. Поменять больно: перевыпускай ПО для всех.
5. Платформы. К нулевым стало ясно: одного клиента мало. Веб, мобилка, десктоп. Копировать логику на три стека — путь в ад.
Так и появился бэкенд — отдельный слой логики посередине.
А сейчас — трёхслойка
1. Клиент — рисует интерфейс, держит UI-состояние. Бизнес-правил тут больше нет.
2. Бэкенд (API) — вся логика, валидации, права. Stateless: ничего про тебя не помнит, поэтому любая из ста копий за балансировщиком обслужит. Запросы по контракту (REST/gRPC/GraphQL), кто ты — по токену (JWT либо session id из Redis).
3. БД — в закрытой сети, доступ только из бэкенда. Бэк держит пул соединений (часто через PgBouncer) и переиспользует на тысячи клиентов.
Клиент стал ТУПОВАТЫМ. Хотя SPA на React "тонким" не назовёшь: роутинг, кэш, оптимистичные апдейты (UI обновляется до ответа сервера). Но суть та же: клиент рисует, бэк думает.
В проде слоёв обычно больше: CDN, API gateway, кэш, очереди, аналитика сбоку. Плюс идемпотентность, BFF, контракт-фёрст — это всё отдельные темы. Но снизу всё равно та же трёхслойка.
Браузер vs нативка
Браузерные — HTML/JS, ничего не ставить, обновления мгновенные. Минус: без интернета по умолчанию мёртвые (PWA умеют офлайн, но это отдельная работа), к железу доступ ограничен.
Нативные — iOS, Android, десктоп. Офлайн, камера, GPS, пуши, биометрия. Релиз через сторы, пользователь обновляется когда захочет (а захочет он никогда). Бэк тащит совместимость со старыми API годами.
Гибриды (Electron, React Native, Flutter) — браузер или JS-движок в обёртке. Куда их относить — вечный спор.
У нормального продукта пачка клиентов: веб, iOS, Android, десктоп. Все в один API 🫡
Видишь в требованиях "клиент" — сразу спрашивай: браузерный или нативный. От этого пляшет всё: оффлайн, пуши, релизы, версионирование API. Не уточнишь — будет жопа в спринте.
—————————————————————
И на десерт. Бизнес-логика в хранимках — это fat database. Антипаттерн или норма?
Защитники: "БД быстрее работает с данными, зачем гонять туда-сюда".
Противники: "не тестируется, не версионируется в git, рефакторинг — боль".
Если бы я сегодня собирал новый сервис — никаких хранимок с бизнес-логикой. Точка. Хранимки только под утилитарное (агрегации, миграции). Но половина читающих захочет меня переубедить — давайте.
Зову тех, у кого половина системы в PL/SQL: как живёте? Джунам — спросить команду "у нас бизнес-логика где живёт?". Ответ расскажет про возраст системы.
@analyst_exe