Ворклог по задаче "Перенести сайт на новый движок"
Итог миграции pivkarta.ru: production и SEO/performance evidence
Задача завершена: новый pivkarta.ru выведен в production. Дальнейшие доработки будут оформляться отдельными задачами.
Масштаб brownfield-миграции
Новый сайт построен поверх развивавшегося HAIH runtime, но для реального legacy-проекта движок был существенно доработан до полноценной production-схемы: единый Express runtime, React Router SSR, GraphQL/Apollo/Pothos, Knex к существующей MySQL, Vite middleware в development, production static serving, Varnish, обработка legacy thumbnails через Sharp, ETag/GET/HEAD и корректное завершение серверных ресурсов.
Восстановлена основная публичная структура старого продукта: пиво, заведения, публикации, участники, комментарии, города, карта и контакты, включая исторические URL и связи между сущностями. Инвентаризация legacy-данных зафиксировала 1 636 записей пива, 3 797 заведений, 600 статей, 64 города, 3 296 комментариев и 26 548 публичных профилей.
Для совместимости был построен реестр из 73 760 адресов. Полный HTTP-обход зафиксирован как passed: 73760 без ошибок на проверенном состоянии. Дополнительно проверялись 11 579 ссылок контента и 19 660 URL ресурсов. Последующие изменения ветки покрывались целевыми тестами, поэтому старый полный crawl не следует считать проверкой каждого последнего коммита.
Измеримый production-результат
Основная работа текущей итерации с 28 сентября заняла по таймерам 18:01:02.
Lighthouse до/после:
| Метрика | Legacy | New |
|---|---|---|
| Performance | 49 | 93 |
| Accessibility | 75 | 100 |
| Best Practices | 74 | 96 |
| SEO | 83 | 100 |
Application runtime по docker stats:
- legacy
front: 588.4 MiB; - legacy
api: 231.3 MiB; - legacy
prisma: 953.2 MiB; - legacy application layer суммарно: ~1773 MiB (~1.73 GiB);
- новый
app: 178.2 MiB.
Таким образом, application RAM уменьшилась примерно в 10 раз (~90%), при одновременном росте Lighthouse Performance с 49 до 93 и достижении 100 по Accessibility и SEO. Особенно показательно, что один только Prisma 1 старого стека потреблял ~953 MiB — более чем в пять раз больше всего нового application runtime.
Главный инженерный вывод
Миграция подтвердила brownfield-гипотезу HAIH: для замены legacy-приложения необязательно воспроизводить его историческую архитектуру. Практический путь оказался таким:
legacy system → восстановление реальных requirements/capabilities → проверка данных и URL-контрактов → отбрасывание ненужного наследия → минимальная новая архитектура → verification → production evidence.
Первоначальная гипотеза о сохранении legacy-модели как основной архитектурной границы была скорректирована после исследования реальной БД и 250 таблиц. В результате сохранены ценные публичные данные, связи и web-контракт, но не воспроизведена накопленная инфраструктурная сложность старой системы.
Это отличает результат от обычного редизайна: получен production replacement реального многолетнего сайта с измеримой совместимостью, существенно меньшей стоимостью runtime и заметно лучшими web-метриками.
Граница этой задачи
В рамках этой задачи считаем миграцию выполненной. Отложенные write-сценарии (авторизация, создание/редактирование сущностей), дальнейший индивидуальный редизайн внутренних страниц, дополнительные production-проверки и прочие улучшения должны выполняться отдельными задачами, а не расширять текущую.