Я, думаю, многие уже слышали о появившихся в .NET 6 Minimal API - легковесной замене контроллеров/MVC. Кто-то уже успел ознакомиться и задался вопросом: "Ваше API в 3 строчки, это, конечно, здорово, но как это будет работать в реальном проекте с сотнями эндпоинтов, кучей фильтров, аттрибутов, расширениями OpenAPI/Swagger и прочих радостях?"
В этой статье я хочу ответить на этот вопрос: пройдемся от основ, преимуществ, недостатков, и закончим нюансами работы и проблемами, которые обязательно возникнут при миграции с контроллеров на Minimal API в крупном проекте.
А забегая чуть вперед: если думаете, стоит ли переводить проект на Mini API, вот вам сразу полезная информация: они могут жить в проекте вместе, причем даже без дублирования инфраструктуры: не обязательно переводить все разом - подробнее под катом.
Бонусом, заменим SwaggerGen на реализацию OpenAPI от Microsoft.
Зачем использовать Minimal API?
Мы с вами, (надеюсь) не гонимся за модными подходами "просто потому что", поэтому для начала разберемся, зачем переходить на Minimal API:
Простота и гибкость.
Контроллеры разработанны под MVC, Mini API разработаны специально под API / REPR паттерн. Это позволяет настроить эндпоинты под нужды и структуру вашего проекта, и минимизирует количество повторяющегося шаблонного кодаПоддержка Microsoft
Референсный eShop уже перешел на Mini API, а по изменениям ASP.NET Core 9 и 10 можно заметить, что в Mini API стабильно добавляют новые возможности - куда активнее, чем для MVC. Во многом, конечно, это обусловлено добавлением функционала, который уже есть в контроллерах, но не всегда. Субъективно, контроллеры движутся в статус легаси. Очень медленно, конечно, вряд ли они станут deprecated в каком-нибудь .Net 11 (скорее примерно в .Net 15 - дам такой прогноз. И то, это для статуса легаси, без выпиливания из фреймворка). И это мое субъективное ощущение: официальных заявлений от Microsoft на эту тему не было, лишь косвенные о развитии Mini API.Схожесть с другими фреймворками
Нам не привыкать к контроллерам, но у большинства других крупных языков - JS (Fastify/Express), Python (Flask, FastAPI), Go (Gin), и так далее, уже давно есть эндпоинты по схожей схеме с MinimalAPI. Во-первых, переходить с языка на язык легче, а во-вторых, это говорит нам о том, что и без контроллеров можно прекрасно жить.Отсутствие рефлексии
Конфигурация эндпоинтов происходит через методы, явно вызывающиеся в вашем коде, а не поиске контроллеров по всему проекту и получению аттрибутов. Это позволяет настраивать проекты более гибко (например, вы не запихнете в аттрибут массив, или значение из конфига), а также из этого следуюет еще 2 плюса:Поддержка NativeAOT
NativeAOT - сейчас тренд в мире .Net, и вряд ли контроллеры получат ее поддержку, в отличии от Mini API, у которых она уже есть. Впрочем, бэкенд - это та область, где NativeAOT может ухудшить производительность. Вообще, это тема для отдельной статьи, но вот вам сравнение, и вот краткое объяснение почему. Но не забываем, что ситуация может измениться - .Net развивается быстро.Улучшенная производительность
Вот и вот вам бенчмарки. Спойлер: разница на несколько процентов по времени выполнения и на десятки процентов по выделенной памяти. В реальности, вероятнее всего бОльшую часть нагрузки будет создавать ваш код, поэтому ждать сильного увеличения RPS не стоит. Но если у вас есть какие-то эндпоинты с десятками и сотнями тысяч RPS, где вы отчаянно боретесь за производительность и каждый вызов GC, перевести их на Mini API может оказаться неплохой идеей, особенно учитывая тренд на улучшения производительности в последних .Net.
Недостатки:
Не весь функционал контроллеров пока реализован
В статье Microsoft можно подробнее посмотреть чего пока нет. Основное - это валидация (решаемо, напишу про это ниже) и нет поддержки View из MVC (но Razor Pages есть)Перенос уже существующих проектов - дни/недели работы
Даже перенести первый эндпоинт для большого проекта может оказаться задачей на денек-другой: из-за необходимости исправлять все ваши фильтры, аттрибуты контроллеров и т.п. Дальше пойдет быстрее, но внимательной работы все равно хватит. Можете попробовать Cursor натравить на это дело - есть вероятность что прокатит.
Итого, мое личное мнение: если начинаете новый проект/микросервис, особенно с прицелом на .Net 10 (или работаете над пока небольшим проектом), переходить стоит. Если у вас большой энтерпрайз проект, все и так работает, а в бэклоге и так куча задач по рефакторингу, на которые менеджеры не дают времени, то можно пока и пожить с контроллерами. Если, конечно, производительность устраивает и NativeAOT не нужен.
Hello World!
Для тех кто не знаком, в этой главе вкратце расскажу, как написать простые эндпоинты с Mini API. Более подробно можно почитать например в примере от Microsoft или статье на хабре.
var app = WebApplication.CreateBuilder(args).Build();
app.MapGet("/", () => "Hello World!");
app.Run();Красиво, правда? Ну ладно, реализовывать эндпоинты мы в Program.cs надеюсь не планируем, поэтому усложняем. Добавлю пример под архитектуру из своей статьи про VSA. Введем интерфейс IEndpoint для удобной регистрации эндпоинтов.
public interface IEndpoint
{
void Register(IEndpointRouteBuilder endpointsBuilder);
}Наши классы эндпоинтов будут реализовывать этот интерфейс. Хотите реализовывать несколько эндпоинтов в классе? Просто переименуйте интерфейс, например, в IEndpoitns(Provider). Minimal API - довольно гибкая штука, реализуйте как это больше подходит к вашему проекту.
Добавим extension для регистрации:
public static class EndpointsHelper
{
public static IEndpointRouteBuilder Register<T>(this IEndpointRouteBuilder endpointsBuilder)
where T : IEndpoint, new()
{
var endpointsProvider = new T();
endpointsProvider.Register(endpointsBuilder);
return endpointsBuilder;
}
}И, например, класс, который будет регистрировать все наши эндпоинты:
public static class EndpointsProvider
{
public static void RegisterAppEndpoints(RouteGroupBuilder endpointsBuilder)
{
endpointsBuilder.Register<GetUserCart>();
}
}Хотя, при желании, никто не мешает пробежаться по Assembly и найти все IEndpoint - как это делается в контроллерах. Но я бы не стал.
И добавим его в Program.cs:
// Все эндпоинты будут начинаться с /api
var endpointsBuilder = app.MapGroup("/api");
EndpointsProvider.RegisterAppEndpoints(endpointsBuilder);Теперь реализуем, сам эндпоинт:
public class GetUserCart : IEndpoint
{
public void Register(IEndpointRouteBuilder endpointsBuilder)
{
endpointsBuilder.MapGet("/user/cart", HandleAsync)
// Аналог аттрибута [Authorize]
.RequireAuthorization()
// Описание эндпоинта для OpenAPI. В контроллерах обычно для этого используют комментарии XML (/// <summary>). Теперь это в коде.
.WithSummary("Search all available platforms.")
// Тэг для OpenAPI. Обычно это имя контроллера.
.WithTags("User");
}
// OpenAPI автоматически сгенерирует описание ответа на основе возвращаемого типа.
private static async Task<QueryableList<UserCartItem>> HandleAsync(int skip, int take, UserContext userContext, ExampleDbContext db, CancellationToken ct)
{
var total = await db.CartItems.CountAsync(x => x.UserId == userContext.UserId, ct);
if (total == 0)
return QueryableList<UserCartItem>.Empty();
var items = await db.CartItems.Where(x => x.UserId == userContext.UserId)
.Select(x => new UserCartItem
{
Id = x.ItemId,
Name = x.Item.Name,
})
.Skip(skip)
.Take(take)
.ToListAsync(ct);
return new QueryableList<UserCartItem>(items, total);
}
}(Я упущу реализацию БД и прочих радостей чтобы не раздувать статью) skip и take будут получены из query string, остальные зависимости зарезолвит DI.
Много skip-take в проекте, хочется вынести в общую модель для удобства использования? Поможет аттрибут [AsParameters]:
private static async Task<QueryableList<UserCartItem>> HandleAsync([AsParameters]PagingQuery paging, UserContext userContext, ExampleDbContext db, CancellationToken ct)
...
public record PagingQuery
{
[FromQuery(Name = "take")]
public int Take { get; init; } = 10;
[FromQuery(Name = "skip")]
public int Skip { get; init; }
}Подробнее о биндинге параметров можно почитать в статье Microsoft.
Движемся дальше.
Заменяем аттрибуты
В Minimal API используется важная концепция - метадата. Это то, что заменит нам атрибуты в контроллерах: добавляем эндпоинту метадату и обрабатываем ее в наших фильтрах.
Забегая вперед: метадата появилась еще до Minimal API, и аттрибуты контроллеров - это тоже метадата, а значит их можно получать одним и тем же кодом.
Например, хотим запретить какой-то эндпоинт в продакшне. Делаем класс:
public class ProhibitInProductionMetadata;Добавляем его в эндпоинт (подсказка - можно даже написать красивые extension):
endpointsBuilder.MapGet("/user/cart", HandleAsync)
.WithMetadata(new ProhibitInProductionMetadata()))А, чтобы реализовать логику, сразу перейдем к фильтрам
Фильтры
Для примера выше реализуем фильтр:
public class ProhibitInProductionFilter(EnvironmentConfig envConfig) : IEndpointFilter
{
public async ValueTask<object?> InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next)
{
var endpoint = context.HttpContext.GetEndpoint();
if (endpoint == null || envConfig.Environment != EnvironmentType.Production)
return await next(context);
// Проверяем наличие метадаты у эндпоинта
var metadata = endpoint.Metadata.GetMetadata<ProhibitInProductionMetadata>();
if (metadata == null)
return await next(context);
// Метадата есть, Production окружение, возвращаем 404
return Results.NotFound();
}
}И сделаем так, чтобы он применялся ко всем эндпоинтам, модифицировав код из введения:
var endpointsBuilder = app.MapGroup("/api")
.AddEndpointFilter<ProhibitInProductionFilter>();
EndpointsProvider.RegisterAppEndpoints(endpointsBuilder);Готово. Вот и познакомились с фильтрами в Minimal API.
Правда, познакомились. Нам теперь не нужно вспоминать каждый раз вот эти все IAuthorizationFilter/IActionFilter/IExceptionFilter и так далее. Весь необходимый функционал можно реализовать наследуя от одного интерфейса.
Пара полезных нюансов:
Как можно заметить из примера выше, AddEndpointFilter() можно применять к одному, группе, или ко всем эндпоинтам - в зависимости от ваших нужд
Переходите с контроллеров? Этот же фильтр можно применить и к контроллерам:
app.MapControllers()
.AddEndpointFilter(new ProhibitInProductionFilter());А, заменив наш ProhibitInProductionMetadata на аттрибут, и добавив его в контроллер, он уже будет у нас в метадате:
var metadata = endpoint.Metadata.GetMetadata<ProhibitInProductionMetadataAttribute>();Отсюда вывод: переделав ваши фильтры на IEndpointFilter, они смогут работать и с контроллерами, и с Mini API одновременно.
Больше деталей в документации.
Middleware
Тут все еще проще - ничего не меняется. Для наглядности пример - реализуем Middleware для логгирования запросов:
public class RequestLoggingMiddleware(RequestDelegate next, ILogger<RequestLoggingMiddleware> log)
{
public async Task InvokeAsync(HttpContext context)
{
var url = context.Request.GetDisplayUrl();
log.LogTrace("Started {RequestId} | Url: {Url}", context.TraceIdentifier, url);
await next(context);
}
}
...
// В Program.cs
app.UseMiddleware<RequestLoggingMiddleware>();Варианты с app.Use() и IMiddleware доступны аналогично
Валидация
А вот тут посложнее: В Minimal API нет ModelState, соответсвенно коробочная валидация контроллеров не работает. Если вы полагаетесь на нее - придется пока переделывать. Если же у вас какой-то свой механизм через фильтры/middleware или просто в коде эндпоинтов - скорее всего получится его адаптировать.
Из коробки валидация появится в .Net 10, так что планируете реализовывать Mini API сразу на .Net 10, то написанное ниже вероятно будет не очень актуально. А пока я расскажу как это можно сделать сейчас:
Допустим, у нас есть такой эндпоинт:
endpointsBuilder.MapPut("/items/create", HandleAsync)
.RequireAuthorization()
.WithTags("Items");
...
// .Net поймет, что CreateItemRequest - это тело запроса, но при желании можно явно пометить аттрибутом
private async Task<IResult> HandleAsync(CreateItemRequest item)
...
public record CreateItemRequest
{
public required string Name { get; init; }
public required int Price { get; init; }
}Можно, конечно, валидировать прямо в HandleAsync()
if (item.Name.Length < 3)
return Results.BadRequest("Item name must be at least 3 characters long.");Хотя тут даже если отправить null в "Name", получим NullReferenceException и 500 ошибку: включенные в проекте nullable reference types не уважаем, непорядок.
Но хорошая новость: FluentValidation, если пользуетесь, совместим с Minimal API. Реализуем для нашего эндпоинта:
public class CreateItemValidator : AbstractValidator<CreateItemRequest>
{
public CreateItemValidator()
{
RuleFor(x => x.Name).NotEmpty().Length(3, 100);
RuleFor(x => x.Price).GreaterThan(0).LessThanOrEqualTo(1000);
}
}
...
// В Program.cs:
builder.Services.AddScoped<IValidator<CreateItemRequest>, CreateItemValidator>();
...
private async Task<IResult> HandleAsync(IValidator<CreateItemRequest> validator, CreateItemRequest item)
{
var validationResult = await validator.ValidateAsync(item);
if (!validationResult.IsValid)
return
Results.ValidationProblem(validationResult.ToDictionary());
...Хотя ключевое слово required при отсутствии поля "name" в body все равно кинет свою 400 ошибку до того, как код дойдет до валидации. Ну да ладно, кейс специфичный и не всем нужен, оставлю так.
Другой подход: MiniValidation, работающий на System.ComponentModel.DataAnnotations, прямо как в контроллерах из коробки. Реализуем:
public record CreateItemRequest
{
[Required, MinLength(3)]
public required string Name { get; init; }
[Required, Range(1, 1000)]
public required int Price { get; init; }
}
...
private async Task<IResult> HandleAsync(CreateItemRequest item)
{
var isValid = MiniValidator.TryValidate(item, out var errors);
if (!isValid)
return Results.ValidationProblem(errors);Главный плюс MiniValidation - он реализует DataAnnotations, а это значит:
Совместимость с текущими контроллерами
В .Net 10 его можно будет просто убрать и заменить коробочным решением.
OpenAPI/Swagger и фильтры
Чуть выше я уже затронул некоторые моменты для OpenAPI, разберем поподробнее
Вообще с .Net 9 Microsoft перешла со SwaggerGen на свой пакет Microsoft.AspNetCore.OpenApi Если вы путаете Swagger(UI/Gen) и OpenAPI (эти понятия были тесно связаны между собой, и нейминг не помогал), то можно глянуть что произошло в этой issue и этой статье.
Вкратце, простыми словами:
SwaggerGen, как и OpenApi от Microsoft, генерируют нам тот самый .json с API спецификацией нашего проекта. Swagger UI - визуализирует этот JSON чтобы можно было удобно тыкаться ручками.
Вместо SwaggerGen теперь рекоммендуется использовать Microsoft.AspNetCore.OpenApi. Но никто не запрещает остаться на SwaggerGen: поддерка MinimalAPI есть. Зачем тогда переходить? В перспективе можно ожидать более качественную реализацию новых функций .Net и протокола OpenAPI. Как показывает опыт, хоть скорее всего так и будет, но это не точно.
Swagger UI все еще можно использовать даже без SwaggerGen
Активно развиваются альтернативы Swagger UI, например Scalar. На хабре уже была статья о нем.
Scalar интригует, но остановимся на пол пути: в примере буду приводить SwaggerGen и переводить его на Microsoft OpenAPI + Swagger UI.
Возьмем пример из головы: допустим, мы хотим отображать OpenAPI определенные хэдеры у конкретных эндпоинтов. Где-то, конечно, подойдет строка с аттрибутом [FromHeaders], но не всегда удобно.
Для привычного "SwaggerGen + Контроллеры" реализация будет выглядеть так:
Добавим аттрибут:
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class)]
public class ApiShowHeadersAttribute(params string[] headers) : Attribute
{
public string[] Headers => headers;
}Реализуем фильтр:
public class ShowHeadersFilter : IOperationFilter
{
public void Apply(OpenApiOperation operation, OperationFilterContext context)
{
// Получаем аттрибут ShowHeadersAttribute из метода контроллера
var headersData = context.MethodInfo.GetCustomAttribute<ApiShowHeadersAttribute>();
if (headersData == null)
return;
operation.Parameters ??= new List<OpenApiParameter>();
foreach (var header in headersData.Headers)
{
// Добавляем описание хэдера в OpenAPI спецификацию
operation.Parameters.Add(new OpenApiParameter
{
Name = header,
In = ParameterLocation.Header,
Required = false,
Schema = new OpenApiSchema() // Можно еще красивую схему придумать
});
}
}
}И добавляем этот фильтр в наш services.AddSwaggerGen(). В OpenAPI спецификации у нас появятся нужные хэдеры.
Теперь реализуем то же самое для Mini API, причем мы переиспользуем фильтр: он будет работать и для контроллеров, и для Mini API
Добавим такую строчку к нашему энпоинту:
endpointsBuilder.MapGet("/user/cart", HandleAsync)
.WithMetadata(new ApiShowHeadersAttribute("X-Custom-Header"))И теперь просто заменяем получение аттрибута в фильтре на получение метадаты:
var headersData = context.ApiDescription.ActionDescriptor.EndpointMetadata
.OfType<ApiShowHeadersAttribute>()
.FirstOrDefault();Готово! Теперь данный фильтр будет работать с контроллерами, и с Minimal API.
Тут можно обнаружить еще один небольшой плюс Minimal API: в отличие от аттрибутов, в метод можно передать наш массив хэдеров из какого-нибудь статического списка или даже конфига при желании: мы больше не ограничены этапом компиляции.
Теперь переделаем фильтр со SwaggerGen на Microsoft OpenApi:
Наш фильтр будет реализовывать не IOperationFilter, а IOpenApiOperationTransformer, при этом изменения в коде минимальны:
// Было:
public class ShowHeadersFilter : IOperationFilter
...
public void Apply(OpenApiOperation operation, OperationFilterContext context)
...
var headersData = context.ApiDescription.ActionDescriptor.EndpointMetadata.OfType<ApiShowHeadersAttribute>().FirstOrDefault();
// Стало:
public class OpenApiShowHeadersFilter : IOpenApiOperationTransformer
...
public async Task TransformAsync(OpenApiOperation operation, OpenApiOperationTransformerContext context, CancellationToken ct)
...
var headersData = context.Description.ActionDescriptor.EndpointMetadata.OfType<ApiShowHeadersAttribute>().FirstOrDefault();Подробнее о трансформерах можно почитать в доке. И поменяем в Program.cs:
// Было:
builder.Services.AddSwaggerGen(c => c.OperationFilter<ShowHeadersFilter>());
...
app.UseSwagger();
app.UseSwaggerUI();
// Стало:
builder.Services.AddOpenApi(c => c.AddOperationTransformer<ShowHeadersFilter>());
...
app.UseSwaggerUI(options => options.SwaggerEndpoint("/openapi/v1.json", "Swagger"));
app.MapOpenApi();Microsoft OpenApi делается с прицелом на Minimal API, однако с контроллерами тоже работает: убедитесь, что на ваших контроллерах есть аттрибут [ApiController]
А описание кодов ответа в Min API можно заменить так:
// Было:
[HttpPut("items/create")
[SwaggerResponse(StatusCodes.Status400BadRequest, Type = typeof(ErrorModel))]
// Стало:
endpointsBuilder.MapPut("/items/create", HandleAsync)
.Produces<ErrorModel>(400);Подробнее, что на что поменялось, можно посмотреть в документации.
Почему-то .Produces недоступен, если хотите навесить его сразу на группу эндпоинтов. Но не беда: это просто метадата, и мы можем сделать так:
var endpointsBuilder = app.MapGroup("/api").WithMetadata(new ProducesResponseTypeMetadata(400, typeof(ErrorModel)))
...Полезно, если у вас стандартизированный ответ с ошибкой (а он, надеюсь, стандартизирован)
Обработка ошибок
В Minimal API есть встроенная обработка ошибок (документация). Можно использовать так:
app.UseExceptionHandler(exceptionHandlerApp =>
{
exceptionHandlerApp.Run(async context =>
{
var exceptionFeature = context.Features.Get<IExceptionHandlerFeature>();
if (exceptionFeature?.Error is ValidationException)
await Results.ValidationProblem([]).ExecuteAsync(context);
else
await Results.Problem().ExecuteAsync(context);
});
});
Впрочем, лично мне это коробочное решение не очень понравилось: оно мне показалось не очень гибким, и оно безконтрольно залоггирует ошибку еще до того, как дойдет до хэндлера - даже если вы ее как-то обработаете.
А под капотом там - обычный Middleware с try catch, поэтому можно так и самим сделать:
public class ExceptionHandlingMiddleware(RequestDelegate next, ILogger<ExceptionHandlingMiddleware> log)
{
public async Task InvokeAsync(HttpContext context)
{
try
{
await next(context);
}
catch (Exception exception)
{
// Ваша обработка тут
}
}
}Но, вне зависимости от вашего выбора, оба варианта (т.к. и там и там Middleware), будут работать и с контроллерами
Кэширование
ResponseCacheAttribute для Minimal API не работает (хотя, подсказка: ничто не мешает добавить его в метадату и написать фильтр для добавления HTTP хэдеров Cache-Control вручную)
Но у нас теперь есть OutputCache: без HTTP, только на уровне приложения. Реализуем:
// В Program.cs:
builder.Services.AddOutputCache();
...
app.UseOutputCache();
// Эндпоинт:
endpointsBuilder.MapGet("/items", HandleAsync)
.CacheOutput(builder =>
{
builder.Expire(TimeSpan.FromSeconds(60));
builder.SetVaryByQuery("*");
});
Теперь, после 1 выполнения, ответ будет закэширован у нас на сервере на 60 секунд.
Эндпоинт с таким кэшом умеет удалять кэш раньше времени при необходимости, кэшировать в Redis и даже имеет resource locking (1ый реквест будет выполняться, а остальные параллельные ждать, пока тот выполнится, чтобы не перегружать сервер) - в общем, штука весьма полезная.
Results/TypedResults
Как и с методами контроллеров Ok(), BadRequest() и т.п., у нас теперь есть (Typed)Results.Ok()/BadRequest().
И, как и с контроллерами, можно их и использовать, а можно и не использовать:
endpointsBuilder.MapGet("/cart/item-plain", HandlePlain);
endpointsBuilder.MapGet("/cart/item-results", HandleResults);
...
private static UserCartItem HandlePlain() => new UserCartItem();
private static Ok<UserCartItem> HandleResults() => TypedResults.Ok(new UserCartItem());
Данные варианты практически идентичны, и OpenAPI/SwaggerGen сам подхватит описание модели ответа.
Но для Results можно еще, в стиле функционального программирования, показать, что у нас возможны разные ответы сервера:
private static Results<Ok<UserCartItem>, NotFound> HandleResults() => TypedResults.Ok(new UserCartItem());Но, как я писал выше про OpenApi, у эндпоинтов есть расширение .Produces(), позволяющее добиться того же результата, причем, при желании глобально
Итого, что же выбрать, Results.Ok() или "сырые" данные? Если у вас уже есть консенсус в контроллерах на эту тему - можно оставить как есть.
Если ответа для вас пока нет, лично мне нравится больше использовать сырые данные + обрабатывать ошибки через Exceptions: зачем привязывать логику обработки событий юзеров к имплементации API, если это особо не дает преимуществ.
Хотя, это больше вкусовщина, ООП против функционального стиля.
Впрочем, если ваш эндпоинт возвращает не просто json-ответ, Results будут полезны в любом случае:
return TypedResults.File(result, "application/x-gzip", $"sitemap-{page}.xml.gz");Итоги
Надеюсь, ничего не забыл, и убедил вас, что MinimalAPI - гибкая и мощная технология, которая прекрасно будет работать как в небоших проектах, так и в больших энтерпрайзах уже сейчас.
Отдельного упоминания заслуживает FastEndpoints - сторонняя альтернатива MVC и Minimal API. Однако, как мне кажется, с развитием Minimal API смысла в ее использовании все меньше
Upd:
Дополнение от @mvv-rus: если нужно погрузиться еще глубже, цикл статей от Andrew Lock про устройство Minimal API под капотом