Пагинация с offset подходит для небольших наборов данных.

Для больших лучше использовать другой подход, а именно keyset pagination (она же seek-based pagination). Это гораздо более эффективный способ обхода больших выборок.

Проблема offset-пагинации (skip + take) в том, что база всё равно обрабатывает пропущенные строки, даже если они не возвращаются в результат.

В keyset-пагинации ничего пропускать не нужно. Достаточно запомнить последний ключ, который вы получили, и от него выбирать следующие строки.

Если столбец ID проиндексирован, такие запросы будут очень быстрыми даже на больших объемах данных.

А если у вас в качестве идентификаторов GUID? Тогда используйте UUID версии 7, он глобально уникальный и при этом сортируемый.

👉 @KodBlog

Неправильный выбор структур данных убивает .NET-приложения

Оптимизация 12 корпоративных систем на ASP .NET Core показала одну и ту же проблему -> разработчики часами тюнят запросы, добавляют индексы и кэш, но игнорируют главный фактор производительности —> структуры данных. 👊

Ошибочный выбор коллекций может замедлить приложение в 10 раз.

Вот что стоит использовать в зависимости от операции:

I. Поиск элементов по ключу
List<T>.Find() → O(n) → ужасно на больших объёмах
Dictionary<K,V> → O(1) → молниеносно

II. Частые вставки в начало
List<T>.Insert(0, item) → O(n) → сдвигает все элементы
LinkedList<T> → O(1) → без сдвигов

III. Коллекция с уникальными элементами
List<T> + проверка Contains → O(n) на добавление
HashSet<T> → O(1) → моментальная проверка уникальности

IV. Упорядоченные данные с бинарным поиском
List<T> + Sort → O(n log n) + свой код поиска
SortedDictionary<K,V> → встроенный порядок + O(log n) доступ

V. Кэширование ответов API
Статический Dictionary → утечки памяти и устаревшие данные
MemoryCache с истечением → автоматическая очистка

Я видел, как команды тратили дни на сложные оптимизации, хотя правильная структура данных решала проблему сразу.

❓А какую самую серьёзную проблему с производительностью ты решал выбором правильной структуры данных?

👉 @KodBlog

Простой гид по масштабированию веб-приложений

Система с более чем миллионом пользователей была масштабирована пошагово

I) Начало с простого

Приложение изначально монолит. Один API-сервер, одна база данных. Несколько лет работало стабильно, но с ростом пользователей система начала тормозить

II) Масштабирование API

База данных пока не была узким местом. Масштабирование API и добавление балансировщика нагрузки в Azure позволили обрабатывать больше запросов. Вертикальное масштабирование DB-сервера сработало на время, но позже потребовалось больше

III) Кэширование

Сначала использовался простой in-memory кэш на серверах. Позже внедрён Redis, распределённый кэш снизил нагрузку на базу. Большинство запросов стало обслуживаться из кэша

Главный совет

Решать проблему, которая есть сейчас. Не переусложнять архитектуру раньше времени

Подробнее о масштабировании приложений

👉 @KodBlog

Сегодня отмечается День программиста!

256-й день года выбран не случайно:

Дата праздника объясняется расчетом: 2 (двоичная система исчисления) в степени 8 (количество битов в байте). То есть 2^8= 256. Поэтому в обычный год день программиста 13 сентября, а в високосный — 12 сентября

С праздником, коллеги! ☺️

👉 @KodBlog

Настоящая находка для гейм девелоперов

Это огромная библиотека бесплатных ресурсов. От спрайтов и текстур до 3D-моделей, звуков и шрифтов, включая ассеты для VR и AR. Всё распространяется по лицензии CC0, так что использовать можно где угодно, даже в коммерческих проектах.

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

kenney.nl/assets

👉 @KodBlog

Интерактивный визуальный гид по математике и алгоритмам через концепты геймдева — https://redblobgames.com

Особое внимание уделите главам про теорию графов 💯

👉 @KodBlog

Исключения и ошибки — это не одно и то же.

Почему в вашем коде вы обращаетесь с ними одинаково?

Это сильно влияет на архитектуру приложения.

Моё твёрдое убеждение:

исключения предназначены для исключительных ситуаций.

Что значит «исключительная ситуация»?

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

Использовать исключения вместо ошибок —> бессмысленно.

Тем не менее многие разработчики делают это, выбрасывая исключения везде.

В результате они используют исключения для управления потоком —> это антипаттерн.

Решение:
• Явно представлять ошибки в коде и обрабатывать их.
• Бонус - явные ошибки делают намерения вашего кода прозрачными.

Подробнее: Functional Error Handling in .NET with the Result Pattern

И это лишь один из множества плюсов

👉 @KodBlog

Лучшие практики REST API в 2025 году

Я построил более 100 API, вот чему научился

Большинство разработчиков испытывают сложности с дизайном REST API.

1. Уровни зрелости REST

• Level 0: Один эндпоинт (избегать)
• Level 1: Несколько ресурсов
• Level 2: Правильные HTTP-методы
• Level 3: HATEOAS (если нужно)

2. Именование ресурсов

• Используйте существительные: /users, /orders
• Не используйте глаголы: /getUsers, /createOrder
• Будьте последовательны: user-profiles или product-carts
• Избегайте: UserProfiles, userProfiles

3. HTTP-методы и коды статуса

Методы:

• GET → Чтение
• POST → Создание
• PUT/PATCH → Обновление
• DELETE → Удаление

Коды успешных ответов:

• 200: Успех
• 201: Создано
• 202: Принято (асинхронно)
• 204: Нет содержимого

Коды ошибок (клиент):

• 400: Некорректный запрос
• 401: Неавторизован
• 403: Запрещено
• 404: Не найдено
• 422: Ошибка валидации

Коды ошибок (сервер):

• 500: Внутренняя ошибка сервера
• 503: Сервис недоступен

4. Версионирование API

• URI: /api/v1/users
• Header: X-Api-Version
• Media Type: application/vnd.api.v1+json
• Query String: ?version=1 (избегать)

5. Лучшие практики для запросов/ответов

• Всегда используйте JSON
• Стандартизируйте ошибки
• Поддерживайте фильтрацию и пагинацию
• Документируйте через OpenAPI/Swagger

6. Чеклист безопасности

• HTTPS повсюду
• OAuth2/JWT аутентификация
• Ограничение числа запросов
• Валидация входных данных
• Кеширование ответов

Главный принцип -> делайте API простым и последовательным.

👉 @KodBlog

SQLZap это настоящая находка

sqlzap.com это веб-платформа для практики SQL-запросов прямо в браузере. По сути, интерактивный симулятор.

Отлично подходит, чтобы прокачать навыки (как LeetCode, но для SQL)

👉 @KodBlog

Знаешь, что означает _ (подчёркивание) в C#?

Это символ для отбрасывания

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

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

Особенно полезно при работе с параметрами out.

Ещё _ можно использовать для:

I. Отбрасывание элементов кортежа
II. Отбрасывание возвращаемых значений
III. pattern matching с discard
IV. в выражениях switch

Для чего ещё можно использовать _ ?

👉 @KodBlog

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

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

Именно поэтому всё больше команд выбирают подход «сначала монолит» с модульной архитектурой:

• Меньше движущихся частей на старте
• Проще создавать, деплоить и поддерживать
• Более стабильная и функциональная система
• Экономично

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

Подробнее о модульном монолите

👉 @KodBlog

90% .NET-разработчиков управляют версиями NuGet самым сложным способом. 👊

Секрет работы с NuGet-пакетами в больших .NET-решениях это использовать Central Package Management (CPM).

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

После этого в проектах указывается только имя пакета — без версии.

Что это даёт
I. Единообразие по всей solution.
II. Одно место для обновления версии пакета.
III. Экономию времени при апгрейде .NET-версии.

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

P.S. Если в каком-то проекте нужна своя версия, всегда можно переопределить центральную.

👉 @KodBlog

Обновление поддержки .NET STS

Начиная с .NET 9 (текущий STS), поддержка STS-релизов увеличена с 18 месяцев до 2 лет.

Теперь STS-релизы теряют поддержку в тот же день, что и предыдущий LTS-релиз.

Это значит, что обновление до STS-релиза больше не приведёт к потере поддержки

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

https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-supported-for-24-months/

👉 @KodBlog

Появилось расширение, которое добавляет эффекты из Elden Ring в вашу почту, LeetCode и GitHub

Теперь пулл реквесты ощущаются как битва с боссом 🔨

Забираем с GitHub

👉 @KodBlog

У .NET-приложений больше нет оправдания быть нестабильными. Исправить это можно за пару минут.

Начиная с .NET 8, добавлять устойчивость в приложения стало гораздо проще, ведь появился обновлённый API Polly и официальные библиотеки от Microsoft для работы с отказоустойчивостью.

Polly — это библиотека для .NET, которая помогает обрабатывать временные ошибки и строить стратегии устойчивости: повторные попытки, fallback, таймауты, rate limiting и circuit breaker.

Хочешь узнать, как использовать Polly для создания resilience-пайплайнов? Вот статья со всеми деталями: Building Resilient Cloud Applications with .NET

А если ты работаешь с .NET Aspire, большая часть уже преднастроена «из коробки».

👉 @KodBlog

Принесли настоящий клад для изучения алгоритмов —> репозиторий awesome-algorithms

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

👉 @KodBlog