Технология создания веб-приложений и веб-сервисов
Эта база данных покоряет своей продуманностью: индексы рождаются автоматически, система обновляется без вашего участия, а защита данных стоит на страже, словно крепость. И это лишь начало её возможностей.
Четыре месяца, 1823 коммита и около 200 000 строк кода: мобильное приложение для изучения английского, почти целиком написанное через LLM-агента. Я формулировал задачи, ревьюил и принимал архитектурные решения, но код руками набирал редко.
Статья не про то, как здорово, что нейросети пишут код. Она про два места, где эта схема ломается насмерть. Первое — энтропия: локально агент пишет аккуратный код, но через двести коммитов в проекте три способа поднять модалку и четыре файла с константами анимаций. Второе — физическая реальность и невысказанные инварианты: 109 коммитов ушло на одно движение шторки над клавиатурой, а на то, чтобы «забудь» в памяти питомца работало честно, понадобилась отдельная спецификация.
Внутри: конституция проекта в CLAUDE.md, четыре слоя храповиков (включая обёртку над git, которая не даёт обойти хуки), разбор пяти причин, почему анимация рвалась на реальном Android, и слоистая память на pgvector с локальными эмбеддингами.
Сегодня про background jobs в .NET: Hangfire, Quartz.NET, Worker Service и тот неловкий момент, когда job “почти точно выполнилась”, но система не уверена.
Снаружи все выглядит спокойно: задача ушла в фон, worker что-то сделал, retry настроен, lock вроде есть. А внутри остается неприятный вопрос: внешний эффект уже произошел или job просто упала до записи статуса?
Разберем без магии: почему retry не равен идемпотентности, чем lock отличается от dedup, зачем нужен operationId и что делать, когда повторный запуск может превратиться во второй счет, второе письмо или повторное изменение статуса.
Совместная разработка, и как найти лентяя в команде. История о том как я пришёл к созданию плагина для OpenSource.
Если у Вас закрались в голову мысли, что один из персонажей не работает, я думаю этот инструмент будет для Вас полезен.
А чтобы не читать всю статью инструменты можно быстро посмотреть
Сегодня про EF Core migrations и один очень удобный вызов, который локально экономит время, а в production может связать старт приложения, DDL-блокировки и rollback в одну неприятную историю.
Мы делаем QoyHunter — учётную систему для овцеводческих хозяйств Узбекистана, с витриной животных, доставкой и блогом на соседних поддоменах. С точки зрения бизнес-логики ничего экзотического: CRM как CRM. Экзотика начинается там, где эта CRM встречается с реальностью рынка.
А реальность такая: основной канал пользователей — Telegram, а не браузер; основной язык — не всегда русский (узбекский обязателен, английский — по явному выбору); часовой пояс один (Ташкент, UTC+5, без перехода на летнее время — тоже давало баги, но об этом ниже); а разработка идёт на Windows-ноутбуках без сервера БД под рукой. Из этих фактов вытекает добрая половина решений в статье. Стек: бэкенд на ASP.NET Core (.NET 10), фронт на React + Vite, админка на react-admin, всё за nginx в docker compose.
Одна база пишет, другая читает: как CQRS, Kafka и Outbox ускоряют запросы, но приносят lag, дубли и eventual consistency
Разрабатывая приложения, мы стараемся не злоупотреблять дублированием кода. Из часто встречающегося кода мы формируем библиотеки, а для их соединения в инфраструктуре ASP.NET Core приложения используем DI-контейнер. Инфраструктура тестирования для ASP.NET Core API, как правило, тоже повторяется, но какие инструменты помогают нам переиспользовать тестовый код?
Разработчики Python решают эту задачу с помощью pytest.fixtures, однако в dotnet-экосистеме (xUnit) хорошего аналога пока нет.
В статье рассмотрим пример, как в несколько строк собрать полноценное интеграционное окружение с изолированной БД, фейковым временем и случайностью, а также как донастроить это окружение для отдельно взятого теста.
Для кого эта статья: для бэкенд-разработчиков (на .NET), технических лидов, QA-инженеров, которые пишут код, и всех, кто устал от бессмысленно повторяющегося кода в тестах.
Если вы пишете на C#, но хотите добавить тестам элегантности Python — добро пожаловать.
TL;DR. Один «безобидный» foo.GetAsync().Result в middleware способен превратить ASP.NET Core, державший 50k RPS с p99 = 40 мс, в сервис с 12k RPS и p99 = 4 с — при CPU 8 %.
Виноват не сам blocking call, а hill-climbing — фидбэк-луп в ThreadPool, в недрах которого живёт дискретное преобразование Фурье. Разбираем по исходникам CoreCLR, почему это вообще возможно, воспроизводим эффект на ~80 строках кода и разбираемся, почему SetMinThreads — не решение, а анестезия.
В dev-среде аутентификация может годами выглядеть безобидно: логин прошёл, cookie выпущена, [Authorize] работает. А потом приложение переезжает в продакшен — и часть пользователей начинает вылетать из системы без понятной ошибки. Иногда всплывает 431 Request Header Fields Too Large, иногда сервер просто перестаёт принимать сессию, которая ещё минуту назад выглядела корректной.
В статье разбираем, почему cookie аутентификации в ASP.NET Core разрастаются до опасных размеров, как это проявляется в реальных системах и какие решения помогают не лечить симптомы, а привести схему аутентификации в нормальное production-ready состояние.
gRPC кажется простым только до первого реального проекта. В этой статье - практические решения для типичных подводных камней: nullable, decimal, DateTime, наследование, дженерики и enum. Всё на основе реального опыта переноса сотни моделей с REST и WCF на gRPC. Обновлено под protoc v34.1 и dotnet 10.
Мне давно было интересно, как устроена библиотека MassTransit изнутри. Хотелось разобраться в её архитектуре, понять, как она развивалась, и почему порой в ней бывает непросто ориентироваться.
Если вам тоже интересно, что скрывается за consumers, publishers и sagas - приглашаю к чтению.
Domain-Driven Design (DDD) звучит как серебряная пуля. Когда мы начинаем проект на ASP.NET, идея четкого разделения на слои, изоляция бизнес-логики в домене и использование паттернов вроде Repository и Unit of Work кажется идеальной архитектурой.
Но есть один нюанс: магия DDD начинает испаряться ровно в тот момент, когда количество агрегатов (реестров) в проекте переваливает за 30. То, что было элегантным решением для CRM с 10 сущностями, превращается в бюрократический ад для ERP-системы или крупного маркетплейса.
В этой статье я разберу, почему классический DDD в ASP.NET (особенно в связке с Entity Framework Core) становится узким местом на масштабных проектах.
В этой статье я постарался собрать краткий гайд по Singleton, Transient и Scoped. Статья рассчитана на тех, кто хотя бы немного знаком с DI в .NET и не является полноценным туториалом.
По традиции статей Хабра начну с описания проблемы.
Я изучаю C#, .NET, ASP.NET и ищу работу Backend-разработчика. Сейчас дело дошло до собеседований и фундаментальных вещей (синтаксис, паттерны проектирования, принципы SOLID), я понял, что информации море и она вываливается из головы.
Вспомнил про метод карточек (Flashcards), который обычно используют для иностранных языков. Пошел на популярные ресурсы: Quizlet, RemNote и прочие. Зарегистрировался, начал создавать колоды, мне понравилось, вошел во вкус и каково было мое разочарование когда я везде натыкался на платные подписки. Где-то ограниченное количество карточек, где-то постоянная реклама, где-то очень замудренный интерфейс сделанный вообще не понятно для кого (привет Anki).
Хочешь больше функций? Плати. — Хочешь учить без рекламы? Плати. — Хочешь добавить картинку? Ну, ты понял...
Я смотрел на эти интерфейсы и во мне кипела злость: «Ну это же обычное CRUD-приложение! Две таблицы в базе, простейший API. Что тут сложного? Я сам могу такое сделать!»
Так родилась идея: написать свой сервис. Бесплатный. Без ограничений. Для себя. Это и проблема решится, и пет-проект для резюме будет.
Работа с микросервисами достаточно сложная, как и с любой распределенной системой. Уменьшение количества возможных точек отказа должно быть одной из целей инженера, который проектирует распределенную систему. В этой статье мы постараемся достичь именно этого, используя паттерн Outbox.
Привет! Сегодня разберем два подхода в ASP.NET. Blazor и классическую архитектуру MVC (Model-View-Controller). В отличие от обсуждений вроде «Java vs C++», эта тема менее спорная, но очень полезная для понимания современной веб-разработки на .NET.
Garbage Collector (GC) — одного из самых важных «невидимых помощников» в.NET.
Он избавляет нас от ручного управления памятью, но как именно?
За 13,5 лет я создал 12 опенсорс-проектов для платформы .NET и особое место среди них для меня занимает проект WebMarkupMin. Я не могу точно сказать, что мне больше всего нравится в нем: интересная исследовательская работа, лавры первопроходца на платформе .NET или не уходящая с годами актуальность.
В этой статье будет мало технических подробностей, потому что подобных статей о WebMarkupMin написано предостаточно. Здесь будет сделан акцент на разработке концепции опенсорс-проекта, его продвижении и взаимодействии с другими людьми.
Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, и так далее.
Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” - истинный, подлинный). В качестве доказательства может использоваться паспорт, для подтверждения личности в банке, либо ввод пароля на сайте.
Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.