HttpClientFactory в ASP,NET Core: убираем таймауты и «умирающие» сокеты!

Частая проблема в сервисах такая: запросов становится больше, а внешнее API начинает отвечать дольше. В какой-то момент появляются случайные таймауты, хотя код «вроде простой».

Обычно это выглядит так:

public async Task<string> LoadOrdersAsync(string url)
{
    using var client = new HttpClient();
    return await client.GetStringAsync(url);
}

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

В ASP.NET Core лучше один раз настроить клиент через IHttpClientFactory и брать его из DI.

using System.Net.Http;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpClient("orders", client =>
{
    client.BaseAddress = new Uri("https://api.example.com/");
    client.Timeout = TimeSpan.FromSeconds(5);
});

Сервис регистрируем отдельно, чтобы использовать настроенный клиент внутри бизнес-логики.

builder.Services.AddScoped<OrderService>();

var app = builder.Build();
app.Run();

Теперь сам сервис. Через фабрику получаем именованный клиент и выполняем запрос.

public sealed class OrderService
{
    private readonly IHttpClientFactory _factory;

    public OrderService(IHttpClientFactory factory)
    {
        _factory = factory;
    }

    public async Task<string> LoadOrdersAsync()
    {
        var client = _factory.CreateClient("orders");
        return await client.GetStringAsync("orders/today");
    }
}

Так соединения используются повторно, а поведение под нагрузкой становится заметно ровнее.

🔥 В итоге ты убираешь класс случайных сетевых сбоев и получаешь более предсказуемый прод.

➡️ C# Ready| #практика

FlowchartAI — это бесплатный AI-генератор блок-схем, который из текста или кода автоматически строит диаграмму. Он анализирует твой ввод (описание процесса/алгоритма или код) и превращает его в визуальную блок-схему, которую можно смотреть прямо в браузере без регистрации.

📌 Оставляю ссылочку: flowchartai.org

➡️ C# Ready| #практика

Почему async void почти всегда проблема?

С async Task вызывающий код может сделать await и нормально поймать исключение. С async void такого пути нет.

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

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

static async Task SaveAsync()
{
    await Task.Delay(100);
}

await SaveAsync();

🔥 Итог: в обычном коде используй async Task или async Task<T>. async void оставляй только для событий.

➡️ C# Ready | #совет

📂 Коротко про HTTPS!

HTTPS — это HTTP с защитой. Он шифрует данные между браузером и сервером, поэтому их сложно перехватить и прочитать.

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

Сохрани, чтобы быстро вспоминать, что значит https://

➡️ C# Ready | #ресурс

❤️ Нашёл крутую статью про оптимизацию рендера в MonoGame!

В этой статье:
• Как устроить слои и батчи, чтобы сократить число draw call.
• Как использовать инстансинг для повторяющихся элементов персонажа.
• Как измерять прирост производительности после изменений.

🔊 Продолжай читать на Habr!

➡️ C# Ready | #статья

int.TryParse в C#: перестаём падать на пользовательском вводе!

Пользователь вводит число в поле, и всё работает до первого «abc» или пустой строки. После этого приложение ловит исключение и ты тратишь время на разбор банального кейса.

Часто пишут так:

Console.Write("Введите возраст: ");
string input = Console.ReadLine()!;
int age = int.Parse(input);

Console.WriteLine($"Возраст: {age}");

int.Parse хорош, когда формат уже гарантирован. Для пользовательского ввода безопаснее использовать int.TryParse.

Console.Write("Введите возраст: ");
string? input = Console.ReadLine();

if (int.TryParse(input, out int age))
{
    Console.WriteLine($"Возраст: {age}");
}
else
{
    Console.WriteLine("Некорректный ввод. Введите целое число.");
}

Теперь программа не падает, а спокойно обрабатывает ошибку и продолжает работу.

🔥 В итоге ты убираешь лишние исключения и получаешь предсказуемое поведение на реальных данных.

➡️ C# Ready | #практика

👐 freeCodeCamp Foundational C#— бесплатная учебная программа, сделанные чтобы дать крепкую базу по C#!

Внутри — обучение через материалы Microsoft Learn + проверки знаний на стороне freeCodeCamp: ты пройдёшь основы языка (переменные, типы данных, управляющие конструкции) и базовые принципы ООП

📌 Оставляю ссылочку: freecodecamp.org

➡️ C# Ready | #ресурс

☕️ Нашёл полезный материал на Хабре — конкретные NuGet-пакеты для повседневной разработки!

В этой статье:
• Какие пакеты реально экономят время в типовых задачах.
• Где пакет уместен в проде, а где лучше остаться на стандартном API.
• Как оценивать риски новой зависимости перед подключением.

🔊 Продолжай читать на Habr!

➡️ C# Ready | #статья

Почему async void приводит к потерянным ошибкам?

Иногда хочется быстро сделать асинхронный метод и поставить async void. Сначала всё выглядит нормально, но при ошибке вызывающий код уже не может корректно обработать исключение.

Поэтому баги всплывают позже и разбор занимает больше времени.

Вот как обычно выглядит такая ситуация:

static async void ProcessOrderAsync(int id)
{
    await Task.Delay(100);
    throw new InvalidOperationException($"Order {id} failed");
}

ProcessOrderAsync(42);
Console.WriteLine("Дальше код идёт как будто всё хорошо");

Проблема в том, что при async void вызывающий код не может дождаться завершения метода. По этой причине ошибка теряет контекст и в логах часто выглядит случайной.

Надёжнее вернуть Task и явно дождаться выполнения:

static async Task ProcessOrderAsync(int id)
{
    await Task.Delay(100);
    throw new InvalidOperationException($"Order {id} failed");
}

try
{
    await ProcessOrderAsync(42);
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

Теперь поведение предсказуемо. Ты сразу видишь точку ошибки и можешь обработать её в нужном месте.

🔥 В обычном коде используйте async Task. async void оставляйте только для обработчиков событий.

➡️ C# Ready | #практика

Как убрать «лес» вложенных `if` из метода?

Часто вся валидация и проверки прав зашиваются внутрь одной большой конструкции, и тело метода уезжает вправо на пол-экрана:

void ProcessOrder(Order order)
{
    if (order != null)
    {
        if (order.IsPaid)
        {
            if (!order.IsCancelled)
            {
                Ship(order);
            }
        }
    }
}

С guard-условиями (ранними выходами) проверки поднимаем в начало, а дальше оставляем только «нормальный путь»:

void ProcessOrder(Order order)
{
    if (order is null) return;
    if (!order.IsPaid) return;
    if (order.IsCancelled) return;

    Ship(order);
}

Метод читается сверху вниз как список требований, а основная логика не утопает во вложениях. Такой подход хорошо заходит для валидаций, проверок прав, preconditions в сервисах и хендлерах.

🔥 Меньше вложенности, легче читать диффы и гораздо проще добавлять новые условия.

➡️ C# Ready | #совет

❤️ Andrew Lock — .NET Escapades — блог и персональный сайт для .NET-разработчиков!

Технический блог от опытного .NET разработчика и Microsoft MVP, где автор делится глубокими практическими заметками, гайдами и идеями по современному разработку с ASP.NET Core, C#, .NET Core/NET 10 и связанным инструментам.

📌 Оставляю ссылочку: andrewlock.net

➡️ C# Ready | #ресурс