В ретроспективе v1 я обещал, что для v2 будет настоящий план маршрута ещё до того, как напишется хоть одна строчка кода. Вот он, реальный план, опубликованный, чтобы будущий я не мог сделать вид, что там было написано что-то другое. Этот пост только о том, что впереди. Всё, что уже вышло, получает отдельные посты в этом дневнике разработки, для этого он и существует.
Основная идея: располагать вещи по порядку зависимостей, а не по порядку энтузиазма. Почти всё, что я хочу, висит на нескольких несущих частях, так что они идут первыми, даже если делать их наименее весело:
+----------------------+
| email service | the keystone
+----------+-----------+
|
+------------+----------+-----------+-------------+
v v v v
password reset contact alerts reply notifications newsletter
+---------------------+ +---------------------+
| central log service | | backups (DB+media) |
+---------------------+ +---------------------+Первая волна это инфраструктура. Сервис почты идёт первым, потому что четыре разных функции, которые я хочу, нуждаются в отправке писем, так что почта становится своим отдельным крошечным сервисом с устойчивым outbox, и всё остальное просто просит его что-то отправить. Сложная часть почты не SMTP, это просто вызов библиотеки. Сложность во всём, что вокруг: не терять письмо при перезапуске процесса, не отправлять одно и то же письмо дважды, когда повтор попытки пересекается с успехом, и доставляемость, тёмное искусство записей SPF, DKIM и DMARC, которое решает, попадёт моё письмо во входящие или в спам. Похоже, я потрачу больше времени на чтение документации по DNS, чем на написание Go.
Резервные копии в первой волне, потому что у них нет зависимостей и нет оправданий. Сложная часть бэкапов не в том, чтобы их делать, с этим справится cron. Сложность в том, чтобы доказать, что они восстанавливаются. Непроверенный бэкап это просто ощущение, а не бэкап, так что в план входит реально восстанавливать его на тестовую базу данных по расписанию и проверять результат. И копии за пределами сервера тоже, потому что бэкап на том же диске, что и то, что он бэкапит, защищает ровно от одного типа сбоя, и не от самого страшного.
Центральный сервис логирования это честный чудак в этом списке. Личному блогу он не нужен, таблицы ошибок в каждом сервисе и так работают. Я всё равно его строю, потому что паттерны внутри него и есть вся суть: отправитель типа outbox, который пакетами отгружает строки в центральный приёмник, повторяет попытку, когда сеть падает, и потребитель, который остаётся корректным, даже когда один и тот же пакет приходит дважды. Это паттерны, которые стоит освоить на системе, где радиус поражения это мой собственный блог. Я записываю это, чтобы случайно не переусложнить его до чего-то в корпоративном стиле.
Вторая волна это всё, что нуждается в почте. Сброс пароля звучит просто, а на деле полон острых углов: токены сброса, которые истекают и могут быть использованы только один раз, и ответы, которые не раскрывают, есть ли у этого email аккаунт здесь. Подтверждение почты идёт следом. Уведомления с контактной формы это лёгкая разминка. Уведомления об ответах на комментарии нуждаются в возможности отписаться от конкретной ветки, никто не хочет получать письма вечно только потому что однажды оставил комментарий. Рассылка это самое глубокое место: согласие подписчиков, ссылки отписки, которые всегда работают (это требование закона, а не вежливости), и отправка достаточно медленная, чтобы мой один маленький сервер не занёс сам себя в чёрный список.
Третья волна самая весёлая. Массовая загрузка фото и галерея, потому что этот блог постепенно превращается в коллекцию фотографий с походов, к которой прилагается блог. Сложные места: провести сотни файлов через загрузку в браузере так, чтобы один сбой не испортил всю партию, генерировать миниатюры на сервере, чтобы галерея не отправляла на твой телефон фото в полном размере, и вычищать EXIF данные перед публикацией, потому что фото, которое тихо носит в себе GPS координаты, это утечка приватности в костюме красивого заката. Серии постов тоже сюда, связывание постов в упорядоченную коллекцию, это больше вопрос моделирования, чем кода.
Четвёртая волна это охват. ActivityPub это финальный босс: сделать так, чтобы посты федерировались, чтобы люди могли подписаться на этот блог из Mastodon. Это значит actors, inbox, outbox и HTTP подписи, и по слухам каждый сервер говорит на чуть своём диалекте этой спецификации, так что большая часть работы это отладка федерации с серверами, которые я не контролирую. Webmentions это более лёгкая разминочная версия той же идеи. Помощник перевода для трёх языков, на которых работает этот блог, тоже сюда относится: переводить один раз при написании и сохранять результат (просмотр страницы никогда не должен стоить вызова API), замечать, когда исходный текст изменился, чтобы перевод можно было пометить как устаревший, и машинный результат всегда должен приземляться как черновик для моей правки, никогда сразу в публикацию. И офлайн чтение как PWA, где известная ловушка это инвалидация кэша, показывающая читателям устаревший сайт вечно.
Каждая из этих вещей выходит как свой собственный маленький законченный кусок, а не одна гигантская ветка v2, которая живёт месяц. Даже если приживётся только первая волна, v2 уже того стоил. Скучное вперёд, специально, письменно. Держите меня за слово.