Я собрал рабочий Minimal API с EF Core всего в 3 файлах.

То же самое можно сделать за 10 минут. Без solution-файла. Без csproj. Без настройки проекта.

Только три .cs-файла и dotnet CLI.

Это file-based apps из .NET 11 Preview 3.
И это полностью меняет подход к созданию внутренних инструментов и прототипов.

Структура из 3 файлов

Order.cs
↳ Обычный POCO с Id, OrderNumber, CustomerName, Amount, CreatedAt

OrdersDbContext.cs
↳ EF Core DbContext с inline Fluent API mappings

main.cs
↳ Настройка DI, Minimal API endpoints и app.Run()

Вот и всё: 3 файла в одной папке.

Вся магия — в 4 директивах в начале main.cs

#:sdk Microsoft.NET.Sdk.Web

↳ Подключает WebApplication и типы ASP.NET Core

#:package Microsoft.EntityFrameworkCore.Sqlite@10.0.0

↳ При первом запуске подтягивает SQLite provider

#:include Order.cs

↳ Добавляет entity в компиляцию

#:include OrdersDbContext.cs

↳ Добавляет DbContext в компиляцию

Эти четыре строки заменяют целый csproj и sln.
Ниже директив — обычный ASP.NET Core-код.

Запуск одной командой:

dotnet run main.cs

При первом запуске восстанавливается EF Core.
Все последующие запуски уже быстрые.
И в итоге у вас полноценный Web API с настоящей базой данных.

Где file-based apps особенно хороши
→ Internal tools без лишней церемонии
→ Прототипы, которыми можно делиться как одной папкой
→ Демо, запускаемые за пару минут
→ Замена Python-скриптов там, где нужна строгая типизация
→ Онбординг новых разработчиков без путаницы с csproj

Где их использовать не стоит
→ Multi-project решения с shared libraries
→ Приложения с кастомной MSBuild-логикой
→ Разработка NuGet-пакетов
→ Production-приложения с полноценным CI/CD и test-проектами

А когда скрипт перерастёт свой формат — есть команда миграции:

dotnet project convert main.cs

Она создаст полноценный csproj и перенесёт туда все директивы.

👉 @KodBlog

Опенсорс домен-сервис с 162K звезд,

→ Регистрация доменов за $0
→ Бесплатное продление навсегда
→ Никаких скрытых подписок и ловушек
→ Полностью open-source и управляется сообществом

https://github.com/DigitalPlatDev/FreeDomain

👉 @KodBlog

Большинство .NET-разработчиков используют Redis только как кэш — и на этом всё.

Redis хранит данные в памяти (RAM), а не на диске, поэтому чтение обычно занимает меньше миллисекунды.

Именно благодаря этой скорости Redis подходит не только для кэширования. Вот 10 сценариев, о которых стоит знать:

1. Кэширование ответов API

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

2. Хранение сессий

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

3. Ограничение частоты запросов (Rate Limiting)

С помощью одного счётчика Redis можно отслеживать количество запросов от IP-адреса за последнюю минуту и блокировать злоупотребления ещё до того, как они дойдут до API.

4. Лидерборды в реальном времени

Сортированные множества (Sorted Sets) позволяют автоматически поддерживать рейтинг по очкам. Запрос топ-10 выполняется практически мгновенно даже при миллионах игроков.

5. Обмен сообщениями через Pub/Sub

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

6. Распределённые блокировки

Когда несколько серверов могут одновременно изменять одну и ту же запись, Redis выдаёт единственную блокировку. Это помогает избежать конфликтов и перезаписи данных.

7. Очереди задач

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

8. Аналитика в реальном времени

Redis Streams позволяют записывать большие потоки событий (клики, просмотры страниц и т.д.) и обрабатывать их по мере поступления.

9. Флаги функциональности (Feature Flags)

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

10. Память для AI-чатов

Храните недавний контекст диалога в Redis, чтобы LLM (модель, лежащая в основе чат-бота) могла помнить, о чём шла речь ранее.

Один инструмент — десять сценариев использования. Но большинство команд так и остаются на первом пункте.

👉 @KodBlog

Разработчики на .NET, автоматизируйте работу с документами.

→ Генерация PDF-документов (QuestPDF / iText)
→ Экспорт в Excel без использования Interop (ClosedXML / EPPlus)
→ Объединение и разделение PDF-файлов (PdfSharp)
→ Работа с шаблонами Word (OpenXML / DocX)
→ OCR и извлечение данных из документов (PdfPig / Tesseract / Azure Document Intelligence)

Подробнее: https://buff.ly/65Hrxv4

👉 @KodBlog

50 тем по System Design — от простого к сложному

Идеальная дорожная карта для изучения System Design в 2026 году. Сохраните этот список.

1. Спроектировать Rate Limiter
2. Спроектировать сервис сокращения URL
3. Спроектировать Pastebin
4. Спроектировать генератор уникальных идентификаторов
5. Спроектировать Consistent Hashing
6. Спроектировать балансировщик нагрузки
7. Спроектировать API Gateway
8. Спроектировать простое Key-Value хранилище
9. Спроектировать систему кэширования (например, LRU Cache)
10. Спроектировать систему уведомлений
11. Спроектировать систему автодополнения (Typeahead/Autocomplete)
12. Спроектировать веб-краулер
13. Спроектировать очередь сообщений
14. Спроектировать чат один на один
15. Спроектировать групповой чат
16. Спроектировать ленту новостей
17. Спроектировать сервис определения близости пользователей (например, друзья поблизости)
18. Спроектировать Instagram (обмен фото и видео + лента)
19. Спроектировать Twitter/X (публикации + таймлайн)
20. Спроектировать WhatsApp (обмен сообщениями в реальном времени)
21. Спроектировать Dropbox (хранение и синхронизация файлов)
22. Спроектировать систему бронирования билетов
23. Спроектировать платформу электронной коммерции (каталог + оформление заказа)
24. Спроектировать рекомендательную систему
25. Спроектировать распределённый кэш
26. Спроектировать Uber (поиск и сопоставление водителей и пассажиров)
27. Спроектировать Netflix (платформа потокового видео)
28. Спроектировать YouTube (загрузка и стриминг видео)
29. Спроектировать TikTok (платформа коротких видео)
30. Спроектировать ленту новостей социальной сети уровня Facebook
31. Спроектировать Google Docs (совместное редактирование документов в реальном времени)
32. Спроектировать CDN (Content Delivery Network)
33. Спроектировать поисковую систему (индексация и поиск)
34. Спроектировать Google Maps (маршрутизация и геолокационные сервисы)
35. Спроектировать распределённую базу данных
36. Спроектировать систему аналитики в реальном времени
37. Спроектировать систему показа и отслеживания рекламы
38. Спроектировать систему обнаружения мошенничества
39. Спроектировать торговую платформу или биржу ценных бумаг
40. Спроектировать распределённый планировщик задач
41. Спроектировать архитектуру Event Sourcing + CQRS
42. Спроектировать мультиарендную SaaS-платформу (Multi-tenant SaaS)
43. Спроектировать масштабируемый сервис прямых видеотрансляций
44. Спроектировать высокомасштабируемую NoSQL-базу данных
45. Спроектировать серверную часть многопользовательской игры в реальном времени
46. Спроектировать инфраструктуру обслуживания ML-моделей (Model Serving)
47. Спроектировать геораспределённую систему с низкой задержкой
48. Спроектировать глобальную базу данных со строгой согласованностью
49. Спроектировать платформу для высокочастотной торговли (HFT)
50. Спроектировать распределённую систему планетарного масштаба (миллиарды пользователей, несколько регионов, высокая доступность)

👉 @KodBlog

AddDbContext — вариант по умолчанию. AddDbContextPool — оптимизация. AddDbContextFactory — запасной выход для особых сценариев. Большинство .NET-команд не понимают, когда стоит выбирать каждый из них.
EF Core предоставляет три способа регистрации DbContext. В Program.cs они выглядят похоже. В продакшене они ведут себя совершенно по-разному.

1. AddDbContext
Вариант по умолчанию. Регистрирует DbContext с временем жизни Scoped — новый экземпляр на каждый HTTP-запрос. Фреймворк создаёт его при начале запроса и освобождает после отправки ответа.
Используйте его, если конфигурация контекста меняется от запроса к запросу: разные строки подключения в multi-tenant-приложениях, динамические фильтры логирования и всё, что нужно определять во время обработки запроса.
Цена такого подхода — создание и освобождение объекта на каждом запросе. В API с низкой нагрузкой вы этого не заметите. При 5000 запросах в секунду нагрузка на GC начинает проявляться в трассировках.

2. AddDbContextPool
EF Core поддерживает пул экземпляров DbContext: выдаёт экземпляр на время запроса, а затем возвращает его обратно в пул. Никаких дополнительных аллокаций и затрат на создание объекта.
Используйте этот вариант, если конфигурация стабильна и важна высокая пропускная способность. Он существенно снижает количество аллокаций на горячих эндпоинтах.

Но есть нюанс: экземпляры из пула переиспользуются, а не создаются заново. Если запрос изменяет состояние на уровне контекста — настройки ChangeTracker, savepoint'ы, состояние пользовательских интерсепторов — и логика сброса что-то упустит, следующий запрос унаследует это состояние. Такой баг выглядит случайным. На самом деле он не случайный. Причина — некорректный сброс состояния перед возвратом объекта в пул.
Не используйте пул, если вам нужна конфигурация, зависящая от конкретного запроса. Пул делает такой сценарий невозможным.

3. AddDbContextFactory
Здесь вы сами управляете жизненным циклом контекста. Внедряете IDbContextFactory<T>, вызываете CreateDbContext(), используете контекст внутри блока using и затем освобождаете его.
Используйте этот вариант в фоновых сервисах, worker-задачах, hosted services и любом коде, который выполняется вне HTTP-запроса. Scoped-зависимости там не работают, потому что отсутствует scope запроса. Фабрика позволяет создавать контекст независимо от него.

Цена — ответственность за освобождение ресурсов ложится на вас. Забудете using — получите утечку соединений.

Если конфигурация меняется для каждого запроса — используйте AddDbContext.

Если нужна максимальная производительность при стабильной конфигурации — используйте AddDbContextPool и контролируйте корректный сброс состояния.

Если код выполняется вне HTTP-скоупа (фоновые сервисы, воркеры) — используйте AddDbContextFactory.

Большинство команд по умолчанию используют AddDbContext и больше не возвращаются к этому решению. Если у вас есть горячие эндпоинты или фоновые задачи, работающие с базой данных, стоит потратить 10 минут на аудит текущей конфигурации.

👉 @KodBlog

dotnet ef поддерживает файловые приложения (file-based apps) в Entity Framework 11.

👉 @KodBlog

Только сейчас наткнулся на полностью переписанный DesktopManager для .NET и PowerShell.

Штука неожиданно мощная. Из коробки умеет:
• Управлять мониторами и обоями
• Контролировать слайд-шоу рабочего стола
• Менять яркость экрана
• Находить окна и UI-элементы и взаимодействовать с ними
• Эмулировать мышь и клавиатуру
• Работать с буфером обмена
• Делать скриншоты
• Управлять раскладками окон и рабочим столом

По сути, это такой комбайн для автоматизации Windows. Если приходилось писать свои обёртки вокруг WinAPI, UI Automation или PowerShell-скрипты для управления рабочим столом, здесь многое уже собрано в одном месте.
Проект с открытым исходным кодом, доступен бесплатно как NuGet-пакет и PowerShell-модуль.

👉 @KodBlog

Знаешь, как спроецировать вложенную коллекцию?

Вот один из способов:

SelectMany — это LINQ-метод, который работает с коллекциями IEnumerable и IQueryable и разворачивает элементы последовательности в одну коллекцию.

Если разложить весь процесс по шагам:
• Берёт последовательность элементов
• Выполняет преобразование для каждого элемента
• Генерирует новую последовательность элементов для каждого входного элемента
• Объединяет все полученные промежуточные последовательности в одну плоскую последовательность

Если коллекция равна null, выбрасывается ArgumentNullException.

👉 @KodBlog

Приложение работает на вашем ноутбуке. Это ещё не значит, что оно готово к продакшену.
Среди всех production-чеков чаще всего забывают именно эти вещи.

Health Checks
У приложения должен быть эндпоинт, который отвечает примерно так:

Я жив, и база данных доступна.

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

Логирование и мониторинг
Когда что-то ломается в 2 часа ночи, логи становятся единственным источником правды.
Если всё логирование заканчивается консолью на локальной машине разработчика, в продакшене вы работаете вслепую.

Секреты в Vault
API-ключи, connection strings и пароли не должны жить в репозитории или попадать в сборку.
Получайте их из Vault или через переменные окружения во время запуска.
Одна утечка артефакта не должна автоматически означать компрометацию продакшена.

Rate Limiting
Один неудачный клиент, бот или бесконечный цикл может положить API для всех остальных.
Лимиты запросов защищают систему от таких сценариев и помогают сохранить доступность сервиса.

Ещё три пункта обычно завершают этот список:
• Миграции базы данных
• Обработка ошибок
• Нагрузочное тестирование

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

👉 @KodBlog

Что такое Sidecar Pattern в микросервисах?

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

Обычно основной контейнер занимается бизнес-логикой, а sidecar обслуживает сопутствующие задачи.

Преимущества:
- Выносит кросс-функциональные задачи из приложения
логирование
мониторинг
безопасность
трассировка запросов

- Не зависит от языка и фреймворка
одинаково работает с Java, Go, Python, .NET и любым другим стеком

- Обновляется и масштабируется независимо от основного сервиса

- Упрощает код приложения
бизнес-логика не смешивается с инфраструктурным кодом

Когда стоит использовать Sidecar:

нужно добавить новую функциональность без изменений в основном сервисе
требуется единый подход к логированию, мониторингу или безопасности во всех сервисах
приходится работать с legacy-приложениями, которые сложно менять

Типичные сценарии использования:

• Логирование и мониторинг
Fluent Bit
Fluentd
OpenTelemetry Collector

• Service Discovery
регистрация сервиса
обнаружение соседних сервисов

• Proxy и Routing
Envoy
Istio Sidecar Proxy

• Безопасность и аутентификация
mTLS
управление сертификатами
проверка токенов

• Управление конфигурацией
получение и обновление конфигурации из внешних систем
Пример:

┌─────────────────┐
│      Pod        │
│                 │
│ ┌─────────────┐ │
│ │ Main App    │ │
│ └─────────────┘ │
│                 │
│ ┌─────────────┐ │
│ │ Envoy       │ │
│ │ Sidecar     │ │
│ └─────────────┘ │
└─────────────────┘

В Kubernetes sidecar чаще всего запускается в том же Pod, что и основное приложение. Именно так работают многие service mesh решения, включая Istio и Linkerd.

👉 @KodBlog

Docker тихо вырастил себе самого серьёзного конкурента.

Он называется Podman.

И всё больше Linux-разработчиков переходят на него.

Почему?

Потому что Podman убирает одну из самых спорных архитектурных особенностей Docker:

демон.

Никакого центрального фонового сервиса.
Никакого постоянно работающего процесса с повышенными привилегиями.
Никакой огромной поверхности атаки из-за привилегированного демона.

Взамен получаешь:

• rootless-контейнеры
• CLI, совместимый с Docker
• интеграцию с Kubernetes
• поддержку OCI
• pods
• интеграцию с systemd
• меньшее потребление ресурсов в простое

При этом большинство Docker-команд работают почти без изменений.

Самое интересное здесь даже не Podman.

Тренд в том, что разработчики всё чаще выбирают инфраструктурные инструменты, которые:

• легче
• работают без root-прав
• имеют открытый исходный код
• не требуют демона
• проще в защите и сопровождении

Экосистема Linux-инструментов сейчас развивается с очень высокой скоростью.

https://github.com/podman-container-tools/podman

👉 @KodBlog

Появился новый IDE для .NET, написанный на .NET и Godot.

Называется SharpIDE - https://github.com/MattParkerDev/SharpIDE

Проект полностью open source и нацелен на .NET 10. Автор делает ставку на современный интерфейс, кроссплатформенность и быстрый цикл разработки.

Что выделяется:
• написан на .NET + Godot
• работает на Windows, Linux и macOS
• собственный отладчик SharpDbg
• открытый исходный код
• активно развивается перед релизом .NET 10

Недавно автор показал бенчмарк, где путь от Build + Debug до срабатывания breakpoint занимает около 350 мс против 1.28 с у Visual Studio и 9.22 с у Rider.

Любопытно видеть, как кто-то пытается построить полноценную .NET IDE с нуля, а не очередной VS Code-плагин.

👉 @KodBlog

Постмортемы, пожалуй, самый недооценённый способ изучать распределённые системы.

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

5 постмортемов, которые реально стоит прочитать:

1. GitLab — Database Outage of January 31

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

2. Slack — Incident on 2-22-22

Отличный кейс про каскадные сбои. Маленькая проблема превращается в цепочку отказов, которая начинает валить остальные компоненты системы.

3. Meta — October 4 Outage

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

4. Cloudflare — Control Plane and Analytics Outage

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

5. AWS — Post-Event Summaries

Целая коллекция разборов инцидентов от одной из крупнейших облачных платформ. Хороший источник для регулярного чтения.

После таких материалов начинаешь смотреть на системы иначе.

👉 @KodBlog

В .NET 11 продолжают тихо выпиливать причины писать unsafe.
Команда накидала пачку оптимизаций в JIT (и Native AOT тоже), которые убирают лишние проверки границ массива. В результате безопасный код всё чаще выдаёт ту же производительность, что и его unsafe аналог.

Если интересно следить за прогрессом, у них даже есть отдельный лейбл: https://github.com/dotnet/runtime/pulls?q=is%3Apr+label%3Areduce-unsafe
Пример: https://github.com/EgorBot/Benchmarks/issues/169

👉 @KodBlog

CQRS на самом деле намного проще, чем его обычно пытаются представить.

Я не делю систему на 15 слоёв, не тащу отдельные базы и не устраиваю культ Event Sourcing.

Просто организую код вокруг use case'ов.
Типичные примеры:
• получить профиль пользователя
• добавить товар в корзину
• оформить возврат средств

Каждый use case живёт в своей папке и отвечает за одну конкретную бизнес-задачу.
Дальше всё сводится к двум вещам:

Command
→ меняет состояние системы
→ пишет в БД
→ отправляет события
→ запускает сайд-эффекты

Query
→ ничего не изменяет
→ просто возвращает данные в том виде, в котором они нужны UI

Вот и весь CQRS.

Каждый раз, когда вижу очередную статью с отдельными read/write базами, Kafka, Event Store и диаграммой на полэкрана, вспоминаю, что CQRS изначально был просто про разделение чтения и записи.

P.S. Нет, CQRS не требует Event Sourcing.
P.P.S. Нет, CQRS не требует двух баз данных.
P.P.P.S. Да, большинство команд, которые внедряют CQRS, в итоге внедряют что-то гораздо сложнее самого CQRS. 😅

👉 @KodBlog

Этот парень уместил RetroPad, свою версию Notepad из Windows XP с полным набором функций, всего в 2686 байт x86-ассемблера.

Да, меньше трёх килобайт.
Чтобы всем было проще запустить проект, он сразу закоммитил готовый .exe, так что возиться с MASM не придётся.
Скоро выйдет отдельный разбор того, как удалось так ужать приложение.

Код: https://github.com/PlummersSoftwareLLC/TinyRetroPad

👉 @KodBlog

Небольшой VS Code трюк для скриншотов и демонстраций.

Откройте Command Palette → Developer: Toggle Developer Tools.
Во вкладке Elements выберите body и добавьте:

filter: blur(5px);

Весь код в редакторе станет размытым, а интерфейс останется узнаваемым.

Удобно, когда нужно показать IDE на скриншоте, записать видео или провести демонстрацию, не раскрывая содержимое проекта.
Чтобы вернуть всё обратно, просто перезагрузите VS Code.

👉 @KodBlog