Фронтенд і бекенд: у чому різниця?
Фронтенд — це частина застосунку, що працює в браузері користувача: сторінки, кнопки, форми й анімації, які він бачить і на які натискає. Бекенд — це частина, що працює на сервері, якого користувач ніколи не бачить: він зберігає й отримує дані, застосовує бізнес-правила, перевіряє, хто що може робити, і взаємодіє з іншими сервісами, наприклад з оплатами та електронною поштою. Ці дві частини спілкуються через API, і разом із базою даних вони утворюють «full-stack» застосунок.
Чому це важливо, коли ви створюєте з ШІ
Коли ви описуєте застосунок ШІ-конструктору, ви описуєте обидві частини одразу, навіть якщо не помічаєте цього. «Клієнти можуть забронювати місце» означає форму бронювання (фронтенд), правила про те, які місця вільні (бекенд), і сховище, де зберігаються бронювання (база даних).
Розуміння цього поділу допомагає на практиці в трьох випадках:
- Безпека. Усе, що є у фронтенді, може побачити й змінити користувач. Правила та секрети мають жити в бекенді.
- Налагодження. «Кнопка не реагує» і «кнопка реагує, але нічого не зберігається» вказують на різні частини системи. Якщо ви скажете, що саме бачите, ШІ швидше знайде причину.
- Хостинг і вартість. Фронтенд-сайт дешевий і простий у розміщенні. Бекенд має де працювати, і це впливає на те, скільки ви платите і як застосунок поводиться в простої.
Повсякденна аналогія
Уявіть ресторан.
Фронтенд — це зал: меню, столики, інтер'єр, офіціант, який приймає замовлення. Він створений для гостей, і вони бачать та торкаються всього цього.
Бекенд — це кухня й офіс: кухарі, склад, каса, правила менеджера щодо знижок. Гості туди не заходять і не повинні мати такої можливості.
API — це передача між ними: стійка, куди подаються замовлення і звідки виходять страви, у погодженому форматі. База даних — це склад і книга замовлень.
Гість може переписати свою замовлену картку (фронтенд під його контролем), але кухня все одно вирішує, що приготувати і скільки це коштує. Тому важливі перевірки мають бути в бекенді.
Що робить кожна частина
| Фронтенд | Бекенд | |
|---|---|---|
| Де працює | На пристрої користувача, у браузері | На сервері, яким керуєте ви (або ваш хостинг) |
| Основне завдання | Показувати, збирати введені дані, реагувати на кліки | Зберігати дані, застосовувати правила, керувати доступом, викликати інші сервіси |
| Чи можуть користувачі бачити і змінювати код? | Так — його завантажують у браузер | Ні |
| Чи може зберігати секретні ключі API? | Ні | Так, у змінних середовища |
| Поширені технології | HTML, CSS, JavaScript/TypeScript, React, Vue, Svelte, Tailwind | Node.js, Python (FastAPI, Django), C#, Java, Go, Ruby |
| Що зазвичай ламається | Верстка з'їжджає на телефоні, кнопка нічого не робить, сторінка повільна | Дані не зберігаються, показуються неправильні дані, помилки, діри в безпеці |
Деякі фреймворки стирають цю межу. Наприклад, Next.js дозволяє мати в одному проєкті і код для браузера, і код для сервера. Ідея та сама: завжди питання в тому, де виконується ця частина?
Практичний приклад: бронювання заняття
Ось що відбувається, коли хтось бронює заняття йогою, крок за кроком.
| Крок | Де | Що відбувається |
|---|---|---|
| 1 | Фронтенд | Сторінка розкладу завантажується і запитує в бекенду заняття на цей тиждень. |
| 2 | Бекенд | Зчитує заняття та бронювання з бази даних, рахує вільні місця і повертає список у форматі JSON. |
| 3 | Фронтенд | Показує кожне заняття з часом, викладачем і кількістю вільних місць. |
| 4 | Фронтенд | Користувач обирає заняття і вводить ім'я та email. Форма перевіряє, що email виглядає коректно (це для зручності, а не гарантія). |
| 5 | Фронтенд → Бекенд | Надсилає запит POST /api/bookings через API. |
| 6 | Бекенд | Повторно перевіряє дані, з'ясовує, чи заняття не заповнене, зберігає бронювання і, використовуючи секретний ключ, просить сервіс електронної пошти надіслати підтвердження. |
| 7 | Бекенд → Фронтенд | Повертає «заброньовано» або «вибачте, місць немає». |
| 8 | Фронтенд | Показує екран підтвердження. |
Зверніть увагу на кроки 4 і 6: дані перевіряються двічі. Перевірка у фронтенді дає миттєвий відгук; а справжню роль відіграє перевірка в бекенді, бо наполегливий користувач може обійти фронтенд повністю.
Поширені терміни
| Термін | Значення |
|---|---|
| Клієнт / сервер | Клієнт — браузер (або застосунок), що надсилає запити; сервер на них відповідає. |
| UI | Інтерфейс користувача — екрани й елементи керування. |
| API | Погоджений спосіб, яким фронтенд запитує в бекенду дані або дії. |
| Endpoint | Одна конкретна адреса в API, наприклад /api/bookings. |
| Full stack | Фронтенд, бекенд і база даних разом. Див. що таке full-stack застосунок. |
| Статичний сайт | Фронтенд без власного бекенду; однакові файли для всіх. |
| SPA | Односторінковий застосунок: фронтенд оновлює сторінку в браузері замість завантаження нових. |
| Рендеринг на сервері (SSR) | Сервер формує HTML сторінки перед відправкою, що може пришвидшити завантаження і допомогти SEO. |
| Змінні середовища | Налаштування та секрети, які бекенд отримує під час роботи і які зберігаються поза кодом. |
Чи потрібен вашому застосунку бекенд?
| Якщо ваш застосунок… | Чи потрібен бекенд? |
|---|---|
| Показує інформацію, однакову для всіх | Ні |
| Має контактну форму, яка лише надсилає вам email | Зазвичай невеликий, або сервіс форм |
| Зберігає дані, які бачитимуть інші люди | Так |
| Має входи в акаунт і приватні дані | Так |
| Приймає оплати | Так — принаймні для створення платежів і прийому вебхуків оплати |
| Використовує платний ШІ або інший API з секретним ключем | Так, щоб ключ не потрапив у браузер |
Поширені помилки й хибні уявлення
- Зберігати секретні ключі у фронтенді. Їх побачить кожен, хто відкриє інструменти розробника в браузері. Це найпоширеніша серйозна помилка в застосунках, створених з ШІ.
- Застосовувати правила лише у фронтенді. Приховати кнопку «видалити» для не-адміністраторів — це не захист; бекенд має відхиляти такий запит.
- Вважати, що бекенд — це «просто база даних». База зберігає дані. Бекенд вирішує, хто може їх читати й змінювати і як.
- Думати, що JavaScript означає фронтенд. JavaScript і TypeScript працюють і на серверах, через Node.js.
- Шукати проблему не там. Якщо сторінка виглядає правильно, а дані неправильні, проблема зазвичай у бекенді чи базі, а не в дизайні.
- Надмірне ускладнення. Портфоліо не потребує власного бекенду. Він додає вартості та рухомих частин.
Про що просити ваш ШІ-конструктор
- «Які частини цього застосунку працюють у браузері, а які на сервері?»
- «Перенеси всі ключі API в бекенд і читай їх зі змінних середовища.»
- «Перевіряй кожну форму і на сервері, і в браузері.»
- «Зроби так, щоб на бекенді видаляти бронювання могли лише адміністратори.»
- «Сторінка виглядає добре, але дані не зберігаються. Перевір логи бекенду для цього запиту.»
- «Це простий маркетинговий сайт; залишай лише фронтенд, якщо бекенд не потрібен.»
Фронтенд і бекенд у Mythex
Новий проєкт у Mythex починається з фронтенду на Vite, React, TypeScript і Tailwind. Агент додає бекенд, коли застосунок його потребує, або ви можете попросити окремий API на Node, Python (FastAPI), C# чи Java, що працює поруч із фронтендом у тому самому проєкті. У попередньому перегляді можна перемикатися між сайтом і API-сервером, а публікація розгортає обидві частини, з базою даних і сховищем файлів за потреби. У документації описано застосунки з кількох сервісів, у гайді про веб-хостинг — де працює кожна частина після запуску, а шаблони застосунків — швидкий спосіб побачити приклади full-stack.
Запитання
У чому різниця між фронтендом і бекендом?
Фронтенд — це частина застосунку, яка працює в браузері користувача: сторінки, кнопки й форми, які він бачить. Бекенд працює на сервері, якого користувач не бачить; він зберігає дані, застосовує бізнес-правила, перевіряє дозволи і взаємодіє з іншими сервісами.
Чи потрібен бекенд кожному застосунку?
Ні. Маркетинговому сайту, портфоліо чи простій лендинг-сторінці може вистачити лише фронтенду. Щойно застосунку потрібно зберігати спільні дані, входити в акаунти, приймати оплати або використовувати секретні ключі API, йому потрібен якийсь бекенд.
HTML — це фронтенд чи бекенд?
HTML, CSS і JavaScript, що виконуються в браузері, — це фронтенд. JavaScript також може працювати на сервері через Node.js, і тоді це бекенд-код. Вирішує не мова, а те, де виконується код.
Що означає full stack?
Full stack означає охоплення і фронтенду, і бекенду (а зазвичай і бази даних). Full-stack застосунок має всі три частини, а full-stack розробник працює з кожною з них.