https://jwt.io/introduction "И как я понимаю, время жизни 6 значного кода будет ровняться жизни токена?" вы можете задать любое ValidUntil поле БД, где сохраняете отосланный код.
Heggi, "JWT может содержать что угодно, лишь бы не дергать сервис авторизации лишний раз (зачем его дергать, если в токене будет всё? Минус одна зависимость в пайлайне обработки запроса)"
Может. Но и GW может кешировать нужные данные по пользователю. Он может оперативно реагировать на состояние пользователя и оперативно блокировать токен или чать пользовательских пермишенов.
Поместив все в токен, вы увеличиваете сильно его размер и тем увеличивает лишний трафик, ведь большинство данных в токене может никогда и не пригодиться. Не можете оперативно прекратить время жизни токена.
"в токене хранятся эти данные или gateway на каждый запрос лазит в сервис авторизации" GW проводит валидацию токена и проверяет пользовательские пермишены. Зачем ему ваши группы и подразделения? Это все будет в сервисе.
" Как ограничить доступ к конкретной транзакции по принадлежности к группе и подразделению?" это уровень сервиса "Транзакций". Т.е. банальный фильтр.
EDA подразумевает, что описание групп, подразделений, правила на их CRUD будут в сервисе "Авторизаций", он источник правды по этим данным. А сервис "Транзакций" подписан на обновление состояний данных обьектов и просто обновляет минимальную копию этих данных, нужных для правильнй фильтрации ваших запросов. Для примера наменование группы/подразделений хранить не нужно если эти обьекты используются только для фильтрации и никогда не отдаются в GW
Heggi, JWT по факту должен содержать только UserID.
Gateway на себя берет валидацию токена, авторизацию пользователя и роутинг запросов к сервисам.
GW для админки будет иметь одни роутинги, для Dashboard другие.
Для запроса "Пользователь запрашивает транзакцию с id=7152522" GW проверяет имеет ли пользователь права на это действие и просто отправляет запрос в сервис "Транзакций" или "Поиска". Зависит от бизнес логики проекта (В GW нет БЛ).
"Если фильтрацию отдать на сторону Gateway, то получим не 30 записей"
GW не должен содержать бизнес логики, я тут выше описал для чего он.
"Следовательно сервис транзакций так или иначе должен обрабатывать содержимое JWT-токена или сходить в сервис авторизации и запросить что этому пользователю позволено." Сервис транзакций не должен знать об наличии сервиса "Авторизации". GW имеет прямой доступ к сервису Авторизации для получения "разрешений". А информация об группах и подразделениях приходит только через Message Broker.
Heggi, "Использование Gateway в качестве "объединятора" данных" - об этом не говорилось. Конечное разные запросы и никакой логики по обьединению в gateway нет.
"Проверять роли? Каждый сервис у нас и так проверяет роли". Gateway проверяет права доступа к данным. А сервис только отдает нужные данные в соответсвии с условиями, в том числе с условиями по доступу (группа, подразделение и т.д.). Еще gateway отсекает важные сервисы от внешнего мира, чтобы у вас не торчали сервисы наружу.
"Объединять несколько запросов в один? Смысл? Фронту проще сделать несколько запросов. Про обогащение уже писал."
Об этом не говорилось. Каждый сервис выполняет свои запросы, никаких обьединений данных от разных сервисов gateway не делает. Если нужны обьединения, то это доп.сервис "Поисковый", который содержит нужные копии данных.
Heggi, У вас взаимодействие пользователя с сервисами должно идти через Gateway, а он может иметь коннект сразу и к сервису "Поиска" и сервису "Транзакций". Так что детализацию получить не проблема без дублирования.
Heggi, Сервис поиска для сложных поисковых запросов и поиск по агрегированным данным.
Пример: Сервис "пользовательских действий" (лайки, просмотры, комментарии) и сервис "статей", а посковый сервис уже просто отдает статьи из индекса, плюс содержит количество лайков, просмотров на статью. Детальная иформация остается только в сервисе "пользовательских действий" .
"еще придется продублировать и список транзакций." для чего? Пользователям реально требуются к показу эти миллионы?
"так же не решает проблему долгой начальной синхронизации" так это начальная синхроницация, она розовая и она может быть отделена на время от всей системы. И при постоянной работе больше синхронизация не нужна. И снова нужны ли тут эти миллионы транзакций?
Василий Васильков, Нет, это я не имел ввиду. У вас есть родительский элемент с ref и через него доступны все дочернии. И писать "ref={containerRef.current[index]}" не нужно
Так и какие есть что можно удалить? Для примера ps eye camera там несколько вариаций, в одной можно удалить ИК, а в другой нет и четких внешних признаков нет. Уже лотерея. ((
WSGlebKavash, Так в файле может быть содержимое, а на хосте может быть программа, что отслеживает появление файла в шаред и выполняет команды из него. Это как вариант. Возможно есть и другие
Тут обычное не понимание как правильно писать асинхронный методы. Человек пытался оставить метод с результатом Task<>, но асинхронных вызовов в его коде нет, вот и выкрутился.
Тут правильно либо делать метод без Task, либо убрать в определении слово async и отдавать в результат Task.FromResult без await
Алексей Березников, Проблема реальная. Уже на втором вызове может не отображаться лоадер в ситуации
_semaphore.WaitOne();
await Task.Delay(10);
_semaphore.Release();
так как освобождение семафора никогда не произойдет.
