Швидкий та надійний бекенд на C# з ASP.NET Core, EF Core та SignalR

Зауважте: коли ваш REST API на Node.js або Python починає гальмувати вже на тисячі запитів за секунду, а синхронні звернення до PostgreSQL перетворюють latency на російську рулетку — пора поглянути на платформу з передбачуваною продуктивністю. ASP.NET Core на Kestrel легко видає 50–80 тис. RPS на одному ядрі, і це не маркетинг, а реальні цифри Microsoft Docs: ASP.NET Core performance benchmarks. Ми переписували десятки бекендів з Node.js та Python на C# — продуктивність зростала в 3–5 разів при збереженні архітектури.

C# обирають не лише за швидкість. Сувора типізація, вбудований DI, OpenAPI з коробки та багата екосистема NuGet знижують вартість володіння. Якщо в проєкті вже є WPF-клієнт або Blazor-інтерфейс, монорепо на одній мові усуває дублювання бізнес-логіки. Ми працюємо з .NET понад 10 років і реалізували понад 50 проєктів: від highload API до корпоративних порталів з Active Directory.

Результат розробки включає:

• REST/GraphQL API з автоматичною OpenAPI-специфікацією
• Аутентифікацію через JWT, Azure AD або IdentityServer
• Фонові завдання (Hangfire, IHostedService)
• Real-time сповіщення (SignalR)
• CI/CD з Docker та оркестрацією
• Повну документацію та навчання команди

Коли .NET незамінний

Enterprise-проєкти з тисячами RPS, інтеграція з Active Directory/Azure AD, вимоги до транзакційної консистентності — це зона відповідальності .NET. Якщо ваша команда вже знає C#, вибір очевидний. Навіть для невеликих проєктів ASP.NET Core Minimal API дозволяє стартувати без зайвого коду.

Як ми проєктуємо бекенд на C#?

Нижче — реальні фрагменти коду, які пройшли code review і працюють в production.

Minimal API та JWT-аутентифікація

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<AppDbContext>(opt =>
    opt.UseNpgsql(builder.Configuration.GetConnectionString("Default")));

builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(opt =>
    {
        opt.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = builder.Configuration["Jwt:Issuer"],
            ValidateAudience = false,
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Secret"]!))
        };
    });

var app = builder.Build();

app.MapGet("/users/{id:int}", async (int id, IUserService svc) =>
    await svc.GetByIdAsync(id) is { } user
        ? Results.Ok(user)
        : Results.NotFound());

app.MapPost("/users", async (CreateUserDto dto, IUserService svc) =>
{
    var user = await svc.CreateAsync(dto);
    return Results.Created($"/users/{user.Id}", user);
});

app.Run();

Цей код — стандартний скелет production-сервісу. Для складних проєктів ми використовуємо Vertical Slice Architecture з MediatR, що дозволяє тримати кожен сценарій ізольованим.

EF Core чи Dapper? Порівняння в таблиці

У наших проєктах ми часто комбінуємо обидва підходи: EF Core для стандартних запитів, Dapper — для важкої звітності. Це дає до 40% зниження витрат на інфраструктуру.

Output Cache та фонові завдання

builder.Services.AddOutputCache(opt =>
{
    opt.AddPolicy("products", p => p.Expire(TimeSpan.FromMinutes(10)).Tag("products"));
});

app.MapGet("/products", async (IProductRepo repo) => await repo.GetAllAsync())
   .CacheOutput("products");

app.MapPost("/products", async (CreateProductDto dto, IOutputCacheStore cache, ...) =>
{
    var product = await svc.CreateAsync(dto);
    await cache.EvictByTagAsync("products", CancellationToken.None);
    return Results.Created($"/products/{product.Id}", product);
});

Output Cache — вбудоване рішення починаючи з .NET 8. Для фонових завдань використовуємо IHostedService або Hangfire, залежно від складності черги.

Деплой та Health Checks

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyApi.csproj", "."]
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .
ENV ASPNETCORE_URLS=http://+:8080
ENV ASPNETCORE_ENVIRONMENT=Production
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApi.dll"]

Health checks для оркестраторів:

builder.Services.AddHealthChecks()
    .AddNpgsql(connStr, name: "postgres")
    .AddRedis(redisConn, name: "redis");

app.MapHealthChecks("/health/live", new HealthCheckOptions { Predicate = _ => false });
app.MapHealthChecks("/health/ready");

Налаштування JWT в ASP.NET Core

1. Встановіть пакет Microsoft.AspNetCore.Authentication.JwtBearer.
2. У Program.cs додайте AddAuthentication з параметрами: ValidIssuer, ValidAudience, IssuerSigningKey.
3. Налаштуйте авторизацію через AddAuthorization з політиками.
4. Застосуйте middleware app.UseAuthentication(); та app.UseAuthorization();.

Приклад конфігурації наведено вище. В production ми додаємо Refresh Tokens та використовуємо IdentityServer для централізованого управління.

Типові помилки при розробці на ASP.NET Core

• N+1 запит в EF Core — використовуйте .Include() або проекції через .Select().
• Відсутність async/await в I/O операціях — блокування потоків різко знижує пропускну здатність.
• Синхронна робота з хешами паролів — bcrypt або PBKDF2 обов'язкові.
• Ігнорування middleware pipeline — порядок реєстрації middleware критичний.

Що входить у розробку?

Ми надаємо повну документацію по API (Swagger), доступ до вихідного коду та навчання вашої команди.

Оцінка термінів розробки

Простий REST API (10–15 ендпоінтів, одна БД, JWT): 5–8 робочих днів. Повноцінний сервіс з ролями, фоновими завданнями, SignalR та CI/CD: 3–5 тижнів. Міграція з .NET Framework на .NET Core оцінюється окремо після аудиту коду — зазвичай займає 2–6 тижнів.

Обговоріть ваш проєкт з нашим архітектором: напишіть нам з коротким описом задачі — ми оцінимо терміни та вартість за 1–2 робочих дні. Зв'яжіться з нами для консультації та замовте оцінку вашого проєкту вже сьогодні. Ми гарантуємо якість коду та надаємо офіційну гарантію на 3 місяці.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.