Чи потрібен вашому AI-додатку справжній бекенд? Як зрозуміти це перш ніж його додавати

Момент, коли з’являються сумніви

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

Ваш додаток працює. Користувачі реєструються. Функції виходять одна за одною. І раптом з’являється те саме повзуче відчуття: а хіба не має бути “справжнього бекенду”? Усі говорять про бекенди. У серйозних додатків є бекенди. А ваш білдер видав вам щось на TypeScript усередині React, і ви починаєте думати, що це якось… непрофесійно.

Ось правда: це відчуття зазвичай оманливе. У тому, що робить бекенд, немає нічого магічного, і ваш AI-створений додаток, можливо, уже це робить. А якщо ні — додавання бекенду не вирішить справжню проблему, хоч би що насправді було зламано.

Цей пост про те, як відрізнити одне від іншого.

Для чого насправді потрібен бекенд?

Бекенд існує рівно з трьох причин: обробка грошей, збереження секретів у безпеці та роль єдиного джерела правди, коли дані редагує більш ніж одна людина.

Обробка грошей. Якщо ваш додаток приймає платежі або знімає гроші з користувачів, платіжний процесор вимагає наявності бекенду. Браузер не може напряму звертатися до Stripe із вашим секретним API-ключем (адже тоді ключ опинився б у клієнтському коді, видимому будь-кому). Тому вам потрібен сервер, який зберігає ключ у безпеці, приймає запити від браузера і спілкується зі Stripe від імені користувача. Це і є бекенд. Він не мусить бути складним — для більшості додатків досить однієї Node-функції — але він має існувати.

Збереження секретів у безпеці. API-ключі, паролі бази даних, токени авторизації — усе це не може жити в браузері, бо будь-хто, хто користується вашим додатком, зможе це прочитати. Якщо вашому AI-створеному додатку потрібно звернутися до зовнішнього сервісу, який вимагає авторизації, браузер сам із цим не впорається. Додаток звертається до вашого бекенду, у якого є ключ, а той уже звертається до зовнішнього сервісу. Ваші секрети залишаються секретами.

Єдине джерело правди для даних. Якщо два користувачі одночасно користуються вашим додатком і обидва намагаються змінити ті самі дані, вам потрібен центральний арбітр, який вирішить, чия зміна переможе. Браузер не може бути суддею — два браузери не бачать один одного. Тому потрібен сервер, який скаже: “Аліса отримує зміну імені, версія Боба прийшла на 30 мілісекунд пізніше, тож вона не застосовується”. Цей сервер і є бекенд. Саме тому розділ про базу даних має значення — вам потрібне одне місце, де насправді живуть усі дані.

Зверніть увагу, чого немає в цьому списку: продуктивність, професійність, масштабованість, “бо у всіх так є”. Це саме ті відчуття, які підштовхують вас додавати складність, яка вам не потрібна.

Як зрозуміти, що бекенд вам справді потрібен?

Про справжню потребу в бекенді свідчать три сигнали: додаток повільний з причини, яку браузер сам не може виправити, вам потрібен код, що виконується там, де користувач його не бачить і не може перервати, або два користувачі перезаписують дані одне одного. Ось як зрозуміти, що з цього — якщо взагалі щось — стосується саме вас.

“Це повільно.” Якщо користувачі скаржаться на повільність, проблема зазвичай одна з трьох: браузер виконує забагато роботи (навантаження на CPU, поганий алгоритм, надмірний рендеринг DOM), повільна мережа (сумно, але факт), або повільна база даних (забагато запитів, неправильні індекси — ваш AI-створений додаток уже спілкується з базою даних, зазвичай непоганою). Справжній бекенд не виправить навантаження на CPU у браузері. Справжній бекенд не виправить затримки мережі (з фізикою сперечатися важко). Бекенд може допомогти із запитами до бази даних завдяки кешуванню чи розумнішим патернам запитів, але ваш білдер, найімовірніше, уже про це подбав.

Реальна історія про повільність: список справ у todo-додатку завантажувався повільно. Розробник подумав: “Мені потрібен справжній бекенд”. Справжня проблема виявилась іншою: додаток щоразу завантажував усі 5000 завдань замість того, щоб завантажувати перші 50 із кнопкою “завантажити ще”. Виправили за один вечір, навіть не торкаючись бекенду. Бекенд не був проблемою.

“Я хочу виконувати код, якого користувач не має бачити.” Це єдина причина, яка справді має сенс, і трапляється вона рідше, ніж здається. Приклади: надіслати лист після реєстрації користувача (ви хочете, щоб цей код виконався, навіть якщо він закриє вкладку), фонове завдання, що обробляє файли вночі, звернення до зовнішнього API за розкладом. Це все обґрунтовані причини. Вам справді потрібно, щоб щось виконувалося на якомусь сервері. Але це не мусить бути повноцінний бекенд із авторизацією, маршрутизацією та базами даних. Це може бути одна-єдина “хмарна функція”, що запускається за розкладом або викликається вебхуком. Значно простіше, ніж цілий бекенд.

“Кілька користувачів одночасно змінюють ті самі дані, і оновлення губляться.” Ось це вже справжня проблема. Якщо ви бачите, що “правки Аліси зникли” або “двоє людей редагували ту саму форму, і зміни другого перекрили перші”, у вас проблема конкурентного доступу. Одні бази даних справляються з цим краще за інші, і деякі AI-білдери за замовчуванням обирають ті, що гірше. Але вирішенням не завжди є повноцінний бекенд — можливо, вам потрібно змінити базу даних, додати блокування або оптимістичну конкурентність (модний термін для “зберігати номер старої версії й порівнювати перед тим, як дозволити оновлення”). Запитайте свого білдера, чи можна змінити базу даних або додати відстеження версій. Можливо, вам потрібен не бекенд, а розумніше налаштування бази даних.

Що виглядає як проблема бекенду, але нею не є?

Три речі часто плутають із проблемами бекенду, хоча ними вони не є: JavaScript, зібраний в одному місці, відсутність окремого шару API та загальна тривога щодо безпеки без конкретної проблеми.

“Код на JavaScript і весь в одному місці.” Багато успішних додатків — це JavaScript у браузері, який спілкується зі справжньою базою даних (Firebase, Supabase, MongoDB Atlas — що там налаштував ваш білдер). Ніякого “справжнього бекенду”-сервера немає. І все працює. Те, що код написаний однією мовою в одному місці, не означає, що він несправжній. JavaScript працює.

“Немає окремого шару API.” Ваш браузер спілкується безпосередньо з базою даних. У багатьох перше відчуття — “це неправильно, тут має бути API-прошарок”. Але якщо цей API — буквально “вибрати з таблиці й повернути” або “додати в таблицю”, проміжний шар нічого не додає. Це просто зайві витрати. Ваша база даних уже є API. Звертайтеся до неї напряму, якщо можете.

“Я переживаю за безпеку.” Більшість AI-створених додатків мають розумні налаштування за замовчуванням: паролі хешуються, SQL-ін’єкції неможливі (бібліотека бази даних це запобігає), секрети не потрапляють на клієнт. Якщо ви справді переживаєте, правильна дія — запитати білдера, чи робить він усе це, а не рефлекторно додавати бекенд. Погано зроблений бекенд вразливіший, ніж добре зроблений фронтенд.

Чесне дерево рішень

Ось як розібратися з цим, не вгадуючи:

Чи може ваш додаток робити те, що робить зараз, без бекенду? Якщо так — переходьте до пункту 2. Якщо ні — у вас уже є бекенд (або він вам потрібен). Продовжуйте. (Можливо, ваш AI-створений додаток уже його має.)
Чи те, що ви хочете додати, — це щось, чого браузер принципово не може зробити? Знімати гроші? Однозначно. Надсилати лист? Так. Звертатися до зовнішнього API із секретним ключем? Так. Щось інше? Ймовірно, ні. Якщо це щось, що браузер міг би зробити, але робить повільно, — переходьте до пункту 3. Якщо це щось, чого браузер не може зробити, — вам потрібен бекенд.
Чи зникає повільність, якщо виправити справжню проблему? Завантажувати менше даних? Розумніше кешувати? Групувати запити? Використати кращу базу даних? Фокус у тому, щоб спершу з’ясувати, що саме повільне. Додавайте бекенд лише після того, як вичерпаєте очевидні виправлення. Бо додавання бекенду не виправляє повільний алгоритм — воно просто переносить його на іншу машину.
Якщо ви додасте бекенд, чи справді він вирішить проблему? Ось у чому пастка. Ви додаєте бекенд, щоб “покращити продуктивність”, а затримка стає гіршою, бо тепер ви робите мережеві виклики до свого бекенду, який робить мережеві виклики до бази даних, — тоді як могли б зробити це з браузера за один крок. Спершу виміряйте. Потім додавайте.

Вам потрібен повноцінний бекенд чи просто хмарна функція?

Якщо те, що вам потрібно, вміщається в одну функцію, яка виконується кілька секунд і зупиняється, вам потрібна хмарна функція, а не повноцінний бекенд. Ось простий тест “на нюх”.

Подумайте, що саме ви хочете, щоб робив бекенд. А тепер уявіть, що пишете це як одну JavaScript-функцію (десь на 100 рядків), яка виконується кілька секунд при виклику, а потім зупиняється. Чи вміститься це в таку коробку?

Обробляти вебхуки платежів? Так.
Надіслати вітальний лист? Так.
Перевірити файл перед завантаженням? Так.
Запускати нічний звіт? Так (майже — довелося б викликати його за розкладом).

Якщо відповідь “так” — вам не потрібен “справжній бекенд”. Вам потрібна хмарна функція. Vercel, AWS Lambda, Google Cloud Functions — байдуже яка. Це дешевше, простіше, і вам не доведеться няньчити сервер.

Якщо відповідь “ні” — якщо вам потрібне щось, що працює постійно, обробляє тисячі запитів і містить складну бізнес-логіку, — тоді мова вже про справжній бекенд, і ця розмова важливіша. Але, чесно кажучи, для додатків, які люди створюють з допомогою AI, це рідкість. Здебільшого те, що виглядає як “робота бекенду”, — це просто “викликати цей API” або “зберегти ці дані”, і ваш білдер, найімовірніше, уже це вміє.

Головне запитання до вашого білдера

Перш ніж щось додавати, поставте своєму білдеру одне запитання: що саме зараз зламано, і що з цього справді виправить бекенд?

Якщо у нього є конкретна відповідь — “нам потрібно знімати гроші”, “нам потрібно звертатися до API із секретним ключем”, “у нас конфлікти при одночасному редагуванні даних” — чудово. Ви знаєте, до чого прямуєте.

Якщо відповідь — “ну, у серйозних додатків є бекенди”, це відчуття, а не причина. Те саме відчуття змушує вас додавати облікові записи користувачів у додаток, яким ніхто ні з ким не ділиться, або схему бази даних із п’ятнадцятьма таблицями, коли насправді у вас лише три сутності. Це запах повзучого розширення обсягу, замаскований під бекенд.

У більшості успішних додатків, зроблених однією людиною, немає “справжнього бекенду” в тому сенсі, який ви собі уявляєте. У них є база даних (ваш білдер, ймовірно, її вже налаштував). Можливо, є одна-дві функції, що запускаються за розкладом. Але саме код у браузері виконує роботу, спілкується з базою даних напряму й випускає нові функції без проміжного шару.

Ваш додаток, найімовірніше, і так у порядку. Відчуття, що це не так, зазвичай — це голос амбіцій, а не правди. Додавайте бекенд, коли він вирішує реальну проблему, а не тому, що вам здається, що так треба.

Наступного разу, коли обмірковуватимете нову функцію, запитайте себе: чи це те, чого браузер принципово не може зробити? Чи це те, що я думаю, ніби потребує бекенду, бо просто чув це слово надто часто? Відповіді на ці два запитання різні, і лише одна з них — справді ваша справа.