Тонкости работы short-circuit routing в ASP.NET Core 8.0

[AgentFire]

Minimal API выглядит как наследник ушедшей Nancy кстати.

А что касается short-circuit... есть ощущение, что сделали костыль для тех, кто не умеет мидлвари использовать. Например, используя их для всего подряд.

[ryanl]

По поводу short-circuit - это вовсе не костыль, это оптимизация использования CPU для веб-приложений. Тот же StaticFilesMiddleware, если вы, например, делаете запрос на получения favicon, то не имеет смысла уже далее пропускать через routing, авторизацию и прочее, а надо сразу вернуть ответ. Это просто здравый смысл обработки запроса.

[AgentFire]

StaticFilesMiddleware

Так пущай он .Next() не вызывает. В этом же вся задумка мидлварей. Смысл костылить альтернативу основному инструменту?

[ryanl]

Так он так и работает из коробки. А то что автор статьи описал - это возможность писать свой подобный функционал быстрее.

[m3ta10ph0b]

Про "наследник ушедшей Nancy" - тоже вижу очевидные сходства, разработчики явно ориентировались на него и на подобные реализации в других языках.

[ryanl]

Я бы еще добавил, что short-circuit можно и самому делать, достаточно в своих Middleware/RequestDelegate-ах, НЕ вызывать следующий в пайплайне RequestDelegate - который обычно обозначается идентификатором next. Это уже от логики зависит. А если и вызываете, то в доках есть упоминание, что лучше использовать те перегрузки, которые требуют явной передачи HttpContext-а в следующий RequestDelegate - это позволяет избежать 2 лишних аллокаций памяти во внутренней кухне пайплайна.

//делай так
//Func<HttpContext, RequestDelegate, Task> - используется эта перегрузка
app.Use(async(context, next) =>
{
    //my middleware logic
    
    //next one
    await next(context);
});

//НЕ делай так
//Func<HttpContext, Func<Task>, Task> - используется эта перегрузка
app.Use(async(context, next) =>
{
    await next();
});

[m3ta10ph0b]

Да, согласен, так можно сделать. Главное этот кастомный middleware с проверкой добавить в самое начало пайплайна и следить, чтобы перед ним не добавили какой-нибудь другой middleware. Я не стал в статью это всё добавлять ибо не вижу смысла писать такую обвязку, раз нам теперь из коробки всё доступно, но спасибо за замечание.

[mvv-rus]

Главное этот кастомный middleware с проверкой добавить в самое начало пайплайна и следить, чтобы перед ним не добавили какой-нибудь другой middleware.

Можно и не следить, а добавить через реализацию IStartupFilter, регистрируемую в контейнере сервисов.

[m3ta10ph0b]

Да, так можно, но если над проектом работает несколько разработчиков - в какой-то момент времени кто-то может добавить свой IStartupFilter, который будет вызван раньше, так как IStartupFilter-ы создают вложенность почти как middleware. И даже если всех предупредили, что так делать не надо - через пол года придёт новый разработчик и добавит, а на ревью не уследят. Не сказать, что большая проблема, но следить периодически придётся. Функционал, описанный в статье, сломать будет сложнее - для этого придётся явно вызвать app.UseRouting, а это уже умышленное вредительство)