Сразу пару замечаний:
1) статика - зло, уберите статичный лист с пользователями, это bad practice
2) Используйте типизированный хаб, чтобы не делать Clients.All.SendAsync("UsersListChanged")
Вы уверены, что метод OnDisconnectedAsync не вызывается? Может просто ничего из листа не удаляется?
Василий Банников, ну, по сути щас так и есть, в 1 репозитории лежит 2 апи разных, библиотеки там же, но в других папках, то есть: api1: d:/repo/api1, api2: d:/repo/api2, dll1: d:/repo/dll1, dll2: d:/repo/dll2. api1 & api2 ссылаются на обе dll, то контекст мне надо указывать на d:/repo? как он поймет тогда, что мне именно надо собрать api1, а не api2? в будущем в репозитории будет много api, например, как быть?
Василий Банников, если правильно понял, то монорепозиторий - когда все проекты в 1 репозитории? Если да, то как это поможет? Проекты всё равно по разным папкам лежат же
Василий Банников, уже думает над тем, чтобы собирать на dev компах, публиковать в нужную папку, откуда докер и будет всё тащить, таким образом уже всё нужное будет в 1 месте (в т.ч. нужные dll). Но не знаю, есть ли уже после этого смысл
+1 к тому, что 20-30 проектов - норма, текущий проект на работе буквально сейчас состоит из 26 проектов, но у меня там всего 3 exe, а остальное - dll.
Каждая dll должна отвечать за свое, например у нас это: 1 - общие классы для ответов от API (несколько API отдают одинаковые ответы (по формату т.е.)), exception и прочие штуки, 2- библиотека для авторизации через JWT, общие настройки JWT, пр., 3 - Unit of Work (который сам состоит из 3 проектов) и так далее. Сделано это для того, что бы не тащить ненужное в проекты, нужен сервис генерации рандомной строк (как пример) - добавил 2 библиотеки (в нашем случае 2, потому что есть интерфейс и его реализация в другой библиотеке) и используешь его везде.
Поэтому ваши 20-30 проектов, если сделаны грамотно, то никаких сложностей не доставят, наоборот повышают (ИМХО) гибкость ваших проектов.
Dudder, если честно - не понимаю зачем в нем что-то хранить в целом, время жизни у Refresh'a тоже должно быть время жизни, в базу полезете всё равно, а там можно и связь на таблицу пользователей сделать
Лично у нас сделано так, что Refresh живет независимо от JWT, JWT живет как правило несколько минут, а Refresh может жить хоть год. Поэтому у нас сделано так, что после недели неактивности можно по Refresh'y взять новый JWT и продолжать работать. Refresh'и держим в базе, при попытке обновить JWT по Refresh'y - смотрим в базу и строим новый JWT. Имхо, но нет смысла держать в Refresh'e данные, т.к. за время жизни JWT и Refresh'a могут поменяться данные человека, в т.ч. роли, имя, почта и прочее, иногда эти данные нужны в JWT.
Поэтому вам не обязательно получать никакие данные от пользователя, достаточно сам Refresh token, а по нему в базе посмотреть кто его запрашивает и выдать новый JWT. (ИМХО(!))
1) статика - зло, уберите статичный лист с пользователями, это bad practice
2) Используйте типизированный хаб, чтобы не делать Clients.All.SendAsync("UsersListChanged")
Вы уверены, что метод OnDisconnectedAsync не вызывается? Может просто ничего из листа не удаляется?