На дворе 2026 год, а вы всё ещё не используете OpenTelemetry?

Вот как он может упростить жизнь software engineer. Если вам важна observability, стоит знать про OpenTelemetry.

Это vendor-neutral open-source стандарт для инструментирования приложений и сбора telemetry data.

Если проще — речь про:
• Logs
• Traces
• Metrics

Работает ли это с .NET? Да. Для .NET есть несколько библиотек, которые достаточно легко интегрировать в приложение.

Вот простой гайд, с которого можно начать знакомство: https://milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet

👉 @KodBlog

Ваш .NET API отлично работает локально. Но это ещё не значит, что он готов к продакшену.

Перед релизом я проверяю 8 вещей, которые помогают избежать множества проблем в будущем: наблюдаемость, CORS, документацию API, версионирование, хранение данных, обработку ошибок, проверки работоспособности и ограничение частоты запросов.

В статье я разобрал, что важно в каждом пункте, почему это имеет значение и как всё настроить на практике в .NET.

Полная статья: https://mwaseemzakir.substack.com/p/before-your-net-api-goes-to-production

👉 @KodBlog

Когда мне нужна функциональность в реальном времени, я выбираю проверенное решение:

→ SignalR

SignalR позволяет добавить взаимодействие в реальном времени в .NET-приложения. При этом клиент может быть написан на React, Angular или обычном JavaScript.

Вы создаёте класс SignalR Hub. Это центральный компонент приложения, который управляет клиентскими подключениями и обменом сообщениями. Клиенты подключаются к Hub, чтобы отправлять и получать сообщения, поэтому связь может быть двусторонней.

SignalR скрывает детали транспортного механизма. Обычно используется WebSockets, но при необходимости библиотека может переключиться на Server-Sent Events или опрос сервера.

Всё, что нужно для начала: статья.

SignalR определённо входит в число лучших библиотек экосистемы .NET.

👉 @KodBlog

Ваш API входа раскрывает злоумышленникам, у кого есть аккаунт?

Распространённая ошибка: Если email не существует, возвращать «Пользователь не найден». Если пароль неверный, возвращать «Неверные учётные данные».

Это уязвимость, позволяющая перебирать учётные записи. Любой может отправить список email-адресов в ваш API и точно узнать, какие из них зарегистрированы, даже не пытаясь подобрать пароль.

Обычное исправление: всегда возвращать «Неверные учётные данные», независимо от причины ошибки. Хорошее начало. Но есть второй канал утечки, который многие упускают.

Когда пользователя не существует, вы пропускаете проверку пароля и быстро возвращаете ответ. Когда пользователь существует, вы обрабатываете введённый пароль с помощью bcrypt или Argon2, а это занимает ощутимое время.

Сообщение одинаковое. Время ответа разное. Злоумышленник просто измеряет миллисекунды и составляет тот же список зарегистрированных аккаунтов, используя секундомер вместо текста ошибки.

Вот как закрыть эту брешь:

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

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

В дополнение к фиктивному хешированию установите фиксированную минимальную длительность ответа.
Ограничивайте попытки входа по IP и по учётной записи, чтобы атаки по времени становились слишком медленными и невыгодными.

👉 @KodBlog

Если вы используете ИИ-агентов для написания кода, стоит разобраться в архитектурном тестировании.

Вот почему.

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

С помощью архитектурных тестов можно контролировать:
• Направление зависимостей.
• Соглашения об именовании.
• Различные правила проектирования.

Подробное руководство, которое, думаю, вам понравится: читать статью.

Можно даже объяснить агенту правила вашей архитектуры, и он напишет тесты для проверки их соблюдения. Затем достаточно запускать эти тесты в CI, чтобы гораздо быстрее выявлять нарушения.

Добавили бы такую проверку в свой процесс ревью кода?

👉 @KodBlog

Можете найти ошибку в этом фрагменте кода?

Второй пример вставляет 10 000 записей в базу данных в 43 раза быстрее. Откуда такая огромная разница в производительности?

Код в обоих примерах выглядит похоже. Но если понимать, как EF работает под капотом, ответ становится очевидным.

Каждый вызов SaveChanges означает обращение к базе данных. В первом примере для вставки каждой записи выполняется отдельный вызов. И накладные расходы быстро накапливаются…

Вот как правильно решить эту задачу: читать статью.

Лишние запросы к БД — одна из главных причин падения производительности. Не допускайте этой ошибки в своём коде.

👉 @KodBlog

Интерактивные курсы по Git

GitHub запустила cборку онлайн курсов, где можно прокачать навыки работы с Git и GitHub бесплатно. Ветки, коммиты, pull request’ы, Actions и реальные командные сценарии.

Быстрый и лёгкий способ подтянуть базу и перестать гуглить «как откатить коммит» в неподходящий момент.

👉 @KodBlog

17 .NET-библиотек, которые стоит держать под рукой каждому backend-разработчику

Необязательно писать всё с нуля. Вот какие задачи закрывает каждая:

Wolverine — современный mediator и message bus для CQRS со встроенными outbox, retries и планированием.
Dapper — лёгкий micro ORM. Особенно удобен для сложных запросов с большим количеством таблиц и JOIN.
Serilog — структурированное логирование с поддержкой более 40 sinks.
Bogus — генерация реалистичных тестовых данных для разработки и тестирования.
FluentValidation — валидация моделей с помощью понятного fluent-синтаксиса.
Refit — уменьшает количество boilerplate-кода при работе с HTTP API поверх HttpClient.
Health Checks — стандартный механизм проверки состояния сервисов и интеграции с мониторингом и алертами.
Hangfire / Quartz — надёжное выполнение и планирование фоновых задач для сценариев, где обычных hosted services уже недостаточно.
Noda Time — корректная работа с датами, временем и часовыми поясами. Создана Джоном Скитом.
Autofac — DI-контейнер для более сложных сценариев внедрения зависимостей.
MiniProfiler — простой способ быстро найти узкие места в производительности приложения.
FastEndpoints — библиотека для создания Web API на основе REPR-паттерна. Структурированная альтернатива controllers и Minimal APIs.
NSubstitute — простой в настройке mocking framework для тестов.
System.Text.Json — зрелая сериализация JSON и стандартный вариант для современных .NET-приложений.
BenchmarkDotNet — точные бенчмарки производительности .NET-кода.
Scalar — интерактивная документация для API, современная альтернатива Swagger UI.
SignalR — упрощает реализацию real-time функций: чатов, уведомлений, live-обновлений и других сценариев.

А какой инструмент из списка чаще всего используете вы?

👉 @KodBlog

Как создавать фоновые задачи в .NET?

С Quartz достаточно реализовать один интерфейс:

• Создать класс задачи.
• Зарегистрировать его в Quartz.
• Quartz возьмёт на себя планирование и выполнение.

Библиотека полностью поддерживает DI, поэтому можно внедрять нужные сервисы. Задачи выполняются в отдельном scope, что позволяет безопасно внедрять DbContext.

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

Подробное руководство по работе с Quartz в .NET: Читать статью

👉 @KodBlog

Шпаргалка по безопасности .NET

• Устанавливайте для cookies флаг HttpOnly, чтобы клиентские скрипты не могли получить к ним доступ.

• Используйте [Authorize] для контроллеров и .RequireAuthorization() для эндпоинтов, чтобы ограничивать доступ.

• Требуйте надёжные пароли и храните их с помощью специализированных алгоритмов хеширования паролей с уникальной солью. При использовании pepper храните его отдельно от базы данных.

• При аутентификации через cookies проверяйте anti-forgery-токены для запросов, изменяющих состояние, чтобы защищаться от CSRF.

• Обновляйте NuGet-пакеты и используйте инструменты, которые уведомляют об уязвимостях зависимостей.

• Логируйте подозрительную активность и события безопасности, не записывая пароли, токены и другие секреты.

• Для защиты от SSRF проверяйте адреса исходящих запросов, формируемые на основе пользовательского ввода, и ограничивайте доступные назначения.

• Не храните секреты в appsettings.json и репозитории. Используйте предназначенные для этого хранилища секретов.

👉 @KodBlog