Нужен ли вашему приложению, созданному ИИ, настоящий бэкенд? Как понять это до того, как вы его добавите

Момент, когда вы начинаете сомневаться

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

Ваше приложение работает. Пользователи регистрируются. Функции выходят одна за другой. А потом появляется это ползучее ощущение: разве не должен быть «настоящий бэкенд»? Все говорят про бэкенды. У серьёзных приложений есть бэкенды. А ваш билдер выдал вам что-то на TypeScript внутри React, и вы начинаете подозревать, что это как-то… недостаточно профессионально.

Вот вам правда: это ощущение обычно ошибочно. В том, что делает бэкенд, нет никакой магии, и ваше приложение, созданное ИИ, вполне может уже это делать. А если нет — добавление бэкенда не решит настоящую проблему, какой бы она ни была на самом деле.

Этот текст — о том, как отличить одно от другого.

Для чего на самом деле нужен бэкенд?

Бэкенд существует ровно по трём причинам: чтобы работать с деньгами, чтобы хранить секреты в безопасности и чтобы быть единственным источником правды, когда данные редактирует больше одного человека.

Работа с деньгами. Если ваше приложение принимает платежи или списывает деньги с пользователей, платёжный процессор требует бэкенд. Браузер не может напрямую обращаться к Stripe с вашим секретным API-ключом (иначе вы бы разместили ключ в клиентском коде, доступном кому угодно). Поэтому нужен сервер, который хранит ключ в безопасности, принимает запросы от браузера и общается со Stripe от имени пользователя. Это и есть бэкенд. Он не обязан быть навороченным — для большинства приложений хватит одной Node-функции, — но он должен существовать.

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

Единственный источник правды для данных. Если два пользователя одновременно работают в вашем приложении и оба пытаются изменить одни и те же данные, вам нужен центральный арбитр, который решит, чьё изменение победит. Браузер не может быть судьёй — два браузера друг друга не видят. Поэтому нужен сервер, который скажет: «Изменение имени принимаем от Алисы, а правка Боба пришла на 30 миллисекунд позже, поэтому не применяется». Этот сервер и есть бэкенд. Именно поэтому важен раздел про базы данных — вам нужно одно место, где реально хранятся все данные.

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

Как понять, что бэкенд вам действительно нужен?

Есть три сигнала, что бэкенд вам действительно нужен: приложение тормозит по причине, которую браузер сам исправить не может, вам нужно, чтобы код выполнялся там, где пользователь не может его увидеть или прервать, или два пользователя перезаписывают данные друг друга. Разберём, какой из них — если вообще какой-то — относится к вашему случаю.

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

История про настоящие тормоза: приложение для списков дел подтормаживало при загрузке. Разработчик подумал: «мне нужен настоящий бэкенд». Реальная проблема оказалась в том, что приложение каждый раз загружало все 5000 задач вместо того, чтобы загружать первые 50 с кнопкой «загрузить ещё». Починили за полдня, не трогая бэкенд. Проблема была не в нём.

«Хочу выполнять код, который пользователь не должен видеть». Это единственная причина, которая действительно имеет смысл, и встречается она реже, чем кажется. Примеры: отправка письма после регистрации пользователя (вы хотите, чтобы этот код выполнился, даже если пользователь закроет вкладку), фоновая задача, обрабатывающая файлы ночью, обращение к внешнему API по расписанию. Это всё веские причины. Вам действительно нужно что-то, работающее на сервере. Но это не обязательно должен быть полноценный бэкенд с аутентификацией, маршрутизацией и базами данных. Может хватить одной «облачной функции», которая запускается по расписанию или вызывается вебхуком. Гораздо проще целого бэкенда.

«Несколько пользователей одновременно меняют одни и те же данные, и часть изменений теряется». Вот это по-настоящему серьёзно. Если вы видите «правки Алисы куда-то пропали» или «два человека редактировали одну форму, и изменения второго затёрли первого», у вас проблема конкурентного доступа. Одни базы данных справляются с этим лучше других, а некоторые ИИ-билдеры по умолчанию выбирают базы, которые справляются плохо. Но решение не всегда — целый бэкенд; иногда достаточно сменить базу данных, добавить блокировки или ввести оптимистичную конкурентность (заумный термин для «храним старый номер версии и сверяем его перед тем, как разрешить обновление»). Спросите у своего билдера, может ли он сменить базу данных или добавить отслеживание версий. Возможно, вам нужен не бэкенд, а более умная настройка базы данных.

Что выглядит как проблема бэкенда, но им не является?

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

«Код на JavaScript, и весь он в одном месте». Множество успешных приложений — это JavaScript в браузере, общающийся с настоящей базой данных (Firebase, Supabase, MongoDB Atlas — что бы ни настроил ваш билдер). Отдельного сервера «настоящего бэкенда» нет. Всё работает. То, что код на одном языке и в одном месте, не значит, что он «ненастоящий». JavaScript работает.

«Нет отдельного слоя API». Ваш браузер общается напрямую с базой данных. У многих первая реакция: «так неправильно, посередине должен быть API». Но если этот API буквально делает «выбрать из таблицы и вернуть» или «вставить в таблицу», промежуточный слой ничего не добавляет. Это просто лишние накладные расходы. Ваша база данных уже и есть API. Обращайтесь к ней напрямую, если можете.

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

Честное дерево решений

Вот как разобраться в этом, не гадая:

Может ли ваше приложение делать то, что делает сейчас, без бэкенда? Если да — переходите к пункту 2. Если нет — у вас уже есть бэкенд (или он вам нужен). Идём дальше. (Возможно, у вашего ИИ-приложения он уже есть.)
То, что вы хотите добавить, — это то, чего браузер принципиально не может сделать? Списать деньги? Точно да. Отправить письмо? Тоже да. Обратиться к внешнему API с секретным ключом? Да. Что-то ещё? Скорее всего, нет. Если это то, что браузер мог бы сделать, но медленно, — переходите к пункту 3. Если это то, чего браузер не может сделать в принципе, — вам нужен бэкенд.
Пропадут ли тормоза, если исправить настоящую проблему? Загружать меньше данных? Умнее кэшировать? Группировать запросы? Использовать базу данных получше? Хитрость в том, чтобы сначала понять, что именно тормозит. Добавляйте бэкенд только после того, как исчерпали очевидные исправления. Потому что добавление бэкенда не исправляет медленный алгоритм — оно просто переносит его на другую машину.
Если вы добавите бэкенд, решит ли это проблему на самом деле? Вот в чём ловушка. Вы добавляете бэкенд, чтобы «улучшить производительность», а задержки только растут, потому что теперь вы делаете сетевые запросы к своему бэкенду, который делает сетевые запросы к базе данных, — а могли бы сделать это из браузера за один шаг. Сначала измеряйте. Потом добавляйте.

Вам нужен полноценный бэкенд или просто облачная функция?

Если то, что вы хотите, умещается в одну функцию, которая работает пару секунд и завершается, вам нужна облачная функция, а не полноценный бэкенд. Вот простой тест на нюх.

Подумайте, что именно вы хотите поручить бэкенду. Теперь представьте, что вы пишете это как одну JavaScript-функцию (строк на 100), которая запускается по вызову, работает несколько секунд и останавливается. Уместится ли задача в эту коробку?

Обработать вебхук платежа? Да.
Отправить приветственное письмо? Да.
Провалидировать файл перед загрузкой? Да.
Формировать ночной отчёт? Да (в общем-то — просто вызывать по расписанию).

Если ответ «да» — вам не нужен «настоящий бэкенд». Вам нужна облачная функция. Vercel, AWS Lambda, Google Cloud Functions — что угодно. Это дешевле, проще, и не нужно нянчиться с сервером.

Если ответ «нет» — если вам нужно, чтобы что-то работало постоянно, обрабатывало тысячи запросов, с сложной бизнес-логикой, — тогда вы действительно думаете о настоящем бэкенде, и этот разговор важнее. Но, честно говоря, для приложений, которые люди создают с помощью ИИ, такое встречается редко. Большая часть того, что выглядит как «работа бэкенда», — это просто «вызвать этот API» или «сохранить эти данные», а это ваш билдер, скорее всего, уже умеет.

Главный вопрос, который стоит задать своему билдеру

Прежде чем что-либо добавлять, задайте своему билдеру один вопрос: что именно сейчас сломано и что бэкенд реально исправит?

Если у него есть конкретный ответ — «нам нужно списывать деньги», «нам нужно обращаться к API с секретным ключом», «у нас конфликты при одновременном доступе к данным» — отлично. Вы знаете, к чему двигаться.

Если ответ звучит как «ну, у настоящих приложений есть бэкенды» — это не причина, а ощущение. То же самое ощущение заставляет вас добавлять учётные записи пользователей в приложение, которым никто ни с кем не делится, или схему базы данных из пятнадцати таблиц, когда у вас реально есть три сущности. Это запах разрастания объёма работ, только в маскировке под бэкенд.

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

Ваше приложение, скорее всего, и так в порядке. А ощущение, что это не так, обычно — голос амбиций, а не правды. Добавляйте бэкенд, когда он решает реальную проблему, а не потому что вам кажется, что так «положено».

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