Думаешь, хорошо разбираешься в ASP.NET Core middleware?

Этот пост поменяет твой взгляд на перехват HTTP-запросов

Middleware в ASP.NET Core — это компонент, участвующий в конвейере обработки HTTP-запросов и ответов.

Есть три подхода: на делегатах (inline), по соглашению (класс), и через IMiddleware для кастомной логики.

1️⃣Сначала можно использовать метод Use напрямую в конфигурации WebApplication.
Такое middleware на основе делегата выполняется до и после следующего компонента в конвейере.

2️⃣Если логика растёт — вынеси её в отдельный класс middleware по соглашению.
Класс должен иметь конструктор с RequestDelegate и метод InvokeAsync.

3️⃣Либо реализуй интерфейс IMiddleware — это более безопасный, проверяемый компилятором способ.
Зарегистрируй класс IMiddleware в DI-контейнере, и фреймворк сам будет его разрешать.

Но есть важные нюансы:

> Middleware по умолчанию живёт как singleton, поэтому внедряй только singleton-зависимости.
> Если нужны scoped-сервисы — передавай их через параметры InvokeAsync в middleware по соглашению.

Кастомные middleware используют для:

• логирования
• авторизации
• валидации
• модификации ответов

Какой подход к middleware ты используешь и почему? Напиши в комментах 😎

👉 @KodBlog

Скриптинг на C# это круто 😎

Отлично подходит для простых POC и наполнения тестовыми данными, как в этом примере

👉 @KodBlog

Как выполнить на 100% безопасную проверку с отрицанием условия?

Это проще, чем кажется.

Но в чём проблема со "старым" способом?

Оператор != может быть переопределён.

А это может привести к нежелательному поведению.

Зато с использованием отрицательного сопоставления с образцом (negated pattern matching) вы в безопасности.

Отрицательные шаблоны — это одна из новых возможностей, добавленных в C# за последние версии.

Они позволяют исключать определённые шаблоны с помощью ключевого слова not

Иными словами, можно исключать конкретные структуры из сопоставления.

С этим ваш код становится:

> Проще для понимания
> Читаемее

Но учтите:

Значение, к которому применяется выражение сопоставления, должно быть константным.

👉 @KodBlog

Понимание архитектуры микросервисов

Задумывались ли вы, как компании вроде Netflix и Amazon внедряют новые функции с молниеносной скоростью? Секрет может крыться в их технологическом стеке, основанном на микросервисной архитектуре.

В основе микросервисной архитектуры лежит идея разделения приложения на набор небольших, слабо связанных сервисов. Каждый сервис запускается как отдельный процесс, имеет чётко определённый API, располагается в своей кодовой базе, управляется отдельной командой и развёртывается независимо.

Ключевые компоненты микросервисной архитектуры:

1. Load Balancer (балансировщик нагрузки): равномерно распределяет входящий сетевой трафик между серверами.
2. CDN (Content Delivery Network): распределённая сеть серверов, доставляющая контент пользователю на основе его геолокации — ускоряет загрузку страниц.
3. API Gateway: маршрутизирует входящие запросы к нужному микросервису через REST API или другие протоколы.
4. Management (управление): отвечает за мониторинг и координацию микросервисов, обеспечивая их стабильную работу и взаимодействие.
5. Microservices (микросервисы): каждый сервис реализует отдельную функцию, может взаимодействовать с другими через RPC (удалённый вызов процедур) и сам отвечает за хранение данных или состояния.

Преимущества:

✅ Масштабируемость: можно масштабировать только нужные части приложения
✅ Гибкость: каждый микросервис разрабатывается, развёртывается и масштабируется независимо
✅ Устойчивость: сбой одного сервиса не выводит из строя всё приложение
✅ Быстрая доставка: небольшие кодовые базы — более быстрый выпуск новых функций

Недостатки:

❌ Сложность: больше сервисов — выше архитектурная сложность
❌ Согласованность данных: сложно поддерживать целостность данных между сервисами
❌ Сетевые задержки: взаимодействие между сервисами увеличивает время отклика
❌ Обработка ошибок: сложно отследить, где именно произошла ошибка

Микросервисная архитектура — не панацея, но мощный инструмент в арсенале современной разработки.

👉 @KodBlog

Ты, скорее всего, пропустил это улучшение в LINQ

Теперь вместо того чтобы использовать Skip и Take для пропуска и выборки определённого количества элементов из коллекции, можно обойтись только Take.

Начиная с .NET 6, у метода Take появилась новая перегрузка, которая поддерживает ещё одну крутую фичу — диапазоны (Ranges).

А что такое диапазоны?

Они появились в C# 8 и позволяют брать подмножество коллекции с помощью оператора .., задавая начальный и конечный индексы.

Начальный индекс включается, конечный — нет. Оба индекса имеют тип Index.

Один из ключевых плюсов такого подхода — улучшенная производительность, так как под капотом процесс выборки данных может быть оптимизирован.

Но учти: если указать индекс, выходящий за пределы коллекции, будет выброшено исключение IndexOutOfRangeException

👉 @KodBlog

Visual Studio теперь отображает возвращаемые значения методов прямо в коде

Фича появилась в версии 17.12 (выпущена в ноябре).

Я всегда считал, что временные переменные помогают снизить когнитивную нагрузку при работе с возвратами методов, но, похоже, теперь игра изменилась

👉 @KodBlog

Самое раздражающее при отладке C#-кода?

(что может серьёзно замедлить процесс)

Проверка значений в коллекции.

Приходится разворачивать каждый элемент, чтобы посмотреть значения свойств.

Чтобы решить эту проблему, в Visual Studio недавно появилась функция закрепляемых свойств (pinnable properties).

Она позволяет быстро отслеживать нужные свойства.

Чтобы воспользоваться, наведите курсор на свойство и нажмите на иконку закрепления.

См. видео-пример, как это использовать 🕵️‍♀️

👉 @KodBlog

Как сделать систему масштабируемой?

Современные приложения должны справляться с резкими всплесками трафика без сбоев.
Когда один сервер достигает предела, это чревато задержками, ошибками или полной недоступностью.

Есть два основных подхода:

> Вертикальное масштабирование → увеличение ресурсов одного сервера
> Горизонтальное масштабирование → добавление серверов за балансировщиком нагрузки

Для горизонтального масштабирования отличным выбором является YARP — высокопроизводительный обратный прокси от Microsoft для .NET.

В моих тестах с K6 масштабирование до 5 экземпляров API дало прирост:

✅ Время отклика: с 9.68 мс до 4.65 мс
✅ Пропускная способность: с 2260 RPS до 3881 RPS

Настроить YARP и запустить масштабирование можно за считанные минуты.

👉 Подробности: read

👉 @KodBlog

Событийно-ориентированные фоновые задачи в C#

BackgroundWorker — это легковесный инструмент для выполнения асинхронной работы.

Обмен сообщениями между хостом и рабочим происходит через события.

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

LINQPad визуализирует весь процесс :

вызвал Dump() — и данные сразу в окне Results как HTML.

Хочешь, стилизуй вывод с помощью CSS.

👉 Полный скрипт для загрузки доступен по ссылке: https://share.linqpad.net/phkul63s.linq

👉 @KodBlog

#1 ошибка, которую я вижу у .NET-разработчиков — это повсеместное использование null.

Ссылки на null стали причиной множества багов, уязвимостей и сбоев систем.

Вот 4 способа минимизировать использование null в C#:

1. Возвращайте пустое значение из метода

> если возможно, возвращайте пустой список вместо null
> например, используйте Enumerable.Empty<TResult>()

2. Исключайте null с помощью nullable reference types

> представлены в C# 8.0
> заставляют вас явно учитывать возможность null

3. Используйте паттерн Null Object

> объект, реализующий поведение “ничего не делать”
> позволяет избежать проверок на null

4. Используйте оператор null-условия (?.)

> безопасно обращается к свойствам объектов
> если экземпляр равен null, всё выражение вернёт null

Хотите сократить количество сбоев? Попробуйте эти подходы. 👀

👉 @KodBlog