Статический сайт, 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" описывают не сложность, а место: где происходит работа и где живут данные. Когда это место известно, способ публикации выбирается сам.

Условия хостингов со временем меняются, проверяйте на страницах тарифов.