Что такое full-stack приложение? Простое объяснение

Full-stack приложение — это приложение, которое включает все слои, нужные для работы: фронтенд, который видят и на который нажимают люди, бэкенд, который работает на сервере и применяет правила, и базу данных, которая помнит всё. Список дел, который сохраняет ваши задачи, позволяет войти с любого устройства и не показывает ваш список никому другому, — это full-stack. Одна страница, которая только показывает часы работы, — нет.

«Stack» — это просто слои технологий, уложенные друг на друга. «Full» означает, что все они на месте.

Почему это важно при создании с ИИ

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

Знание разницы помогает в трёх случаях:

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

Бытовая аналогия: ресторан

Представьте ресторан.

• Зал — это фронтенд. Меню, столики и блокнот официанта. Это то, что видят гости, и оно должно быть приятным и удобным.
• Кухня — это бэкенд. Гости туда не заходят. Там принимают заказы, проверяют, есть ли блюдо, готовят и отказывают в странных просьбах. Правила живут здесь.
• Кладовая и книга заказов — это база данных. В них хранится то, что есть, и то, что заказано, поэтому ничего не забывается при смене смены.

Ресторан, в котором есть только зал, может показать красивое меню, но вас не накормят. Это приложение только с фронтендом, которое притворяется full-stack.

Три слоя подробнее

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

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

Практический пример: приложение для записи на занятия

Представьте, что вы ведёте студию йоги и хотите, чтобы люди записывались на занятия онлайн.

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

Что происходит внутри:

1. Фронтенд показывает расписание. Чтобы его заполнить, он спрашивает бэкенд: «Какие занятия на этой неделе и сколько мест осталось?»
2. Бэкенд запрашивает у базы данных занятия и считает записи на каждое, затем отвечает.
3. Посетитель нажимает «Записаться». Фронтенд отправляет: «запиши вошедшего человека на занятие 42».
4. Бэкенд проверяет: действительно ли этот человек вошёл в систему? Не заполнено ли занятие? Не записан ли он уже? Только если всё в порядке, он записывает новую строку-бронирование в базу.
5. Бэкенд отвечает «записано», и фронтенд показывает подтверждение.
6. Позже владелица студии входит в систему и видит список занятий. Бэкенд проверяет, что она администратор, прежде чем показать имена всех записавшихся.

Теперь представьте, что это сделано только на фронтенде. Расписание могло бы отображаться, а кнопка «Записаться» показала бы красивую галочку, но запись исчезла бы при обновлении страницы, счётчик «свободных мест» был бы неверным для всех остальных, и владелица никогда бы её не увидела. Шаг 4 — проверки — полностью отсутствовал бы. Вот и вся практическая разница.

Ключевые термины

• Фронтенд (клиентская часть): часть, которая работает в браузере.
• Бэкенд (серверная часть): часть, которая работает на сервере. Также называется сервером API.
• База данных: место, где данные хранятся упорядоченно. См. что такое база данных.
• API: список запросов, которые бэкенд принимает от фронтенда или других программ.
• Аутентификация: проверка того, кто перед вами (вход). Авторизация: проверка того, что этому человеку можно делать.
• Развёртывание (deployment): размещение всех слоёв на серверах, чтобы ими могла пользоваться публика.
• Монолит против сервисов: одна программа, которая делает всё, против нескольких небольших (например, сайт и отдельный API). Оба варианта — full-stack.

Частые ошибки и заблуждения

• «Выглядит готовым — значит, готово». Примерные данные и работающая на вид кнопка — это не то же самое, что сохранённые данные. Обновите страницу, откройте её в приватном окне и проверьте, что данные на месте.
• Правила во фронтенде. Скрытая кнопка — не безопасность. Если бэкенд ничего не проверяет, любой, кто знает запрос, может его отправить.
• Секретные ключи во фронтенде. Ключ платёжного или ИИ-провайдера в коде браузера доступен каждому посетителю. Ключи должны жить на бэкенде, в переменных окружения, см. переменные окружения и секреты.
• Мысль, что full-stack значит сложный. Небольшое full-stack приложение может состоять из нескольких экранов, нескольких маршрутов бэкенда и трёх таблиц базы. Это описание слоёв, а не размер.
• Мысль, что нужно самому выбрать каждую технологию. Для первой версии подойдёт любой разумный и широко используемый стек. Важнее ясное описание данных и правил.

Что попросить у конструктора на основе ИИ

Описывайте приложение в терминах трёх слоёв, даже если не называете их:

• Данные: «Сохрани занятия (название, время, вместимость) и записи (занятие, человек, время записи) в базе данных.»
• Правила: «Нельзя записаться на занятие сверх вместимости. Один человек может записаться на занятие только один раз. Только администраторы видят, кто записан.»
• Экраны: «Недельное расписание, подтверждение записи, страница администратора со списком записей по занятиям.»
• Проверки: «Применяй эти правила на сервере, а не только на странице. Храни все ключи API на сервере.»

Затем тестируйте скептически: обновите страницу, войдите под двумя разными людьми, попробуйте увидеть данные, которые вам видеть нельзя. Руководство по созданию приложения с ИИ проходит весь этот цикл от начала до конца.

Full-stack приложения в Mythex

Mythex создаёт full-stack веб-приложения по описанию в чате. По умолчанию новое приложение получает фронтенд на React и TypeScript; когда приложению нужно сохранять данные, Mythex добавляет в проект выделенную базу Postgres, а вы можете попросить отдельный сервер API (например, на Python, Node, C# или Java) рядом с сайтом. Всё работает вместе в живом предпросмотре и публикуется по публичному адресу. Страница документации о многосервисных приложениях показывает, как сайт и API вместе просматриваются и публикуются, а на странице конструктора full-stack приложений есть стартовые точки.

Вопросы