---

---

1. Теоретические основы разработки веб-приложения

В современном мире веб-приложения являются основой цифровой экономики, предоставляя пользователям доступ к функционалу через браузер без необходимости установки дополнительного ПО. Теоретические основы разработки таких систем базируются на трех ключевых аспектах: архитектуре, сетевых протоколах и принципах взаимодействия клиент-сервер.

Большинство современных веб-приложений строятся по клиент-серверной архитектуре. Серверная часть (бэкенд) отвечает за бизнес-логику, хранение данных и безопасность. Клиентская часть (фронтенд) обеспечивает интерфейс и взаимодействие с пользователем. Ключевым принципом является протокол HTTP/HTTPS, который определяет правила обмена данными.

В последние годы доминирующим подходом стала SPA (Single Page Application) архитектура. В отличие от классических многостраничных сайтов, SPA загружает страницу один раз, а затем динамически обновляет только необходимый контент (через AJAX или WebSockets). Это критически важно для аукциона, где цены меняются в реальном времени.

Кроме того, важной теоретической основой является концепция REST (Representational State Transfer) — архитектурный стиль для построения API, где каждый ресурс (лот, пользователь, ставка) имеет свой уникальный URL, а операции с ним выполняются стандартными HTTP-методами (GET, POST, PUT, DELETE).

2. Обзор и сравнительный анализ существующих онлайн-аукционов

Для успешной разработки необходимо изучить предметную область и конкурентную среду. Существующие онлайн-аукционы можно классифицировать на три типа:

1. Универсальные (eBay, Yahoo Auctions) — продажа любых товаров по модели «английский аукцион» (повышение цены).
2. Специализированные (Sotheby's, Catawiki) — антиквариат, искусство, коллекционные вещи.
3. Нисходящие аукционы (голландские) — цена снижается до момента покупки (используется на биржах).

Анализ популярных решений (например, eBay) позволяет выделить следующие функциональные блоки:

· Регистрация и профиль пользователя (с верификацией).
· Каталог лотов с фильтрацией по категориям, цене, времени окончания.
· Торговая сессия — механизм мгновенного приёма ставок.
· Таймер обратного отсчёта для каждого лота.
· Уведомления (email, push) о перебитии ставки или победе.
· Система рейтинга продавцов и покупателей.

Недостатки существующих решений (которые стоит учесть в своей разработке):

· Задержки при обновлении текущей цены (особенно у старых платформ).
· Сложный и перегруженный интерфейс для новых пользователей.
· Отсутствие прозрачной системы отмены ставок.

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

3. Выбор программных решений для создания веб-приложения

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

Для фронтенда (клиентская часть):

· JavaScript-фреймворк: Рекомендуется React или Vue.js. Они позволяют реализовать SPA и мгновенно перерисовывать цену при получении новой ставки без перезагрузки страницы.
· State Manager (управление состоянием): Redux или Pinia — для хранения текущего состояния торгов в глобальном хранилище.
· WebSockets (библиотека Socket.IO): Для двусторонней связи «сервер-клиент». В отличие от HTTP, WebSocket держит соединение открытым, позволяя серверу самому «проталкивать» новые ставки всем участникам лота.

Для бэкенда (серверная часть):

· Язык: Node.js (NestJS или Express) или Python (Django/ FastAPI). FastAPI (Python) хорош своей асинхронностью, но Node.js нативно лучше работает с WebSockets и большим количеством параллельных соединений.
· База данных:
  · Основная (реляционная): PostgreSQL для хранения пользователей, лотов, истории ставок. Нужны транзакции (ACID), чтобы избежать ситуаций, когда ставка записана, но баланс не списан.
  · Кэш / брокер: Redis. Хранит текущие «горячие» ставки и таймеры в оперативной памяти, что в сотни раз быстрее диска. Redis также используется как брокер для очередей задач.
· Авторизация: JWT (JSON Web Tokens).

Для инфраструктуры:

· Веб-сервер: Nginx (проксирование запросов + отдача статики).
· Процессор фоновых задач: Celery (Python) или Bull (Node.js) — для отправки писем о победе или напоминаний за 5 минут до конца торгов.

4. Анализ предметной области

Предметная область «Онлайн-аукцион» представляет собой модель экономического взаимодействия между тремя типами субъектов: «Администратор», «Продавец» (инициатор) и «Покупатель» (участник торгов).

Ключевые сущности и их атрибуты:

1. Пользователь: Логин, пароль, email, баланс счёта, рейтинг (на основе завершённых сделок), роль.
2. Лот: Название, описание, стартовая цена, шаг ставки (минимальное повышение), дата-время старта и окончания, статус (активен/завершён/отменён), победитель (ссылка на пользователя).
3. Ставка: Сумма, время размещения, ID пользователя, ID лота.
4. Транзакция: Списание/зачисление средств, статус (в ожидании/успешно).

Бизнес-правила (ограничения предметной области):

· Новая ставка должна быть строго больше текущей цены минимум на величину «шага торгов».
· Ставка не может быть сделана, если пользователь является текущим лидером.
· Ставка, сделанная после времени окончания лота, считается недействительной (Race condition — проблема гонки данных). Решение: проверка времени на сервере, а не на клиенте.
· Продавец не может делать ставки на своём собственном лоте.
· Пользователь не может отменить уже сделанную ставку (кроме случая, если лот перенесён администратором).

Процессы (основные потоки данных):

1. Процесс ставки: Пользователь нажимает «Сделать ставку» → Браузер отправляет запрос по WebSocket → Сервер проверяет текущую цену и баланс в Redis → При успехе записывает в PostgreSQL → Шлёт новую цену всем подключенным клиентам лота.
2. Процесс завершения: По истечении таймера запускается триггер → Победителю блокируется сумма ставки, продавцу начисляются средства (минус комиссия). Проигравшим возвращаются замороженные ранее гарантийные суммы.

Вывод по анализу: Разрабатываемое приложение должно решать ключевую проблему предметной области — консистентность данных в конкурентной среде (атомарность ставок) и низкую задержку извещения участников. Это требует отказа от архитектуры «запрос-ответ» в пользу событийно-ориентированной модели (Event Sourcing) с использованием WebSockets.

---