Статичний сайт, frontend і backend

Два сайти на екрані. Перший - сторінка з грою: поле, рахунок, кнопка "заново". Другий - сторінка майстерні з формою "залишити замовлення". Обидва відкриваються в браузері, обидва зібрані з HTML, CSS і JavaScript, обидва виглядають готовими. Перший викладається за хвилину: тека на хостинг, посилання готове. На другому агент, найпевніше, зупиниться і запитає, де буде сервер і куди зберігати замовлення.

Різниця не в складності і не в красі. Вона в тому, кому треба щось робити, коли відвідувач натискає кнопку, і де мають лежати дані після цього. Розберемо три слова - статичний сайт, frontend і backend, - подивимося, де живуть дані і чому від цього залежить спосіб публікації. Наприкінці розберемо, що агент запитає сам до того, як ви попросите "виклади", а що варто запитати в нього.

1. Статичний сайт

Статичний сайт - це сайт із готових файлів: index.html, style.css, скрипти, зображення, шрифти. Сервер зберігає їх і віддає кожному відвідувачу одні й ті самі, нічого не обчислюючи і нічого не запам'ятовуючи про відвідувачів. Усю роботу - показати, порахувати, зреагувати на клік - робить браузер відвідувача на його комп'ютері.

Візьмемо односторінкове портфоліо. У теці лежать index.html з розповіддю про себе і списком робіт, style.css, десяток зображень і невеликий скрипт. Відвідувач відкриває посилання, браузер завантажує файли і збирає з них сторінку. Клік на роботу відкриває зображення збільшеним, перемикач темної теми змінює кольори: це робить скрипт у браузері. Сервер після того, як віддав файли, ні в чому більше не бере участі: йому все одно, хто прийшов і що натиснув. З'явилася нова робота - ви правите index.html, кладете поруч зображення і викладаєте теку заново; іншого способу щось змінити тут немає, і змінюєте сайт ви, а не відвідувач.

За тією ж схемою влаштовані:

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

Де статика закінчується, видно, якщо поділити роботу сайту на дві половини: ту, що робить браузер, і ту, що робить сервер. Ці половини мають назви.

2. Frontend працює в браузері

Frontend - усе, що виконується на комп'ютері відвідувача: розмітка, стилі та скрипти, які браузер отримав і запустив у себе. "Передня частина", та, яку видно. (Її часто називають "просто версткою", а це вся частина сайту, з якою людина має справу, у статичного сайту - взагалі весь сайт.)

Уміє frontend багато: показати сторінку, порахувати ходи у грі, перевірити перед надсиланням, що поле форми не порожнє, запам'ятати щось до наступного візиту - для цього браузер має власне сховище, агент назве його localStorage. Чого він не вміє - поділитися. Сховище живе в цьому браузері на цьому пристрої, і більше ніде. Де ця межа заважає, а де ні, видно на двох прикладах.

Найкращий рахунок у грі. Партія закінчилася, скрипт порівняв результат із минулим рекордом і записав новий у сховище браузера. Завтра гравець відкриє сторінку в тому ж браузері на тому ж ноутбуці - рекорд на місці. Відкриє на телефоні - там порожньо, телефон має своє сховище. Ви, автор гри, цей рекорд не побачите ніколи. І нічого страшного: він потрібен тільки самому гравцеві, і сайт залишається статичним.

Замовлення майстерні. Клієнт описав, що треба зробити, залишив телефон, натиснув "надіслати". Скрипт може перевірити, що поля заповнені, а далі йому нікуди: запише замовлення у сховище браузера - замовлення залишиться в телефоні клієнта, і майстер про нього не дізнається. Замовлення має прочитати інша людина на іншому пристрої, отже, дані мають поїхати з комп'ютера клієнта, а на іншому кінці їх має хтось прийняти і зберегти. Сайт із самих лише файлів такого "когось" не має.

Усе, що стосується одного відвідувача на одному пристрої, frontend робить сам. Решта - робота другої половини.

3. Backend працює на сервері

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

На схемі два шляхи однієї форми: клік, робота, результат. Відрізняються вони середньою плашкою - хто робить роботу і що саме. Угорі після ходу у грі JavaScript у браузері обчислює рахунок, зберігає рекорд і перемальовує поле, і все це на комп'ютері відвідувача. Унизу клік на "надіслати" перетворюється на запит, запит іде на сервер, програма приймає його, зберігає замовлення в себе на сервері і відповідає браузеру, і вже її відповідь потрапляє на екран. Де саме на сервері лежить замовлення - наступний розділ. Питання "хто робить роботу" і є межею між двома типами сайтів.

Три впізнавані ознаки, що без backend не обійтися:

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

Мова у backend будь-яка: JavaScript (тоді це Node.js), Python, Java, десяток інших. Для цієї статті важливо не це, а те, що програма має десь працювати постійно, і це "десь" - не браузер. Адреса сайту веде до місця на сервері, як і у статики, тільки на цьому місці тепер не файл, а програма, яка збирає відповідь на льоту.

4. Де живуть дані

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

У файлах проєкту. Текст сторінки, зображення, правила гри. Однакові для всіх відвідувачів і змінюються тільки новим деплоєм: поправили файл, виклали знову.

У браузері відвідувача. Налаштування, найкращий рахунок, чернетка форми, яку не хочеться втратити під час перезавантаження. Бачить тільки цей відвідувач на цьому пристрої. Зникають після очищення даних сайту, у приватному вікні їх немає, в іншому браузері й на іншому пристрої теж, і вам про них нічого не відомо.

У базі на сервері. Замовлення, коментарі, акаунти. Бачать усі, кому треба, і ви теж. Живуть незалежно від того, чи відкрита в когось вкладка. Щоб туди щось потрапило, потрібна програма на сервері, яка прийме дані і запише.

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

Замість теорії поставте собі одне запитання: чи має інша людина побачити те, що ввела ця? "Запам'ятати найкращий рахунок" - ні, отже, сховище браузера, і сайт залишається статичним. "Зберегти замовлення" - так, отже, база і програма, яка в неї пише. Запитання має один виняток, і даних він не стосується: ключ до чужого сервісу. Якщо ключ є, відповідь "ні" не рятує: у файлах йому лежати не можна, отже, потрібна програма на сервері, яка ходить у чужий сервіс від вашого імені, або чужий сервіс-посередник, який зробить це за вас.

Буває середина. Форму замовлення може приймати за вас чужий сервіс: відвідувач тисне "надіслати", дані йдуть не на ваш сервер, а до них, і звідти приходять вам листом. Це все одно backend, тільки не ваш. Агент назве такий, якщо запитати; зараз важливо розуміти, що форма без чиєїсь програми на сервері не працює.

5. Чому способи деплою різні

Статику публікують копіюванням: тека їде на хостинг (чужий сервер, який віддає ваші файли всім охочим), посилання готове, оновити - скопіювати знову. Усе.

З backend інакше. На сервері має стояти середовище для мови програми - сам Python або Node.js, без яких код нічим запустити. Програма має бути запущена і перезапускатися, якщо впала. Поруч має працювати база даних. Ключі до бази і до чужих сервісів мають лежати так, щоб програма їх читала, а відвідувачі ні. Кожна з цих частин оновлюється окремо і ламається по-своєму.

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

Одне уточнення до рядка про секрети. Ключ до хостингу, якщо ви завели його заради постійного посилання, статичний сайт має, але живе він окремо від теки сайту і в неї не кладеться.

"Підняти сервер" у відповіді агента звучить буденно, як "створити файл". За цією фразою стоїть увесь правий стовпець таблиці, і майже кожен рядок потім доведеться підтримувати.

6. Куди викласти статичний сайт

Оскільки статику публікують копіюванням, хостингів для неї багато, і більшість безкоштовні для невеликої сторінки. Ось п'ять, які трапляються найчастіше. У таблиці буде слово "репозиторій": поки досить розуміти його як теку проєкту під контролем версій, докладніше не зараз.

Як обирати. Показати і обговорити - той, де посилання з'являється без реєстрації. Залишити надовго - будь-який, де ви завели акаунт. Проєкт лежить у репозиторії - той, що підключається до репозиторію і оновлюється сам після кожної зміни. На те, який вигляд має опублікована сторінка, вибір не впливає: файли ті самі.

Якщо сайт має backend

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

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

Умови і ліміти в усіх сервісах змінюються, а продукти перейменовують і об'єднують: Cloudflare, наприклад, вже пропонує починати нові проєкти не в Pages, а у Workers, де статичні файли викладаються так само. Числа в обидві таблиці навмисно не потрапили: перед вибором загляньте на сторінку тарифів.

7. Що запитати в агента перед публікацією

Агент дивиться на теку і зазвичай сам називає тип проєкту. Файли без програми - запропонує хостинг для статики, навіть якщо серед файлів є форма, якій нікуди надсилати: таке він помічає не завжди. Є server.js або app.py - скаже, що потрібен сервер, і запитає, де він буде. Якщо не назвав або назвав надто швидко, запитайте самі:

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

Відповідь залежить від проєкту, тому тут її немає. Зате є кілька речей, на які варто дивитися в будь-якій відповіді.

• На "потрібен сервер" не погоджуйтеся, не глянувши. Запитайте, що саме його вимагає і чи можна це зробити в браузері або відкласти - наприклад, випустити першу версію без форми. Агент охоче будує backend там, де вистачило б сховища браузера.
• І навпаки: якщо дані мають бути спільними, агент, найпевніше, скаже, що статикою не обійтися. Це не ускладнення, а називання речей своїми іменами. сперечатися тут нема з чим.
• Про ключ до чужого сервісу агент запитає, куди його покласти. Відповідь "у файл сайту" неправильна, і добрий агент сам це скаже. Для таких ключів є місце поза файлами сайту, і агент має назвати його сам, а не пропонувати вписати ключ у сторінку.
• Перед деплоєм статики агенту потрібна тека. Перед деплоєм backend - ще й відповіді про базу, середовище і секрети. Якщо запитань не було, а сервер "піднявся", подивіться, що саме він зробив і де.

Слова "статика" і "backend" описують не складність, а місце: де відбувається робота і де живуть дані. Коли це місце відоме, спосіб публікації обирається сам.

Умови хостингів з часом змінюються, перевіряйте на сторінках тарифів.