На один сервис меньше: перенос HES в сервер авторизации

Что было ​

В Waviot сервер авторизации auth.waviot.ru выдаёт учётки, компании и JWT для всех остальных кабинетов. Это самописный PHP без фреймворка, он старше меня в компании. Рядом с ним с 2019 года жил HES, тоже самописный PHP на тех же принципах, задуманный как постепенная замена бэкенда телеметрии.

К 2024 году сложилась странная картина. Экраны партий приборов, PIN-кодов, базовых станций, контрактов, компаний и модемов пользователь открывал в auth. А их бэкенд был в HES: JS этих страниц ходил по адресу HES_HOST, который auth подставлял в шаблон. Один интерфейс, два сервиса, два деплоя, две базы кода, которые надо держать совместимыми.

При этом HES почти не развивался: два коммита за два года. И дважды не доехал до PHP 8: я делал это в 2022-м и снова в августе 2024-го, обе ветки так и не влились. Держать второй PHP-сервис ради нескольких контроллеров стало дороже, чем его убрать.

Что решил ​

Перенести контроллеры и модели HES внутрь auth. Не переписать, а перенести: код рабочий, его проблема только в том, где он живёт. И сделать это так, чтобы фронтенд не менялся вообще.

Как сделал ​

• Модели HES работают с базой телеметрии через то же соединение. В базовую модель auth добавил поле $database; модели из HES объявляют свою базу и пишут в неё полным именем таблицы. Схему базы не трогал, ровно как требовал README HES: "работать будет с базой Б".
• Роутер auth понимает оба способа адресации. Свой ?action=controller-method и HES-овский путь /batches-get/. Старые адреса продолжили работать.
• HES_HOST во фронте теперь равен хосту самого auth. Весь JS страниц остался без изменений и просто стал ходить в auth.
• Cron HES переехал в cron-файл deb-пакета auth.

Перенос: 54 файла, около 4,6 тысячи строк, 8 контроллеров и около 20 моделей плюс клиент RabbitMQ. Примерно половина строк дословно из HES, остальное адаптировано под классы auth: другое базовое соединение, другие имена методов.

Влито 30 августа 2024. Дальше три недели доводки отдельными MR, и я специально называл их честно: "пропустил кусок кода с hes", "забыл перенести", "функционал hes для аккаунтов". Перенос по живому так и выглядит, и лучше, когда это видно в истории, чем когда спрятано в одном большом коммите.

Что вышло ​

На один PHP-сервис меньше: нет отдельного деплоя, отдельной ветки под PHP 8 и отдельного места, где можно сломать совместимость. Код HES живёт в auth до сих пор и дорабатывается там же.

Вывод ​

Если два сервиса делят один интерфейс и одну базу, граница между ними существует только в репозитории. Самое дешёвое решение не "довести второй сервис до ума", а признать, что его не должно быть, и перенести код туда, где он уже используется. Главное при этом не трогать то, что не ломалось: схему базы и фронтенд.