Что на самом деле внутри приложения на ИИ: экскурсия для не-разработчиков

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

Вы набрали описание, нажали «поехали», и двадцать минут спустя у вас было рабочее приложение. Отлично. Но вот вы кликнули «посмотреть файлы» и теперь смотрите на дерево папок, которое будто написано на другом языке. Что такое package.json? Почему в node_modules сорок штук всего? Что значит «схема» и почему она у вас есть?

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

Я буду использовать три сквозных примера на протяжении всего текста, чтобы у абстрактных частей было что-то конкретное, к чему привязаться:

  • Майя, руководитель по маркетингу, которая построила реферальную таблицу лидеров для своей команды.
  • Джордан, преподаватель йоги, который построил сайт записи на занятия.
  • Сэм, у которого пекарня, построивший страницу «предзаказать завтрашние круассаны».

Все трое использовали ИИ-конструктор приложений. Все три приложения выглядят для клиента совершенно по-разному. Под капотом же они устроены на удивление похоже.

Фронтенд: то, что ваш клиент на самом деле видит

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

У Майи фронтенд — это таблица лидеров с рангом, именем и числом рефералов. У Джордана — это календарь занятий с кнопкой «записаться». У Сэма — это список выпечки с маленькими кнопками плюс и минус рядом с каждой.

Внутри проекта фронтенд обычно живёт в папке с названием вроде app/, pages/ или src/. Вы увидите файлы, заканчивающиеся на .tsx или .jsx. Каждый из них — это примерно «один экран» или «один кусок экрана». Строка таблицы лидеров — это один файл. Шапка — другой файл. Страница, которая всё это связывает воедино, — третий.

Когда вы просите ИИ-конструктор «сделать кнопки более округлыми» или «сдвинуть таблицу лидеров вправо», меняется именно эта часть.

Бэкенд: часть, которая думает

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

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

Бэкенд обычно живёт в папке с названием api/, server/ или app/api/. Файлы там обычно короткие. Каждый обрабатывает конкретный запрос: «создать запись», «вывести сегодняшние круассаны», «добавить реферала».

Когда что-то в вашем приложении работает, но результат не закрепляется — вы нажимаете «отправить», видите подтверждение, а назавтра данные пропали, — баг почти всегда в бэкенде.

База данных: память вашего приложения

Представьте память вашего приложения как ряд картотечных шкафов. У каждого шкафа спереди наклейка. На одном написано «пользователи». На другом — «записи». На третьем — «заказы_круассанов». Внутри каждого шкафа каждый ящик — это одна строка. У каждого ящика один и тот же набор ячеек: имя, email, дата создания, статус.

Эта структура — «какие шкафы существуют, какие ячейки есть у каждой строки» — называется схемой. Это самый важный файл в проекте, хотя он же, вероятно, и самый скучный на вид. Найдите файл с названием schema.ts, schema.prisma или что-то внутри папки с именем db/ или migrations/. Откройте его. Вы увидите список, который отражает то, что ваше приложение действительно помнит о мире.

У схемы Джордана есть таблица classes, таблица bookings и таблица users. У Сэма — products, orders и order_items. У Майи — members и referrals. Форма схемы — это форма продукта, и поэтому менять её потом труднее, чем менять то, как выглядят кнопки.

Полезный приём: если вы можете описать, что ваше приложение помнит, простыми словами, вы обычно можете описать и схему. «Я помню имя и email каждого клиента. Для каждого клиента я помню заказы, которые он сделал. Для каждого заказа я помню, какая выпечка и сколько каждой». Это предложение — почти слово в слово — и есть схема.

Авторизация: вышибала у двери

«Авторизация» (auth) — это два слова, слепленные вместе: аутентификация (кто ты?) и авторизация (что тебе разрешено делать?). Оба обычно обрабатываются небольшим набором файлов в папке auth/ или сервисом, имя которого вы, возможно, узнаете: Clerk, Auth0, Supabase Auth, NextAuth.

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

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

Интеграции: то, что вы не строили, но всё равно используете

Вот где большинство не-разработчиков недооценивают то, что на самом деле происходит. То, что отправляет письмо Сэма «ваши круассаны готовы», — это не код, это аккаунт в SendGrid или Resend. То, что обрабатывает оплату занятия Джордана, — это не код, это Stripe. То, что хостит фотографии на таблице лидеров Майи, — это не код, это сервис хранения вроде S3 или Cloudinary.

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

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

Деплой: как оно попадает в интернет

Последняя часть — это то, что превращает папку на вашем диске в нечто, что ваш клиент может посетить по URL. Обычно это значит, что три небольшие вещи работают вместе:

  • Хост: сервис вроде Vercel, Netlify, Fly или Render, который запускает ваш бэкенд и отдаёт ваш фронтенд.
  • Домен: имя вроде mayas-leaderboard.com, которое указывает на ваш хост.
  • Сборка: рецепт, который берёт ваши беспорядочные исходные файлы и превращает их в более компактную, более быструю версию, которая реально работает.

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

Пятиминутная привычка, которая окупает себя

Вам не нужно читать каждый файл в вашем проекте. Вам не нужно знать, что делает большинство из них. Но раз в неделю вам стоит делать пятиминутный обход, открывая каждую из папок выше и спрашивая ИИ-конструктор простыми словами, что изменилось.

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

В этом и весь смысл понимания частей. Не чтобы стать разработчиком. Просто чтобы быть способным задавать вопросы получше.

Куда двигаться дальше

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