.NET позволяет добавить API rate limiting буквально одной строкой кода.

Это отличный способ контролировать использование вашего приложения.

У такого подхода есть как плюсы, так и минусы, но rate limiting может сделать ваши API более надёжными и безопасными.

Это техника, которая позволяет ограничивать количество запросов к серверу или API.

👉 @KodBlog

Cокровищница для новичков «Coddy Journeys»

Бесплатная онлайн платформа где вы осваиваете программирование, проходя интерактивные маршруты и решаете задачи прямо в браузере.

Учёба превращается в игру, шаг за шагом к своим первым успехам в IT ❤️

👉 @KodBlog

Saga Pattern в .NET

Если вы разрабатываете distributed systems, этот паттерн обязательно стоит знать.

Saga Pattern помогает поддерживать согласованность данных в длительных процессах, которые затрагивают несколько сервисов. В основе Saga лежит координация потока данных и действий между microservices. Такая координация может быть реализована двумя способами:

• Choreography — каждый сервис самостоятельно взаимодействует с другими для достижения общей цели
• Orchestration — центральный компонент координирует действия всех сервисов

Что происходит, если один из шагов Saga завершается ошибкой?

Об этом часто забывают, поскольку большинство разработчиков пишут код в расчёте на happy path. Однако важно заранее продумать обработку ошибок на каждом этапе Saga. Лучший способ обработки будет зависеть от требований бизнеса.

Как реализовать Saga Pattern в .NET: Гайд по реализации Saga Pattern с MassTransit

👉 @KodBlog

Как запускать conditional middleware в .NET?

В динамичном мире web-разработки эффективная обработка входящих HTTP requests имеет ключевое значение для создания надёжных и производительных приложений.

Middleware в .NET играет важную роль в обработке этих requests, выступая связующим звеном между server и application. Один из мощных инструментов ASP.NET Core — app.UseWhen, который позволяет разработчикам условно применять middleware в зависимости от заданных критериев.

Преимущества такого подхода:

• Оптимизация производительности
• Более чистая организация кода
• Выборочное применение middleware

app.UseWhen особенно полезен для приложений со специфическими требованиями к routing или обработке requests. Для простых приложений он может быть избыточен, но в более сложных сценариях способен значительно улучшить производительность и организацию кода.

👉 @KodBlog

Что такое API Gateway?

Самое простое объяснение: это reverse proxy с дополнительными возможностями. API Gateway — это точка входа для ваших backend services и API. Он выступает промежуточным слоем, принимает client requests и направляет их в нужные сервисы.

Основные возможности API Gateway:

• Request routing и composition
• Authentication и Authorization
• Load balancing
• Rate limiting
• Monitoring
• Caching

Проще всего воспринимать его как reverse proxy с дополнительными обязанностями.

Как реализовать API Gateway в .NET: Гайд по API Gateway с YARP

👉 @KodBlog

Не получается разобраться с EF Core queries?

По умолчанию EF Core уже логирует SQL, но вместо реальных значений parameters вы увидите плейсхолдеры ?.

Объедините EnableSensitiveDataLogging() с LogTo(), и получите реальные значения parameters прямо в query — именно в том виде, в котором EF отправляет его в базу данных.

optionsBuilder
    .LogTo(Console.WriteLine)
    .EnableSensitiveDataLogging();

Где это полезно:

• Видны реальные значения parameters вместо ?
• Можно скопировать точный SQL и сразу выполнить его в БД
• Легче обнаружить ситуации, когда EF отправляет неправильный тип или неожиданный NULL

Никогда не включайте это в production. В logs могут попасть чувствительные данные: PII, tokens и keys. Ограничивайте использование через проверку environment, а не через комментарий с напоминанием отключить настройку позже.

👉 @KodBlog

Что должно находиться в слоях Clean Architecture?

Clean Architecture — один из самых распространённых подходов к правильному разделению ответственности. Но на практике разработчики часто размещают компоненты не в тех слоях.

Вот что обычно относится к каждому слою:

1) Domain
• Events
• Entities
• Exceptions
• Repository Interfaces

2) Application
• Services
• Behaviours
• Validators
• Queries / Commands

3) Infrastructure
• Email
• Storage
• Background Jobs
• Database — если нет отдельного слоя Persistence
• Repository Implementations — если нет отдельного слоя Persistence

4) Persistence (опционально, если отделён от Infrastructure)
• Database
• Repository Implementations

5) Presentation
• Controllers
• Middlewares
• View Models или Request Models

👉 @KodBlog

IAsyncActionFilter недооценивают, хотя это очень мощный инструмент.

В ASP.NET Core filters позволяют выполнять собственную логику до или после определённых этапов request pipeline, не затрагивая controllers.

Есть две основные причины использовать их:

1. Переиспользование — одну и ту же логику можно применять к нескольким controllers или actions.
2. Расширяемость — business rules можно полностью вынести из action methods.

IActionFilter выполняется до и после action method и хорошо подходит для лёгких синхронных проверок. IAsyncActionFilter стоит использовать, когда сама проверка требует await, например обращения к базе данных или внешнему service.

Вместо двух отдельных методов «до» и «после», как в синхронной версии, здесь используется один OnActionExecutionAsync, который оборачивает delegate next(). Вызовите next(), чтобы продолжить pipeline, либо не вызывайте его и установите context.Result, чтобы досрочно завершить обработку request.

// EmailVerifiedFilter.cs
internal sealed class EmailVerifiedFilter(
    IUser currentUser,
    IUserService userService) : IAsyncActionFilter
{
    public async Task OnActionExecutionAsync(
        ActionExecutingContext context,
        ActionExecutionDelegate next)
    {
        Guid? userId = currentUser.Id;

        if (userId != null &&
            !await userService.IsEmailVerifiedAsync(userId))
        {
            context.Result = new ForbidResult();
            return;
        }

        await next();
    }
}

// Program.cs
builder.Services.AddScoped<EmailVerifiedFilter>();

// UsersController.cs
[HttpGet("dashboard")]
[ServiceFilter(typeof(EmailVerifiedFilter))]
public IActionResult GetUserDashboard()
{
    ...
}

Где этот подход особенно полезен:

• Проверка подтверждения email или подписки
• Проверка business rules перед выполнением action
• Условная блокировка request без early return в каждом action
• Cross-cutting logic, которую иначе пришлось бы копировать в десятки controllers

Для обычных проверок ролей или policies, не требующих обращения к БД, обычно лучше подходит IAsyncAuthorizationFilter. Он выполняется до model binding, поэтому отклонённому request не придётся проходить ненужный этап привязки данных.

👉 @KodBlog

Как вы рисуете архитектурные диаграммы?

Скорее всего, вы уже знакомы с одним из самых популярных подходов — UML. Но есть и другой вариант — C4 Model.

C4 включает четыре уровня представления архитектуры:

• System Context Diagram
• Container Diagram
• Component Diagram
• Code Diagram

Это лёгкий и понятный подход к визуализации архитектуры программных систем. Создатель C4 Model Simon Brown также выпустил книгу по этому подходу — её тоже стоит посмотреть.

Хотите подробнее разобраться в C4 Model? Начать можно с этой статьи: https://milanjovanovic.tech/blog/visualize-your-software-architecture-with-the-c4-model

👉 @KodBlog

6 ошибок в EF Core queries, которые кажутся безобидными в development, но дорого обходятся в production:

• Фильтры, которые не позволяют эффективно использовать indexes
• Загрузка целых entities, когда нужны всего несколько columns
• Result sets, которые растут без каких-либо ограничений
• Загрузка связанных данных, приводящая к N+1 queries или огромным JOIN

Буферизация тысяч строк, когда данные можно обрабатывать через streaming
Tracking entities, которые вы не собираетесь обновлять

В статье каждый пункт разобран на примерах: компромиссы разных подходов и то, что стоит проверять в первую очередь, когда EF Core endpoint начинает тормозить.

Полная статья здесь

👉 @KodBlog

Одна из самых крутых возможностей .NET, о которой почти никто не говорит:

→ Channels

Найти их можно в namespace System.Threading.Channels.
Channels позволяют организовать асинхронный обмен сообщениями с помощью простого C#-кода. Они предоставляют два основных API:

• для записи сообщений в channel
• для асинхронного чтения сообщений из channel

В background можно запустить worker, который будет забирать сообщения из channel и отправлять их на дальнейшую обработку.

Например, на основе Channels можно реализовать простой in-memory message bus — разумеется, со всеми ограничениями такого подхода.

Пример реализации: https://milanjovanovic.tech/blog/lightweight-in-memory-message-bus-using-dotnet-channels

👉 @KodBlog

Нужно получить ID авторизованного пользователя в Web API?
(При условии, что User ID был добавлен как claim при генерации token.)

✔️ Создайте интерфейс IUser
✔️ Реализуйте его для получения ID из claims
✔️ Зарегистрируйте зависимости
✔️ Внедрите IUser и получайте ID пользователя в нужном месте приложения

👉 @KodBlog

Я встречаю этот code smell почти в каждом production-коде, который приходится разбирать.

→ Magic numbers и magic strings.

Главная проблема таких значений — отсутствие смысла. Это просто произвольное число или строка, из которых непонятно, что именно они означают. Из-за этого код сложнее понимать и проще сломать. Что разработчики могут сделать, чтобы добавить смысл?

Мой предпочтительный вариант — вынести значение в config или использовать enum. То есть дать magic number или string понятное имя.

Имя уже объясняет намерение кода и делает его гораздо проще для понимания. Это лишь один из способов сделать код чище.

Сегодня Clean Code Sunday, поэтому вот ещё 5 советов по рефакторингу C#: 5 Awesome C# Refactoring Tips

👉 @KodBlog

Clean Code — это не про то, чтобы писать больше кода.

Это про то, чтобы делать код понятнее, проще для тестирования и поддержки. Вот 5 практических советов по Clean Code для .NET-разработчиков:

1/ Давайте понятные имена
Код должен объяснять себя сам и не требовать лишних комментариев.

2/ Старайтесь не возвращать null
Так можно сократить количество постоянных null checks и снизить риск NullReferenceException.

3/ Делайте классы и методы небольшими
Разделяйте ответственности, чтобы код было проще понимать, тестировать и поддерживать.

4/ Не изобретайте велосипед
Используйте готовые abstractions и libraries из .NET вместо того, чтобы заново решать уже решённые задачи.

5/ Используйте подходящие инструменты и IDE
Освойте возможности своей IDE, а для единообразия между проектами используйте .editorconfig и общие .props файлы.

👉 @KodBlog

Распространённая ошибка в software architecture, которую я часто встречаю:

→ Код организован без учёта бизнес-задач и частоты изменений.

К счастью, Vertical Slice Architecture (VSA) решает эту проблему довольно просто. Вместо разделения приложения на горизонтальные layers, VSA организует код вокруг конкретных features или use cases.

Почему это важно?

• Такой подход даёт несколько преимуществ:
• Повышает cohesion
• Упрощает поддержку
• Снижает общую сложность
• Фокусирует код на business logic

Вот с чего можно начать: https://milanjovanovic.tech/blog/vertical-slice-architecture-structuring-vertical-slices

👉 @KodBlog