Думаешь, хорошо разбираешься в 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

Какой язык более читаемый: C# или Python? Программисты забивают на безопасность?

Обсуждаем эти и другие холиварные темы в шоу Контура «Согласен — не согласен», где сталкиваются два представителя разных IT-профессий, каждый со своим мнением и бэкграундом.

Cмотрите самые горячие выпуски🔥

➡️ С# vs Python-разработчики: какой язык круче
➡️ Джун vs cеньор-разработчики: нужны ли джуны в бигтехе
➡️ Бэкендер vs фронтендер: кто больше страдает
➡️ Программист vs учитель информатики: делать ли программирование обязательным в школе
➡️ Безопасник vs программист: кто должен думать об уязвимости продукта

Новые дискуссии выходят в канале @KonturTech каждые две недели. Будет эмоционально, но с уважением.

16+. Реклама. АО «ПФ «СКБ Контур», ОГРН 1026605606620. 620144, Екатеринбург, ул. Народной Воли, 19А. Erid: 2SDnjcTtt77

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

Задумывались ли вы, как компании вроде 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

Записи действительно являются неизменяемыми.

Если вы знаете, как их определять.

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

Однако, если в записи используется init только для части свойств, то такая запись не является полностью неизменяемой.

Так как же сделать их неизменяемыми?

Используйте позиционные записи.

Такой тип записей компилятор генерирует со свойствами только для инициализации (init-only).

Может показаться, что первый и второй вариант определения идентичны.

Но позвольте развеять это заблуждение.

Первая форма компилируется во вторую, и во втором случае вы можете заменить init на set и тем самым нарушить основную характеристику записей. 🐸

👉 @KodBlog

MongoDB теперь нативно доступен на Azure.

Больше никаких "костылей" между сервисами.

Теперь можно:

> Запускать MongoDB Atlas напрямую из Azure Portal
> Интегрироваться с Azure AI, Databricks, OpenAI — в одном потоке
> Получать единый биллинг по всему стеку

Это будущее cloud-native разработки?

Или тесная интеграция с облаком — палка о двух концах для свободы разработчиков?

Полная разбивка: https://fnf.dev/4n1fsLd ✌️

👉 @KodBlog