Поднимая вопрос о производительности и оптимизации большого объема данных, могу посоветовать следующие способы оптимизации выдачи API (мыслю конечно в контексте dotnet):

0) GraphQL
Понятно, почему я против того, чтобы фронт решал какие данные из БД ему нужны, и как страдает (исчезает) от этого слой бизнес логики бэкенда, но имеет место быть, и не говорить о нем нельзя.

1) Пагинация
Стандартная тема, скипаем n, берем m элементов из БД. На практике, если используются прослойки, например MediatR, то тут универсальности не добъешься, придется в хэндлере медиатора отдавать IQueryable, что не очень подходит как универсальное code-design решение, которое может выбиваться из устоявшегося стиля подхода существующих зрелых проектов.

[HttpGet]
public async Task<IActionResult> Get([FromQuery] int pageNumber = 1, [FromQuery] int pageSize = 100)
{
    return Ok(await _dbContext.Data
                             .Skip((pageNumber - 1) * pageSize)
                             .Take(pageSize)
                             .ToListAsync());
}

2) Поток
Почему-то не очень распространенный подход, но очень классный, в своей простоте. Пока фронт отрисовывает всё поступающие элементы, бэк обрабатывает и выдает все новые, не забивая при этом память, т.к. нет потребности хранить весь ответ. Есть те-же минусы, что и у 1, но при этом очень сильный бенефит который этот минус прикрывает.

[HttpGet]
public async IAsyncEnumerable<DataEntity> GetDataAsStream()
{
    await foreach (var item in _dbContext.Datas.AsAsyncEnumerable())
        yield return item;
    }
}

3) Сжатие
Можно включить сжатие всех ответов на уровне приложения, но это занимает некоторые ресурсы процессора, если есть возможность настроить для конкретных эндпоинтов то круто (не копал глубоко в настройки этой фичи). Но не думаю что комрпессия будет сильно выиграшнее чем просто gRPC или контракт на Protobuf, где убираются самые повторяющиеся части ответов — названия полей.

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCompression(options =>
    {
        options.EnableForHttps = true;
    });
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseResponseCompression();
}

4) Заголовок Cache-Control
Думаю что для одного и того-же клиента, врятли сильно изменится информация в выдаче в течение 5 секунд или 5 минут, в зависимости от кейса. А мы сэкономим на валидациях, мапперах и обращениях в БД.

[HttpGet]
[ResponseCache(Duration = 60)] // кэш на 60 секунд
public IActionResult GetData()
{
    return Ok(_dbContext.Datas.ToList());
}

MinimalAPI vs Controllers

Тут мужик сравнил быстродействие эндпоинтов с использованием вышеупомянутых подходов по декларированию и обработке API. Почитал, ничего сверхъестественного не получилось в итоге. MinimalAPI примерно на 8% быстрее отрабатывает, и в 1.5 раза меньше выделяет памяти в процессе запроса.

Но у MinimalAPI есть свои минусы перед обычными контроллерами:
1) В первую очередь самый большой минус исходит из самого большого плюса: ПРОСТОТА. Простая декларация имеет сложности в поддержке, при росте и усложнении проекта, соответственно простой API лучше использовать для простых приложений.
2) Из-за своей небольшой распространенности, имеет меньше примеров и не все разработчики смогут с наскока с ним работать.

Rate Limiter

А еще, вместо того, чтобы бороться с причинами долгой работы API — можно бороться с его последствиями! Для этого просто ограничим пользователей, чтобы они не могли делать много запросов и тогда мы разгрузим мощности для наших неоптимизированных операций!

Нужно всего лишь добавить NuGet:

$ dotnet add package Microsoft.AspNetCore.RateLimiting

И добавить ограничения:

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("HundredPerSecondPolicy", opt =>
    {
        opt.PermitLimit = 100;
        opt.Window = TimeSpan.FromSeconds(1);
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        opt.QueueLimit = 2; 
    });
});

app.UseRateLimiter();

Так мы запрещаем обращаться к нашему апи, если за секунду к нам пришло больше 100 запросов.

Если без шуток, то это правда имеет реальные бенефиты:
* Большое количество запросов может замедлить работу приложения или даже привести к сбоям.
* Помогает остановить атаки методом перебора, ограничивая количество попыток входа в систему или вызовов API.
* Гарантирует справедливое распределение ресурсов API между всеми клиентами.
* Для облачных сервисов с тарификацией за каждый запрос, сокращение количества запросов может помочь снизить расходы.

В этой-же библиотеке есть и более гибкие способы, с линейным распределением и пр., по ограничению запросов (название соответствует политике, подобно Fixed Window Limiting — options.AddFixedWindowLimiter):
1) Token Bucket Limiting — разрешает пакетный трафик путем накопления токенов. Запросы потребляют токены, и когда их не остается — запросы ограничиваются.
2) Sliding Window Limiting — сглаживает распределение запросов, проверяя частоту по скользящему окну вместо фиксированного временного окна.
3) Concurrency Limiting — ограничивает количество одновременных запросов.

Ну и Best Practice:
1) Детализация ограничений: Ограничения в зависимости от клиента, пользователя или IP-адреса. Например, вам могут потребоваться более строгие ограничения для пользователей, не прошедших проверку подлинности, и более мягкие ограничения для доверенных клиентов.
2) Код ответа: При превышении лимитов скорости возвращаются значимые сообщения с кодом состояния 429 Too Many Requests. С добавлением информации о том, когда клиент сможет повторить попытку снова.
3) Заголовки: Используйте заголовки ограничения скорости X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset, чтобы предоставлять клиентам обратную связь об их текущем состоянии ограничений.

DDD

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

🤡

Не нашел в истории, хвастался ли я своими NuGet пакетами, но вот они, и у них уже 22к скачиваний 😁

Ой, как неожиданно и приятно (с)

Это не оверинжениринг если:
1. Тебе было весело
2. PM не заметил

Остановите мой ор ахахахха

Слышал про одну притчу, про хирурга и автомеханика:

Приезжает хирург в автосервис. Мастер объявляет ему стоимость ремонта двигателя. Хирург соглашается.
Мастер ему говорит: -"Почему такая несправедливость? Ты ведь тоже "механик", только людей ремонтируешь. А стоимость работы у нас с тобой не сопоставима."
Хирург с удивлением говорит: -"Да? Ну хорошо!"
Заводит двигатель автомобиля, и говорит мастеру: -"Вот теперь ремонтируй!"

В наших (айтишных) руках, конечно не человеческая жизнь, но аналогия схожа. Только автомобиль при этом не только заведен, а еще и едет по дороге на скорости. И на ходу нужно в него добавлять всякие кнопочки, которые позволяют более гибко зажигать лампочки в автомобиле. Кому-то нужно встроить принтер в бардачок, чтобы он печатал давление всех колес, кроме одного, которое пользователю нужно вывести на экранчик в руле, потому что ему так виднее. Или добавить пятое колесо в движении.

И всё это на ходу, без остановок. Из вспомогательных факторов: можно остановиться несколько раз за неделю, на 10-15 минут; параллельно едет такая-же машина, с которой можно делать что угодно и останавливать на сколько угодно, чтобы проверить и подготовить все новые штуки к внедрению в основной автомобиль.