Вход, платежи, письма, хранение файлов и аналитика — пять частей, которые нужны почти любому продукту и которые трудно сделать надёжно в одиночку. Готовый сервис берёт на себя самое неприятное: безопасность, доставляемость, эксплуатацию. Взамен вы получаете зависимость от поставщика, и её нужно ограничить с самого начала.
После урока вы сможете
- Назвать пять типовых частей продукта, которые разумно брать готовыми
- Выбрать сервис по критериям и проверить его до подключения
- Изолировать сервис в коде так, чтобы его можно было заменить
- Составить реестр внешних сервисов с владельцами аккаунтов
Содержание
Что брать готовым и на что смотреть
Для каждой из пяти частей есть свои вопросы. Общие критерии вы уже знаете из прошлого урока, здесь — то, что специфично.
Вход (аутентификация)
- Что должен уметь сервис
- регистрация, вход, сброс пароля, при необходимости вход через внешние аккаунты
- Что проверить до выбора
- можно ли выгрузить пользователей; как хранятся пароли; можно ли настроить права доступа к данным
Платежи
- Что должен уметь сервис
- приём оплаты, статусы платежей, возвраты, уведомления (вебхуки)
- Что проверить до выбора
- работает ли с вашим юрлицом и банком; как оформляются чеки и закрывающие документы
Письма (e-mail)
- Что должен уметь сервис
- доставка транзакционных писем: подтверждения, сбросы пароля, чеки
- Что проверить до выбора
- настройка вашего домена (SPF, DKIM), что происходит при блокировке отправителя
Хранилище файлов
- Что должен уметь сервис
- загрузка, выдача по ссылке, ограничение доступа
- Что проверить до выбора
- кто может скачать файл по ссылке; можно ли вывести все файлы одной командой
Аналитика
- Что должен уметь сервис
- события и воронка: пришёл, зарегистрировался, выполнил целевое действие
- Что проверить до выбора
- какие персональные данные уходят поставщику; можно ли получить сырые данные
Для платежей в Казахстане набор доступных провайдеров и способов оплаты зависит от вашего юридического лица (ИП, ТОО), банка и вида деятельности. Не рассчитывайте, что сервис, популярный в других странах, будет доступен вам. Условия подключения, комиссии, документы и порядок выдачи чеков уточняйте у самого провайдера и у вашего банка до того, как заложите платёж в сроки. Как устроен сам процесс оплаты и обработка вебхуков, объясняет урок Интеграция платежей; устройство входа — урок Аутентификация: сессии, cookies и JWT.
Зависимость от поставщика: чем она опасна
Привязка к поставщику (vendor lock-in) — ситуация, когда уйти от него дорого или невозможно. Сервис может поднять цены, поменять условия, закрыть доступ в вашей стране, уйти с рынка или заблокировать ваш аккаунт. Это не повод отказываться от готовых сервисов, а повод заранее ответить на вопрос «что я буду делать, если завтра этого сервиса не станет?».
Три вопроса, которые стоит задать до подключения:
- Какие мои данные находятся у поставщика и можно ли выгрузить их целиком в понятном формате?
- Что пользователь потеряет при смене сервиса: пароли, историю платежей, файлы?
- Сколько изменений в коде потребует замена?
Ответы запишите — они станут частью вашего реестра внешних сервисов.
Как сделать сервис заменяемым
Идея из принципов The Twelve-Factor App: внешние службы подключаются как ресурсы, которые можно заменить, не меняя код приложения. На практике одиночке достаточно трёх привычек.
- Один модуль на сервис. Весь код, который общается с сервисом, лежит в одном месте — например, папке
services/email. Остальное приложение вызывает ваши собственные функции вродеsendEmail(to, subject, body), а не библиотеку поставщика. - Настройки — в переменных окружения. Ключи и адреса не прописаны в коде (см. урок про секреты и переменные окружения).
- Свои идентификаторы. Не используйте идентификатор поставщика как единственный номер пользователя или заказа: храните свой и рядом сохраняйте внешний.
Пример границы в коде:
// services/email.ts — единственное место, знающее о поставщике писем
export async function sendEmail(to: string, subject: string, html: string) {
// здесь вызов API выбранного поставщика; при смене меняется только этот файл
}Пример учебный: он показывает форму границы, а не готовую отправку писем. Реальный вызов, обработку ошибок и повторные попытки добавьте по документации выбранного поставщика.
Реестр внешних сервисов
Когда сервисов станет несколько, без списка вы забудете, где что оформлено и кто может войти. Реестр — таблица в репозитории или в общем документе:
Аккаунты регистрируйте на рабочую почту, которая останется у вас или у компании, и включайте двухфакторную защиту. Если проект потом будет передаваться инженеру или команде, такой список входит в пакет передачи — см. урок Передача MVP команде.
Что дальше
Дальше — безопасный минимум: что нужно сделать с ключами, доступами и резервными копиями до того, как придут первые пользователи. Если вам нужно подключить сервисы или собрать интеграции аккуратно, посмотрите услугу разработка программного обеспечения.