Собираем стек под проект

Стек — набор технологий, из которых сделан сервис: страницы, язык, API, вход, уведомления, данные и хостинг. Его выбирают по главному действию и пути данных.

Из частей в целое

Вы узнали, как работает сервер, чем статика отличается от динамики, чем PHP отличается от Node.js, как выглядит API, как приходят заявки и как устроен вход. Теперь можно собрать всё в одно решение для вашего проекта. Это и называют выбором стека: набора технологий, из которых сделан сервис. Здесь нет правильного ответа «вообще». Есть ответ, который подходит вашему проекту, и вы умеете его обосновать.

Как рассуждать

Порядок рассуждения важнее конкретных названий, и он всегда один и тот же.

1. Главное действие. Что посетитель должен сделать на сайте: оставить заявку, купить, записаться, прочитать? Всё остальное служит ему. Это то самое действие из вашего брифа.
2. Путь данных. Что происходит после нажатия: куда уходят данные, кто их принимает, кто и как узнаёт о них. У заявки это посетитель, форма, приём, хранение, уведомление и владелец. Каждый шаг пути это блок, которому нужен инструмент.
3. Самое простое подходящее на каждом шаге. Не самое мощное и не самое модное. Если хватает готового файла, не нужна база. Если хватает сервиса форм, не нужно приложение. Если заявку хватает отправить письмом, не нужен личный кабинет.
4. Что будет, когда сломается. Любой блок когда-нибудь откажет, и план на этот случай составляют заранее, пока спокойно.
5. Где лежат данные и кто их видит. Закон здесь не формальность.

Стек по блокам

Страницы. Статика или динамика. Для визитки, лендинга, блога чаще статика: готовые файлы, которые раздаёт nginx или хостинг (вы помните, насколько это быстрее, дешевле и безопаснее). На движке (WordPress, 1С-Битрикс) страницы собираются из базы, и это оправдано, когда контент часто меняют несколько людей, а не программист. Про движки и генераторы сайтов впереди целая часть.

Язык и приложение. Нужно, только если есть динамика: приём заявок, вход, личный кабинет. Вы уже видели, как выбирать: для сайта на движке это PHP, для чата Node.js, Go или Elixir, а в остальных случаях тот язык, на котором легче всего найти людей. Если динамики на сайте одна форма, часто выгоднее не писать приложение, а подключить сервис форм или облачную функцию.

API. Для списка и заявки хватит простого REST с описанием OpenAPI. GraphQL нужен, когда у проекта несколько разных клиентов.

Вход. Начните с вопроса, нужен ли он. Если нужен, то без паролей (пасскей, ссылка с почты, Яндекс ID), а роли зафиксируйте заранее.

Заявки и уведомления. Приём, вебхук в мессенджер или письмо на почту. Подпись, идемпотентность и быстрый ответ. Два канала надёжнее одного.

Данные. База нужна, если что-то надо хранить и искать: заявки, пользователей, заказы. Если не нужна, не заводите. Про базы следующая часть.

Хостинг и сервер. От дешёвого хостинга с PHP до виртуального сервера (VPS) и облака. Для маленького проекта чаще всего достаточно одного VPS с nginx. Облака, контейнеры и Kubernetes (часть про инфраструктуру) нужны, когда проект вырос.

Выберите блоки для вашего главного действия, и схема сама скажет, чего не хватает и что лишнее:

Главное действие проекта: Главное действие

Блоки

Хостинг статических файлов (GitHub Pages, Яндекс Облако, любой хостинг) Веб-сервер (nginx) на VPS (VPS у российского провайдера) Приложение (Node.js, PHP…) (работает на том же VPS) База данных (PostgreSQL на том же VPS или управляемая) Вход (свой или через Яндекс ID) Сервис приёма форм (вместо своего приложения) Вебхук / уведомление (Telegram, почта) Почтовая рассылка и письма (сервис транзакционных писем) CDN (раздача файлов поближе к людям)

• Не хватает Главное действие «Главное действие» требует принять данные от посетителя: нужно приложение или сервис форм.

Ориентировочно: 0 ₽ в месяц. Порядок величин для российского рынка, не прайс: цены меняются, а у многих сервисов есть бесплатные ограничения.

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

Данные формы надо кому-то принять и о них известить владельца. Нужны хотя бы приём (приложение или сервис форм) и уведомление.

Россия: что учесть

Российский контекст добавляет три вопроса, которые в других странах задают реже.

Где лежат данные. Закон о персональных данных (152-ФЗ) требует, чтобы персональные данные граждан России при сборе записывались и хранились в базах на территории России. Заявка с именем и телефоном это именно такие данные. Поэтому основную базу выбирают у российского провайдера (например, Selectel, Timeweb Cloud, Яндекс Облако, VK Cloud, Cloud.ru). Копии в иностранных сервисах (в том числе в мессенджере) возможны, но о них надо сказать в политике обработки. Что именно и как оформлять, обсудите с юристом: закон трактуют строго, а штрафы ощутимы.

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

Хостинги и движки. В России много недорогих хостингов с PHP (WordPress и 1С-Битрикс ставятся там в пару щелчков) и большой рынок специалистов по ним. Для проекта на движке это вполне хороший вариант, а не «устаревший».

Риски

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

• упало приложение с формой: страницы остаются доступны (статика), на странице указаны телефон и почта, и мониторинг сообщает о сбое;
• недоступен канал уведомлений: заявка дублируется на почту;
• потерян сервер: резервная копия базы лежит в другом месте и обновляется каждый день, а сайт разворачивается из репозитория.

Практика

Вы на сайте эпохи 2022 года и подводите итог части. Соберите на одной странице схему серверной части вашего проекта: главное действие, путь данных от посетителя до владельца, семь блоков с выбором и причиной, где хранятся персональные данные и три риска с планом. Выбор «не нужен» для блока такой же полноценный ответ, как название инструмента. Хорошая схема короткая и конкретная: по ней можно поставить задачу разработчику или нейросети.

Что было не так раньше

В 2010-е годы «современным» считалось собрать для визитки стек из десятка технологий: приложение, база, кэш, очередь сообщений, поисковый движок, контейнеры. Это называли «чтобы потом масштабировалось». Потом оказывалось, что сайт никогда не вырос из тысячи посетителей в месяц, а поддерживать десять компонентов, которые каждый могут сломаться, было некому. А на другом полюсе стояла «чёрная коробка»: сайт на движке с пятьюдесятью плагинами неизвестного происхождения, и никто не знал, что где хранится.

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