Что такое фронтенд и бэкенд и зачем приложению база данных

Фронтенд — это часть приложения, которую видит и трогает пользователь: экраны, кнопки, формы. Бэкенд — часть на сервере, которая решает, что можно делать, и выполняет это. База данных — место, где всё хранится, пока приложение не смотрит.

Слова «фронтенд и бэкенд» звучат в любом разговоре с разработчиками, и без понимания этой границы трудно разобраться, почему у тебя что-то утекло, тормозит или ломается. Проще всего объяснить на одном запросе, который проходит через все три части.

Фронтенд и бэкенд на примере: запись на занятие

Допустим, у тебя приложение студии йоги. Человек открывает расписание, выбирает занятие в четверг и жмёт «Записаться». Вот что происходит дальше.

1. Фронтенд. Код в браузере (обычно React или что-то похожее) рисует кнопку и ловит нажатие. Он собирает, что нужно отправить: какое занятие выбрано. И отправляет запрос на сервер вместе с отметкой о том, кто вошёл в систему, — токеном сессии.

POST /api/bookings
Authorization: Bearer <токен сессии>
{ "classId": 42 }

2. Бэкенд. Сервер получает запрос и начинает задавать вопросы. Кто это? Токен настоящий и не истёк? Существует ли занятие 42? Есть ли на нём свободные места? Не записан ли человек уже? Не превышен ли лимит записей у его абонемента?

3. База данных. Чтобы ответить, бэкенд читает из базы занятие, число записей и абонемент. Если всё в порядке, он добавляет строку в таблицу записей: такой-то человек, такое-то занятие, такое-то время.

4. Обратно. Бэкенд отвечает фронтенду: «записан» или «мест нет». Фронтенд показывает зелёную галочку или сообщение об ошибке. Весь путь занимает доли секунды.

Почему правила живут на бэкенде

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

Если проверка «есть ли места» сделана только во фронтенде, человек с консолью браузера запишется на занятие, где мест нет. Если цена абонемента приходит из браузера, он заплатит столько, сколько напишет сам. Общее правило: всё, что касается денег, прав и чужих данных, проверяется на сервере.

А если бэкенда нет?

Многие инструменты для вайбкодинга — Lovable, Bolt, v0 — собирают приложение, где фронтенд обращается к базе почти напрямую, например через Supabase или Firebase. Кажется, что бэкенда нет вовсе.

На самом деле он есть, просто в другой форме: правила доступа в самой базе (в Supabase это Row Level Security) и серверные функции для того, что нельзя доверить браузеру. Если правил нет, база отвечает на любой запрос любого человека — ровно то, что произошло бы с сервером, который ничего не проверяет. Пока приложение маленькое, такая схема удобна. Когда появляются платежи, сложные проверки или внешние API с секретными ключами, отдельный бэкенд почти всегда становится нужен.

Где обычно ломается

• Логика только во фронтенде. Проверки, лимиты и цены живут в браузере, а сервер просто сохраняет всё, что пришло.
• Секреты во фронтенде. Ключ платного API вшит в код, который скачивает каждый посетитель.
• Слишком много запросов. Фронтенд загружает список занятий, а потом для каждого отдельно запрашивает число записей. На десяти занятиях незаметно, на тысяче — страница грузится минуту.
• База без структуры. Всё лежит в одной таблице с полем «данные» в виде текста, и любой отчёт превращается в археологию.

Понимание этих трёх слоёв помогает задавать правильные вопросы: «эта проверка на сервере или в браузере?», «откуда фронтенд берёт эту цену?», «кто может прочитать эту таблицу?».

Коротко

• Фронтенд — то, что видит пользователь; бэкенд — сервер, который проверяет и выполняет; база данных — где всё хранится.
• Любое действие — это запрос от фронтенда к бэкенду, который читает и пишет в базу и возвращает ответ.
• Фронтенд принадлежит пользователю, поэтому проверки прав, лимитов и цен живут на бэкенде.
• Если фронтенд ходит в базу напрямую, роль бэкенда выполняют правила доступа в базе — и без них данные открыты.

SUBXCAT помогает разобраться, где в твоём приложении проходит эта граница, и перенести на сервер то, что не должно жить в браузере.