29 февраля в гостеприимном Санкт-Петербурге на Saint P Ruby Meetup Winter 2024 рассказал про запущенный проект "Аутентификации об монолит" (слайды и видео-запись)

💡Идея в том, чтобы дать возможность новым микро-сервисам обслуживать аутентифицированный трафик, и разблокировав реализацию новых фичей в обособленном сервисе (а не в монолите).

1️⃣Входящий трафик аутентифицируем "об монолит" отдельным запросом
2️⃣Заменяем оригинальные аутентификационный заголовки - внутренним X-Auth-Identity, в котором содержится результат аутентицикации
3️⃣Оригинальный запрос снабжаем аутентификационными данными (UUID пользователя)

На первый взгляд решение костыльное: поскольку изначально вся логика аутентификации находится в Rails-монолите, то и предлагаемое решение завязано на монолит. В этом смысле как будто ничего не меняется!

Но нет же! Можно еще хуже: пустить трафик в новый сервис через монолит, делегировав ему предварительную аутентификацию и роль API-гейтевея!

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

Более того, на личном опыт подтверждаю, что схема рабочая, как для запуска, так и для дальшейшего расширения в системное решение!

А сам подход универсальный, и может быть применен для монолитной архитектуры любого стека. Хотя в докладе добрая половина времени уделена специфике Rails-монолита.

Ссылку на слайды и видео-запись прилагаю.