У нас уже подходит к концу лето 2026 года. AI‑агенты, вайб-кодинг, Docker и тонны фреймворков, библиотек и примеров для всех современных платформ. Микросервисы — цель, икона и грааль как в разговорах, так и в требованиях к кандидатам. В одиночку можно быстро поднять работающий проект, подключить к нему ИИ и выложить для использования.

Наконец-то закончилась волна «входа в IT» с бесконечными полусырыми курсами и инфоцыганскими каналами для вайтишников. Как-то поуспокоилось.

Но есть ряд вопросов: Не тратит ли разработчик больше времени, сражаясь с настройками контейнеров для разработки или с тем же Webpack, чем на написание самого кода? Сколько нужно изучить, чтобы написать простое веб-приложение? Каково минимальное количество библиотек и фреймворков для этого? Всегда ли нужны микросервисы?

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

Что будем разрабатывать

В качестве эксперимента возьмём небольшое приложение — TODO List (не! нечто более живое) систему хронометража для лесной велогонки с раздельным стартом. Требования на старте выглядят вполне несложно:

• регистрация участников с раздачей стартовых номеров;

• фиксация момента старта каждого участника;

• фиксация финиша или отказа от участия;

• отображение списка участников с их временем и итоговым местом.

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

Такая задача отлично подходит для эксперимента: она требует базовых операций CRUD, немного логики (расчёт времени, определение мест), но при этом остаётся достаточно простой, чтобы реализовать её с минимальным количеством инструментов.

Выбираем платформу

Так как я очень давно имею дело с .NET, приложение будем строить, используя:

• C# и ASP.NET Core — кроссплатформенный фреймворк от Microsoft, который входит в состав .NET;

• ADO.NET — для доступа к базе данных (да, обычно просто берут Entity Framework а еще есть например Dapper, но попробуем обойтись без них);

• PostgreSQL — хорошо зарекомендовавшая себя СУБД, для работы с которой будем использовать провайдер Npgsql;

• JavaScript (совместимость со старыми браузерами делать не будем) — на клиенте, возможно, с минимальным использованием какого-нибудь микро-фреймворка для удобства работы с UI, всё же чистый JS сильно увеличивает трудоемкость.

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

План эксперимента

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

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

2. Начнём с UI.
   Соберём интерфейс, который будет работать прямо в браузере, пока без серверной части. Используем для временного хранения localStorage, чтобы увидеть, как будет выглядеть и вести себя приложение. Это позволит быстро прототипировать внешний вид и логику отображения.

3. Серверная часть — чтение и сохранение данных.
   Реализуем простейший ASP.NET Core backend с CRU[без D]. Для работы с PostgreSQL подключим Npgsql и будем писать запросы через ADO.NET. Посмотрим, что можно сделать с маппингом данных из БД в объекты C# и обратно.

4. Развитие серверной части.
   Посмотрим что и куда нам нужно добавить что бы получилось почти завершенное приложение.

5. Усложнение UI.
   Вернемся к UI и добавим то, чего нам не хватает.

6. Упаковка и деплой.
   Подготовим приложение к запуску на реальном сервере: соберем пакет, рассмотрим варианты контейнеризации (Docker) — но только если это действительно упростит деплой, а не создаст лишнюю прослойку.

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

Что дальше

В следующей статье мы подробно разберём бизнес-процесс нашего велозаезда, выделим ключевые сущности и набросаем архитектуру будущего приложения. Присоединяйтесь — надеюсь будет интересно. А что точно дальше будет: темы для холиваров, шатание принятых практик, велосипеды и костыли.

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

Начнем