Василий Банников, ну вот это уже звучит как аргумент :)
Спасибо! Будем слегка смещать UoF в сторону сервисов, которые реализовать будем в Infrastructure, когда это возможно. Можете оформить как ответ, в целом это решает мою головную боль :D
Роман, А еще можно с апи отдавать время жизни токена и проверять время жизни без запроса на сервер, проверил время жизни - подходит к концу или кончилось - обновил - послал запрос дальше, но уже с новым токеном
Nik Faraday, это полный бред. В запросе может и не быть refresh token'a (в 99.9% запросах его и не будет, потому что в обычных запросах он и не нужен), который нужен для обновления jwt, тот, кто вам такое ТЗ дал - пусть и скажет вам, как это должно выглядеть. Такие вещи лежат на плечах клиента, но никак не сервера.
Nik Faraday, EF всю жизнь делает так, что открывает соединение по каждому чиху, а потом закрывает обратно сразу же. Поэтому проблема явно не в том, что просто открываете и закрываете соединение постоянно.
Nik Faraday, с blazor server в этом плане не работал, он в целом какой-то кривой для этих вещей, на wasm никаких проблем не было положить банально в local storage
Bayfong, Придумать бизнес задачу за вас?) Никаких примеров тут я придумать не смогу. В гугле много road map для C#, изучайте сначала его, а уже потом влезайте в юнити - всё, что могу сказать.
Bayfong, ну, опять же имхо, "минимальное приложение" - то, которое может делать %что-то% и не ломаться (%что-то% - любая бизнес задача). Опять же, показать MessageBox != jun.
Vitaly Karasik, билд и деплой должны стартовать после изменения основного кода. Но есть пару критичных сабмодулей, за которыми стоит следить пристально и они должны точно попадать в деплой. Например: инициализация настроек приложения, была ошибка в сабмодуле - её исправили и надо сделать билд + деплой после этого, но основной код никак не поменяется.
На сколько будет хорошей практикой такой расклад:
1) 1 задача смотрит в master ветку (она же dev) и просто обновляет сабмодули и делает коммиты этих изменений
2) 2 задача смотрит в build ветку (она же prod), собирает и выкатывает в прод приложение
3) Вся разработка ведется в master'e и игнорируется для сборки
Хотелось бы автоматизировать обновление сабмодулей, чтобы руками не обновлять их
Спасибо! Будем слегка смещать UoF в сторону сервисов, которые реализовать будем в Infrastructure, когда это возможно. Можете оформить как ответ, в целом это решает мою головную боль :D