Всем привет! Пишу API для своеобразной соц сети.
При каждом запросе данных происходит:
1. Запрос к БД для проверки существования полученного от клиента токена
2. Если токен существует - запрос на получение ID пользователя с этим токеном
3. Получение данных из БД о пользователе, ID которого получили
4. На основе полученных данных из шага 3, получаем роли пользователя для проверки возможных действий
В итоге при каждом, даже самом маленьком запросе данных, приходится делать 4 обращения в базу данных. Что, наверное не правильно...
Как вы делаете подобное?
Но ведь тогда нарушается принцип "каждый класс отвечает за свою область".
Один класс за проверку токена, другой за аутентификацию пользователя, третий за получение ролей пользователя.
У меня с этими правилами, на самом деле, всегда проблемы... Если делать постоянно следуя им - я упираюсь в кучу дополнительного кода и бОльшему количеству операций и вызовов всяких методов...
Один класс за проверку токена, другой за аутентификацию пользователя, третий за получение ролей пользователя.
Зачем СТОЛЬКО-ТО?! Класс на блокировку/разблокировку юзера - тоже есть?!)
У Вас связанные зависимости через оператор AND.
Отношение токена к юзеру: 1-к-1. Нет токена или юзера - нет мультиков!
Вы не можете двигаться дальше по бизнес-логике без получения всех параметров из базы (user exist = true, user token = true, roles=[.....]).
Т.е. это "if-then"-конструкция: "Если всё есть - дай мне роли юзера".
Это один класс - "юзер" с методом "получения ролей".
Метод уже сам всё проверяет: лезть в базу, не лезть, юзер авторизован или нет, и т.д. и возвращает или список методов, или иной результат (например, ошибку), или сам осуществляет все необходимые действия для получения запрошенных методов по токену.
Советую - с блок-схем начать понимание логики и не плодить лишних объектных зависимостей в виде классов: это жрёт и память и проц...
Переписать в один запрос. Ну или в два, смотря как роли вытаскивать.
Затем поставить memcache или redis и по ключу "токен клиента" писать готовую структуру пользователя и его прав, соответственно добавить инвалидацию при изменениях в базе. Запросы с несуществующими токенами можно тоже кешировать с указанием разумного TTL и переписывать при генерации нового токена.
Как такового чистого JWT не получается, потому что все равно придется проверять в БД не нажал ли пользователь кнопку "выход".
Получается токен будет валидный до тех пор, пока не закончится его время существования.
Нажал кнопку выход и улалил токен из локалСторадж и больше нечего будет слать и следовательно доступа больше не будет. Существует масса способов обойти проблемы, это точно лучше, чем делать 4 похода в БД на каждый чих
Средний
