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 минут; параллельно едет такая-же машина, с которой можно делать что угодно и останавливать на сколько угодно, чтобы проверить и подготовить все новые штуки к внедрению в основной автомобиль.