Василий Банников

Пахнет утечкой памяти, даже очень-очень нагруженные приложения редко больше пары гигов потребляют.
"простейший api-сервис" редко больше 1гб потребляет
Я бы начал со снятия дампа памяти, чтобы понять, какие объекты столько занимают, а там уже можно будет и найти конкретное местно, где утечка произошла.

https://learn.microsoft.com/en-us/dotnet/core/diag...
https://learn.microsoft.com/en-us/dotnet/core/diag...

1. Можно сессии хранить в чём-то типа редиса - там можно задавать ttl
2. При хранении в обычной реляционке - можно на всякие события аутентификации, когда ты читаешь таблицу сессий - смотреть на ttl и удалять просроченные.
3. Сверху ещё добавляем какую-нибудь задачу в cron, которая будет раз в сутки чистить.

Но не совсем понял механизм, как сделать sign-out при не активности или полном истечении времени сессии. Единственное что приходит в голову это background tasks, но думаю, что есть более нормальные решения этой проблемы.

Не обязательно удалять сессию сразу после её истечения - всё равно же при запросах проверяешь время действия.

1. Не соглашусь с идеей "одна entity-один контроллер", так как сущности из EF далеко не всегда 1-в-1 маппятся на сущности твоего api

2. Проблема с DI логична, но далеко не всегда является проблемой. При достаточном желании можно настроить всё так, что у тебя все объекты, включая контроллеры и DAL будут Singletone (на одном проекте мы так сделали и это сильно увеличило производительность и снизило нагрузку на память).
Но вообще да - если у тебя в контроллере очень много зависимостей и в разных методах используются разные наборы этих зависимостей - значит что-то идёт не так и надо разделять (но не факт).
Помни ещё, что кроме инъекции в конструктор можно инжектить в параметры метода при помощи атрибута [FromServices]

3. Я предпочитаю группировать по сущностям api.
Тоесть если у меня будут сущности /orders, /items, то тогда у меня будет два контроллера: OrdersController и ItemsController - это упрощает поддержку и делает расположение методов логичным и очевидным.
=> Тактика по разбиению SignInController из вопроса будет зависеть от того, по каким url доступно каждое из его действий.

Ну и ещё наброшу:
Существует minimal api в котором нет контроллеров
https://learn.microsoft.com/en-us/aspnet/core/fund...
https://github.com/CarterCommunity/Carter

Существует практика создавать для каждого endpoint - свой класс.
https://github.com/ardalis/ApiEndpoints

1. Мануал по установке рантайма лучше таки официальный использовать:
https://learn.microsoft.com/en-us/dotnet/core/inst...

2.

Но их там несколько! И называются GemBox, SendMail...

А вот на этом моменте лучше обратиться к разработчику вашего сайта, если вы не имеете возможности тут поделиться структурой проекта.

В худшем случае проект ваш может быть старый - написан под старый asp net MVC / asp net webforms, а не под asp net core => может быть вообще не предназначен для линукса

И как эти scoped объеты существуют в background сервисах?

Никак. В рамках IHostedService никакой скоуп не создаётся - надо руками его создавать.
Как подтверждение - при попытке зарезолвить Scoped - будет ошибка

"Создается один объект при его запросе в рамках некой области, например http запроса, и в последующем выдается уже созданный в рамках этой области". Часто получал утверждение что неправильно, и непонятно что за область

Странные челы какие-то. Вроде вполне корректный ответ, хоть и странно сформулированный.

Scoped
For web applications, a scoped lifetime indicates that services are created once per client request (connection). Register scoped services with AddScoped.

In apps that process requests, scoped services are disposed at the end of the request.

When using Entity Framework Core, the AddDbContext extension method registers DbContext types with a scoped lifetime by default.

Note

Do not resolve a scoped service from a singleton and be careful not to do so indirectly, for example, through a transient service. It may cause the service to have incorrect state when processing subsequent requests. It's fine to:

• Resolve a singleton service from a scoped or transient service.
  
• Resolve a scoped service from another scoped or transient service.
  

By default, in the development environment, resolving a service from another service with a longer lifetime throws an exception. For more information, see Scope validation.

Есть паттерн такой "backend for frontend" - вот тебе нужно сделать как раз его.
Отдели ту часть, которая делает SSR в отдельный проект, а те места, где идёт обращение к бизнес-логике замени на вызовы твоего web api.

Соответственно тебе нужно будет написать web api.

1. Чем не устроила официальная документация?
docs.nethereum.com/en/latest

2. Чтобы её понимать, надо ещё с самим эфиром разобраться, так что по нему тоже доку читай.
Вероятно ещё придётся солидити изучить, чтобы смарт-контракты писать.

Я бы сделал отдельное предоставление для админа.