Как создать собственную социальную сеть на .NET

Это отличный проект для самостоятельной реализации.

Базовая реализация платформы может включать следующие сущности:

↳ Пользователи

↳ Посты и категории

↳ Лайки и комментарии

↳ Лента

↳ Уведомления

Рассмотрим реальный кейс:

Пользователь открывает сайт соцсети и видит:

↳ Ленту с актуальными постами

↳ Свои собственные публикации

↳ Уведомления о новых постах, комментариях и лайках к интересующим его записям

Типичное frontend-приложение делает три отдельных запроса к серверу:

Получение ленты

GET /api/feed?userId=1&count=10

Получение уведомлений

GET /api/notifications?userId=1&count=10

Получение постов пользователя

GET /api/users/1/posts?count=10

У этой реализации два ключевых недостатка:

Клиенту приходится делать три отдельных запроса к серверу

Клиенты получают все поля, которые возвращает сервер. Для веба это приемлемо, но для мобильных приложений — избыточно и может замедлять работу

Решение — GraphQL

GraphQL был создан как альтернатива REST, чтобы решить эти проблемы.

Hot Chocolate это самый эффективный и функциональный open-source GraphQL-сервер в экосистеме .NET. Он позволяет легко строить масштабируемые GraphQL API и шлюзы.

Преимущества Hot Chocolate по сравнению с REST API:

Клиент сам выбирает, какие поля ему нужны — никакого overfetch/underfetch
Все данные можно запросить одним запросом, без лишних round-trip’ов
Автогенерация документации, генерация кода и автодополнение в IDE синхронизируют frontend и backend
Встроенные фильтрация, сортировка и пагинация — middleware всё берёт на себя, причём делает это лучше и проще, чем OData
Интерфейс Nitro GraphQL позволяет визуально исследовать типы, собирать запросы и тестировать их за секунды

Я использую Hot Chocolate GraphQL в продакшене уже более трёх лет, и это сильно прокачало мои подходы к построению API.

Автор собрал простую реализацию социальной сети на базе Hot Chocolate GraphQL, и сегодня поделился пошаговой инструкцией с разработчиками, как сделать это правильно с учётом best practices.

Исходный код доступен бесплатно.

@KodBlog

🇷🇺 Разбираешься в радиочипах, оптике и связи? Забери до 1 000 000 рублей за свои инженерные навыки на турнире «Дронкон» 🇷🇺

«Сталинские Соколы» открывают регистрацию на 4-й Всероссийский турнир «Дронкон», который пройдет с 22 по 26 августа.

Турнир пройдет по направлению:
- Инженерное дело: навыки программирования, сборка электронного оборудования, беспроводная связь, оптические системы + стратегия «Битва Дронов»;

Призовой фонд для победителей:
🥇место – 1 000 000 рублей
🥈место – 700 000 рублей
🥉место – 500 000 рублей
Награда за 4-8 места - 100 000 рублей

Пройди заочный онлайн-этап и получи путевку на очный этап турнира в Республику Татарстан!
Перелет, питание, проживание - за счет организаторов.

🇷🇺 Подать заявку и узнать подробности 🇷🇺

Создавать новый HttpClient для каждого запроса — не решение.

HttpClient владеет пулом соединений. Если постоянно его освобождать (Dispose), вы будете постоянно пересоздавать соединения и расходовать порты.

Используйте один из следующих вариантов:

- долгоживущий HttpClient + PooledConnectionLifetime;
- недолгоживущие экземпляры HttpClient, создаваемые через IHttpClientFactory.

https://learn.microsoft.com/ru-ru/dotnet/fundamentals/networking/http/httpclient-guidelines

@KodBlog

Инсайд: Я думал, что довольно хорошо знаю PostgreSQL, пока не наткнулся на это.

Оказывается, PostgreSQL способен заменить гораздо больше, чем просто базу данных:

* очереди;
* cron-задачи;
* Redis;
* MongoDB;
* векторные базы данных;
* журналы аудита;
* и даже некоторые сценарии использования Kafka.

Я не говорю, что нужно заменить Postgres'ом каждый инструмент в вашем стеке.

Но мне кажется, что большинство стартапов начинают использовать Redis, Kafka, MongoDB и ещё десяток других сервисов гораздо раньше, чем в них действительно возникает необходимость.

Определённо стоит прочитать, если вы разрабатываете backend-системы. Этот материал заставил меня пересмотреть многие свои представления.

@KodBlog

Совет по .NET MAUI: перестаньте каждый раз проверять текущую тему приложения, когда нужно получить цвет.
AppThemeBinding позволяет XAML автоматически выбирать ресурсы для светлой и тёмной темы, а также обновляет их при смене системной темы во время работы приложения.

Меньше кода для обработки тем. Меньше ситуаций в духе: «Почему в тёмной теме это вообще невозможно прочитать?»

@KodBlog

Запомни: Монолит ≠ Модульный монолит ≠ Микросервисы

Многие команды думают, что путь выглядит так:
Монолит → Микросервисы

Но между ними есть важный этап, который многие пропускают... Модульный монолит.

Вот самый простой способ запомнить разницу:

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

Простая шпаргалка 👇
✅ Монолит = одно приложение
✅ Модульный монолит = одно приложение, много модулей
✅ Микросервисы = множество независимых приложений

Когда использовать каждый подход?

🔹 Монолит
стартапы и MVP;
небольшие команды;
быстрая разработка;
простое развёртывание.

🔹 Модульный монолит
растущие приложения;
команды, которым нужна чистая архитектура без сложности распределённых систем;
проще тестировать, сопровождать и развивать.

🔹 Микросервисы
большие инженерные команды;
независимое развёртывание сервисов;
разные требования к масштабированию отдельных доменов;
высокая доступность и масштабируемость организации.

Самое распространённое заблуждение. Микросервисы не становятся автоматически лучшим выбором.
Они привносят распределённые транзакции, сетевые задержки, обнаружение сервисов (service discovery), наблюдаемость (observability), версионирование, пайплайны развёртывания и дополнительные операционные издержки.

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

Фраза, которую стоит запомнить

Монолит = простота
Модульный монолит = организованность
Микросервисы = независимость

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

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

@KodBlog

Claude Code постоянно добавлял слой Repository, хотя я его об этом не просил.

Я просил реализовать один endpoint в .NET API. В ответ получал интерфейс репозитория, профиль AutoMapper и структуру папок из чьего-то другого проекта. Код был вполне нормальный. Просто не мой.

Проблема не в недостатке знаний. Claude начинает каждую сессию, ничего не зная о вашем репозитории, поэтому заполняет пробелы самым распространённым вариантом, который встречал в .NET. Controllers, Repositories, AutoMapper.

Я снова и снова расплачивался за это временем на code review. Одни и те же правки, сессию за сессией, потому что всё, что я объяснял, не сохранялось до следующего раза.

Решение — один Markdown-файл в корне репозитория. Claude Code автоматически загружает его в начале каждой сессии, ещё до вашего первого запроса.

В моём файле описаны пять вещей: стек с точными версиями, структура проекта и зоны ответственности каждого слоя, команды для сборки, тестов и миграций, используемые мной паттерны (например, records для DTO и тип Result для обработки ошибок), а также паттерны, которые он не должен предлагать никогда.

Именно последний раздел делает всю работу. Фраза «Никогда не предлагай AutoMapper, используй явное маппирование» кажется мелочью, пока не понимаешь, что она делает: она блокирует неправильное поведение по умолчанию ещё до того, как Claude пойдёт по этому пути. Предотвратить неверный дефолтный выбор гораздо дешевле, чем потом проверять код и откатывать изменения.

Теперь тот же самый однострочный запрос приводит к созданию команды, валидатора и обработчика именно в тех папках, где им и место. Более того, перед тем как сообщить, что задача выполнена, Claude даже запускает тесты.

Файл, показанный на изображении, — это базовый шаблон, который я добавляю в каждый новый .NET-проект. Скопируйте его, замените раздел со стеком на свой и удалите всё, с чем не согласны. Он будет работать только в том случае, если описывает то, как строите проект вы, а не то, как это делаю я.

@KodBlog

Перестань просто читать книги по системному дизайну и начни тестировать архитектуры на практике (с помощью Chaos Engineering) — это казалось невозможным без огромных трат на AWS.

Но эта платформа, которая уже 2 года работает в продакшене, 100% бесплатна и с открытым кодом.

Познакомьтесь с Dinamos.

Представьте, что вы симулируете инфраструктуру WhatsApp или продажу билетов на грандиозное шоу.
В Dinamos вы загружаете готовые сценарии, видите запросы, падающие на балансировщик нагрузки, и в реальном времени через «Золотые сигналы» (Golden Signals) обнаруживаете узкие места в очереди сообщений (Message Bus).

И вы можете поэкспериментировать с Chaos Engineering.
Можете намеренно добавить задержки или просто «убить» узел в своей инфраструктуре, чтобы увидеть, как система поведёт себя под нагрузкой и сможет ли она масштабироваться автоматически. На практике — без лишних сложностей.

Готовитесь к System Design интервью?
В Dinamos есть симулятор на базе фреймворка System Design Canvas. Вы рисуете схему архитектуры, записываете голосовое объяснение своего решения, а ИИ оценивает ваш ответ, подсвечивая сильные стороны и указывая, что требовало лучшего обоснования. Это бесплатный тьютор.

Проект уже 2 года развивается вместе с комьюнити. Уроки охватывают всё — от Кеширования до теорем CAP / PACELC.
И всё двуязычно (PT/EN): можете прочитать концепцию на португальском и мгновенно переключиться на английский, чтобы выучить точные термины, используемые на международном рынке.

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

http://dinamos.net это Open Source!

@KodBlog

НОВИНКА: Устойчивые функции (Durable Functions) в PostgreSQL

pg_durable — это расширение PostgreSQL. Состояние рабочего процесса, очередь, повторные попытки и восстановление хранятся в Postgres, и оно использует устойчивость Postgres / высокую доступность / резервное копирование / восстановление.

https://techcommunity.microsoft.com/blog/adforpostgresql/introducing-durable-functions-in-postgresql/4526821

@KodBlog

Ваше приложение запускается без ошибок.

Затем приходит первый настоящий запрос.

Он пытается вызвать GitHub, отправить email, подключиться к сервису или использовать флаг функции.

И только тогда вы узнаёте, что одно значение конфигурации отсутствует или неверно.

Плохой URL.
Пустой токен.
Отсутствующая настройка.

Приложение никогда не было готово к запуску.

Оно просто об этом не сообщило.

ASP.NET Core предоставляет строго типизированную конфигурацию через паттерн Options. Но привязка значений к классу — это только часть работы.

Вам также нужно знать, что эти значения валидны.

И здесь может помочь FluentValidation.

Вместо добавления простых правил в класс настроек, вы можете хранить валидацию в отдельном валидаторе и чётко описать реальные правила:

→ Обязательное значение должно существовать
→ URL должен быть валидным
→ Одна настройка может зависеть от другой
→ Пользовательские проверки можно тестировать независимо

Затем добавьте валидацию при запуске.

Теперь, если конфигурация неверна, приложение падает сразу при старте.

Именно это нужно в контейнере, CI-пайплайне или новом деплое.

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

@KodBlog

У твоей очереди нет тормозов.

Если производители добавляют задачи быстрее, чем потребители успевают их обрабатывать, безграничная очередь — это просто отсроченная боль.

Пятничный .NET-совет: используйте ограниченный Channel<t>.

Когда он заполняется, вы выбираете, что делать: ждать, отбрасывать или падать с ошибкой.</t>

https://learn.microsoft.com/ru-ru/dotnet/core/extensions/channels

@KodBlog

Microsoft выпустила почти 100 готовых skills для AI-агентов, работающих с .NET

Microsoft без громких анонсов опубликовала набор из 99 готовых skills для AI-агентов, предназначенных для работы с .NET. Все они доступны в открытом доступе и могут использоваться в таких инструментах, как Claude Code, Codex, GitHub Copilot и Cursor.

Skills размещены в репозитории dotnet/skills и сгруппированы в 14 плагинов, включающих около 95 специализированных сценариев. Каждый skill представляет собой набор инструкций, который AI-агент автоматически загружает только при выполнении соответствующей задачи.

Среди наиболее полезных плагинов:
dotnet-data — помогает оптимизировать запросы EF Core, выявляет проблемы N+1, корректирует режимы отслеживания (tracking) и устраняет типичные узкие места производительности.
dotnet-test — крупнейший плагин, содержащий 22 skills для запуска, фильтрации и миграции тестов между различными тестовыми фреймворками.
dotnet-upgrade — автоматизирует миграцию проектов с .NET 8 на .NET 10 и включает поддержку nullable reference types.
dotnet-aspnet — предназначен для создания Web API и endpoints загрузки файлов с использованием Minimal APIs.
dotnet-ai — позволяет создавать, отлаживать и тестировать MCP-серверы с помощью C# SDK.

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

Для подобных сценариев разработчикам предлагается создавать собственные skills, которые описывают принятые в проекте конвенции и позволяют AI-агентам учитывать специфику конкретной кодовой базы.
Подробное руководство по созданию пользовательских skills, настройке Skill Creator и работе с репозиторием dotnet/skills опубликовано автором статьи на его сайте.

@KodBlog

Ваш фоновый цикл, вероятно, не нуждается в Task.Delay.

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

Просто помните: один потребитель за раз, диспоозьте его, передавайте токен.

Ссылка на документацию ниже.

https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.periodictimer?view=net-10.0

@KodBlog

Почему используется Event-Driven Architecture?

Представьте систему с двумя микросервисами:
1) payments
2) emails

Когда платеж подтверждён, payments вызывает emails, чтобы отправить чек.

Но приложение растёт. Теперь нужно ещё сгенерировать счёт, обновить метрики и отправить уведомление.

Чтобы это сделать, payments начинает вызывать каждый из них.

Каждая новая функциональность добавляет ещё один вызов. Со временем такой поток становится всё сложнее поддерживать.

Event-Driven Architecture предлагает другой способ коммуникации.

Когда платеж подтверждён:
1) payments публикует событие "payment confirmed".
2) emails отправляет чек.
3) billing генерирует счёт.
4) metrics обновляет дашборды.

Если завтра вы добавите ещё один микросервис, ему просто нужно реагировать на это событие. Payments не меняется.

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

Очевидно, не всё только преимущества. Система также становится сложнее. Возникают такие проблемы, как повторные попытки, дублирующиеся события, порядок обработки и наблюдаемость.

На практике обычно используется брокер (например, Kafka или RabbitMQ), который получает событие и распределяет его по подписанным микросервисам.

@KodBlog

Хватит использовать изменяемый Dictionary для данных, которые никогда не меняются.

Если вы строите справочные данные один раз, а читаете их часто, FrozenDictionary может подойти лучше.

Загвоздка: заморозка стоит ресурсов. Используйте его для долгоживущих справочников, а не для обычного состояния приложения.

Ссылка на документацию ниже.

https://learn.microsoft.com/ru-ru/dotnet/core/whats-new/dotnet-8/runtime#performance-focused-types

@KodBlog

Если ты уже знал все 25 приёмов — отпишись от меня.

Почти никто не доходит до 11-го приёма по .NET.

(№23 удивил даже меня):

1. Используй async до самого низа стека вызовов. Один блокирующий .Result может привести к взаимной блокировке всей цепочки.

2. ConfigureAwait(false) нужен в библиотеках. Не в коде приложения.

3. Возвращай Task напрямую, если не используешь await. Так не создаётся лишняя state machine.

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

5. IEnumerable — ленивый. Переберёшь его дважды — запрос выполнится дважды.

6. Здесь большинство перестаёт читать. IQueryable выполняется на стороне базы данных. IEnumerable сначала загружает всё в память.

7. Слишком ранний вызов .ToList() ломает оптимизацию фильтрации. Вызывай Where до материализации.

8. Проблема N+1 возникает незаметно. Включи логирование запросов EF Core — и увидишь её в работе.

9. Для операций чтения используй AsNoTracking(). Отслеживание изменений не бесплатно.

10. Проецируй данные в DTO через Select. Не загружай всю сущность целиком.

11. Scoped-сервис внутри Singleton — это ошибка с захваченной зависимостью, которая рано или поздно проявится.

12. Не создавай новый HttpClient для каждого запроса. Используй IHttpClientFactory.

13. Span<T> и stackalloc позволяют работать с данными без выделения памяти в куче. Нулевая нагрузка на GC.

14. В циклах используй StringBuilder вместо +=. Каждая конкатенация создаёт новую строку.

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

16. Records подходят для неизменяемых данных. Оператор with позволяет бесплатно создавать копии с изменениями.

17. Pattern matching лучше длинных цепочек if/else. Switch-выражения читаются проще.

18. Включай nullable reference types с первого дня. Эти предупреждения — ошибки, до которых ты ещё не добрался.

19. Вместо внедрения IConfiguration используй паттерн Options. Он даёт строгую типизацию и валидацию.

20. Передавай CancellationToken во все асинхронные методы. Прокидывай его дальше по цепочке, а не игнорируй.

21. Используй BackgroundService, а не случайный Task.Run(). Пусть жизненным циклом управляет хост.

22. Сначала измеряй, потом оптимизируй. Используй BenchmarkDotNet, а не интуицию.

23. Именно это удивило меня: по умолчанию делай свои классы sealed. Это даёт JIT бесплатную возможность для оптимизации.

24. Используй Native AOT для быстрого запуска и минимального размера приложения. Убирай всё лишнее при тримминге.

25. Последнее правило — и единственное, которое действительно имеет значение: читай SQL, который генерирует EF Core. Абстракция может вводить в заблуждение, пока не посмотришь, что она создаёт.

@KodBlog

Твоё .NET MAUI приложение, скорее всего, уже не только мобильное.

VisualStateManager + AdaptiveTrigger могут переключать layout, когда окно становится шире — прямо в XAML.

Без кода с SizeChanged и всей этой каши с событиями. Удобно.

Ссылка на документацию ниже.

https://learn.microsoft.com/ru-ru/dotnet/maui/fundamentals/triggers?view=net-maui-10.0#state-triggers

@KodBlog

Если хочешь стать по-настоящему сильным в .NET,
изучи следующие концепции:

1. CLR и JIT-компиляция
2. Сборка мусора (Garbage Collection)
3. Поколения памяти (Gen 0/1/2 и LOH)
4. Типы значений (Value Types) и ссылочные типы (Reference Types)
5. Boxing и Unboxing
6. Стек и куча (Stack vs Heap)
7. Span<T> и Memory<T>
8. ref struct и stackalloc
9. IDisposable и using
10. Финализаторы (Finalizers)
11. Async/Await
12. Task и ValueTask
13. SynchronizationContext
14. ConfigureAwait
15. CancellationToken
16. IAsyncEnumerable
17. Потоки и пул потоков (Threading & Thread Pool)
18. lock, Monitor и Semaphore
19. Channels
20. Parallel и PLINQ
21. LINQ и отложенное выполнение (Deferred Execution)
22. IEnumerable и IQueryable
23. Делегаты и события (Delegates & Events)
24. Func, Action и Predicate
25. Деревья выражений (Expression Trees)
26. Дженерики и ограничения (Generics & Constraints)
27. Ковариантность и контравариантность
28. Records и сопоставление с образцом (Pattern Matching)
29. Nullable Reference Types
30. Внедрение зависимостей (Dependency Injection)
31. Жизненные циклы сервисов (Scoped/Singleton/Transient)
32. Конвейер middleware (Middleware Pipeline)
33. Minimal APIs и Controllers
34. Привязка моделей и валидация (Model Binding & Validation)
35. Конфигурация и паттерн Options
36. IHostedService и BackgroundService
37. Entity Framework Core
38. Отслеживание изменений (Change Tracking)
39. Миграции (Migrations)
40. Проблема N+1
41. Пул подключений (Connection Pooling)
42. Dapper и Raw SQL
43. Кэширование (IMemoryCache и Distributed Cache)
44. Output Caching
45. Генераторы исходного кода (Source Generators)
46. Рефлексия и атрибуты (Reflection & Attributes)
47. AssemblyLoadContext
48. Native AOT
49. Бенчмаркинг (BenchmarkDotNet)
50. Профилирование памяти и настройка GC (Memory Profiling & GC Tuning)

@KodBlog

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

Большинство разработчиков строят абстракции для кода, который живёт ровно в одном месте.

Один интерфейс. Одна реализация. Один вызывающий. Навсегда.

И называют это «чистым кодом».

Вот в чём ловушка →

Абстракция, построенная для переиспользования, которое никогда не наступает — не переиспользуема. Это просто лишний слой, который надо прочитать, чтобы понять, что код на самом деле делает.

📌 Сначала удобство использования. Переиспользование — то, что вы зарабатываете потом.

Самая частая пустая трата, которую я вижу:

- ❌ IThingService с одной реализацией «на всякий случай»
- ✅ Конкретный класс, который можно прочитать от начала до конца
- ❌ Общая база «для будущей гибкости», которая никогда не гнётся
- ✅ Простая прямая версия, решающая сегодняшнюю задачу
- ❌ Фабрика, оборачивающая создание одного объекта
- ✅ Внедрение объекта напрямую через DI

Каждая лишняя абстракция усложняет использование кода.

Больше файлов для открытия. Больше косвенности для трассировки. Больше догадок, зачем это существует.

👉 Честный тест перед тем, как выносить абстракцию:

1. Есть ли у меня второй или третий реальный вызывающий код прямо сейчас? (Не «может быть потом»)
2. Это делает код проще в использовании или просто даёт повод гордиться собой?
3. Сможет ли следующий разработчик разобраться в этом без моих объяснений?

Если ответ «нет» — удаляйте слой. Пишите конкретную реализацию.

Вы не теряете переиспользование.

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

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

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

@KodBlog

Интересный новый бенчмарк проекции языков WinRT: Rust самый быстрый, C++ недалеко позади, C# пока догоняет. Внутренний push на C# для ОС и приложений не оставляет ли слишком много производительности на столе? 🤔

https://github.com/microsoft/windows-rs/blob/master/crates%2Fsamples%2Flang_perf%2Freadme.md

(время в мс; меньше — лучше)

На фото 2 обновлено под .NET 10.

@KodBlog