Глава 11. Хостинг, базы данных и публикация

Работающая локальная страница решает только часть задачи. Для опубликованного сайта нужно определить, где выполняется код, куда сохраняются данные, кто имеет к ним доступ и как восстановить последнюю рабочую версию.

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

Где разместить сайт

Сценарий	Что требуется	Кандидат для проверки
Статические страницы	Раздача файлов, HTTPS, домен	Vercel или Cloudflare Pages
Сайт, где часть кода выполняется на сервере	Поддержка нужного языка и программ, настройки и лимиты	Vercel; подходящий вариант Cloudflare Workers
Личный кабинет с данными	Авторизация, база, права, серверные операции	Приложение плюс Supabase
Бот, который должен постоянно работать	Постоянно работающая программа, перезапуск после сбоя, запись ошибок	Сервер, который ещё нужно выбрать и проверить

Это варианты для сравнения. Перед выбором попросите Codex определить, какие программы нужны сайту и может ли выбранный хостинг их запускать.

Vercel Hobby разрешён для личного некоммерческого использования. Для сайта бизнеса нельзя автоматически выбирать его как бесплатный тариф для рабочего сайта. Условия оплаты, превышения лимита и возможные расходы проверяйте отдельно. Vercel Hobby.

Для Next.js Cloudflare различает статический экспорт в Pages и полноценное приложение на Workers. Текущая страница рекомендует vinext для серверного сценария. Прежде чем переносить существующий проект, проверьте совместимость конкретных функций и актуального адаптера. Cloudflare: Next.js.

Промпт: Выбрать хостинг по требованиям

Сначала опубликовать тестовую версию

На Vercel используются три названия. Local означает работу на вашем компьютере. Preview означает тестовую публикацию по отдельной ссылке. Production означает рабочий сайт для посетителей.

Публикация, или deployment, создаёт адрес выбранной версии сайта. Откройте именно её и проверьте основные действия. Если подключён Git, отправка кода может автоматически обновить сайт. Заранее выясните, из какой ветки выходит рабочая версия. Ветка хранит отдельную линию изменений проекта. Vercel: deployments.

Перед запуском запишите команду подготовки сайта к публикации, папку приложения и названия настроек. Эти настройки часто называются переменными окружения. Значения секретов в план не записывайте. Тестовая версия должна использовать учебные данные и предназначенные для них доступы. Человек, открывший preview, не должен случайно отправлять настоящий заказ.

У рабочего сайта могут быть другие настройки, чем у тестовой версии: там могут отличаться данные, адреса возврата после входа, домен и переменные. Для выпуска подготовьте отдельный проход основного пользовательского пути.

Промпт: Подготовить проверяемый preview

Промпт готовит план публикации. Сам выпуск выполните отдельным действием в выбранном учебном аккаунте, затем проверьте полученный адрес.

Supabase: вход и право на запись

Пользователь вошёл в аккаунт, но это ещё не определяет доступ к каждой записи. Опишите модель: что видит посетитель без входа, что видит владелец, что доступно сотруднику. Например, Анна должна видеть свои заявки, а Борис свои.

Для этого нужны два уровня правил. Первый разрешает само действие, например чтение таблицы. В документации это grants. Второй определяет, какие именно записи видит пользователь. Это RLS. Проверьте оба уровня. Supabase RLS.

Для кода, который работает в браузере посетителя, предусмотрен publishable key, публичный ключ подключения. Он допустим только вместе с правильно настроенными правами доступа. Secret key и старый service_role дают расширенный доступ и обходят RLS. Такие ключи должны храниться на сервере, где отдельно проверяется право пользователя на действие. Если ключ находится в коде страницы, посетитель может его увидеть. Supabase: API keys.

Перед настройкой попросите Codex проверить журнал обновлений Supabase. На 8 октября в нём описаны личные токены с ограниченными правами. Они нужны для управления сервисом и не заменяют ключ доступа к данным сайта. Старые подключения некоторых фреймворков через @supabase/server уже помечены как устаревшие. Не копируйте настройку из старой статьи без проверки. Supabase changelog.

Промпт: Спроектировать и проверить права данных

Сначала задайте модель данных. Универсальный SQL-блок для всех приложений может случайно открыть больше, чем требуется, поэтому в книге сначала фиксируется модель, затем пишется миграция и запускаются проверки.

Домен без потери почты

Добавьте домен в настройки выбранного проекта и используйте записи, которые покажет его панель. Для Vercel документация различает основной домен и поддомен; конкретные значения не нужно переносить из чужого скриншота.

DNS связывает название сайта с адресом сервера. Если меняете сервис, который хранит эти записи (nameservers), заранее перенесите все существующие записи. В том числе MX для почты и TXT для подтверждений и настроек. Иначе вместе с сайтом может перестать работать почта.

Если меняете только адрес сайта в нынешнем DNS-сервисе, переносить остальные записи не нужно. После изменения откройте сайт с www и без него, проверьте правильный адрес и защищённое соединение HTTPS. Vercel: настройка домена.

Покупка домена, продление, DNS и сертификат являются разными этапами. Стоимость продления проверяйте отдельно от стартовой скидки.

Копия данных и проверка восстановления

Supabase прямо указывает: резервная копия базы сохраняет сведения о файлах в Storage, облачном хранилище. Сами файлы в такую копию не входят. После восстановления базы удалённый файл сам не появится. Планируйте отдельное сохранение файлов и проверьте их восстановление вместе с записями. Ежедневные копии и восстановление на выбранный момент времени (PITR) доступны в зависимости от тарифа. Supabase: backups.

Для выпуска сохраните версию кода, схему и состояние данных, нужные настройки и ссылки на внешние ресурсы. Сведения о секретах храните отдельно. Локальный опыт в главе 13 покажет разницу между восстановлением кода и данных; он не заменяет испытание восстановления облачной базы.

Приём оплаты на своём сайте

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

В ЮKassa ключ повторяемой операции называется Idempotence-Key. Он помогает отличить повтор запроса от нового платежа; условия и срок действия описаны в API. После неопределённой ошибки сначала выясните состояние операции. ЮKassa: формат запросов.

Уведомление сервиса может прийти повторно. Проверяйте подлинность и текущее состояние, затем обновляйте заказ без второй выдачи доступа. ЮKassa: уведомления.

Промпт: Подготовить тестовый платёжный путь