Що таке 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.

Типові помилки та хибні уявлення

• «Виглядає готовим, значить, готово». Тестові дані і кнопка, що здається робочою, — не те саме, що збережені дані. Оновіть сторінку, відкрийте її в приватному вікні і перевірте, що дані лишилися.
• Правила у фронтенді. Приховати кнопку — це не безпека. Якщо бекенд не перевіряє, будь-хто, знаючи запит, може його відправити.
• Секретні ключі у фронтенді. Ключ платіжного або AI-провайдера в браузерному коді читається кожним відвідувачем. Ключі мають жити на бекенді, у змінних середовища — див. змінні середовища та секрети.
• Думка, що full-stack означає складно. Невеликий full-stack застосунок може складатися з кількох екранів, кількох маршрутів бекенду і трьох таблиць бази даних. Це опис шарів, а не розміру.
• Думка, що треба самому вибрати всі технології. Для першої версії підійде будь-який розумний, широко вживаний стек. Важливіше чіткий опис даних і правил.

Що попросити у вашого конструктора на основі ШІ

Опишіть застосунок через три шари, навіть якщо не називаєте їх:

• Дані: «Зберігай заняття (назва, час, місткість) і бронювання (заняття, людина, час бронювання) в базі даних».
• Правила: «Не можна забронювати заняття понад місткість. Людина може забронювати заняття лише раз. Лише адміністратори бачать, хто бронював».
• Екрани: «Тижневий розклад, підтвердження бронювання, адмін-сторінка зі списком бронювань по заняттях».
• Перевірки: «Застосовуй ці правила на сервері, а не лише на сторінці. Тримай будь-які API-ключі на сервері».

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

Full-stack застосунки в Mythex

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

Запитання