В статье представлено веб-приложение, предназначенное для организации мероприятий и коммуникационных услуг. Оно предлагает удобный инструмент для общения пользователей, организации их развлечений и отдыха. Рассмотрены архитектурные решения, функциональные возможности, технологии реализации, тестирование и обеспечение безопасности системы. Использованы современные технологии: Java, Spring Boot и PostgreSQL.

Ключевые слова: веб-приложение, организация мероприятий, Java, Spring Boot, PostgreSQL, тестирование, REST API, интеграция

Введение

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

Существующие на рынке [1–3] веб-приложения, помогающие с поиском компании для организации мероприятия, являются либо дорогостоящими, либо громоздкими с избыточным функционалом, либо требуют установки специфического программного обеспечения для организации мероприятий. Платформа Timepad.ru [1], предлагающая детальный конструктор страниц мероприятий, возможность просмотра чужих мероприятий как в каталоге, так и на странице мероприятия, добавление пользователей для участия в мероприятиях, массовые рассылки организаторами участникам мероприятия, генерируемые отчеты для организаторов, обладает рядом недостатков: включают высокую комиссию за продажу билетов (до 8 %), имеет ограниченный функционал на минимальных тарифах (отсутствие рассылок и шаблонов), сложную панель управления, которая не позволяет видеть изменения в реальном времени, и отсутствие электронной цифровой подписи на документах. Платформа Fixmeet.ru [2] ориентирована на организацию, в основном, личных встреч и неформальных собраний. Платформа запрещает ставить личные оценки, на ней отсутствуют инструменты для планирования и возможность для комментирования мероприятий в публичном пространстве. Платформа Pognali.ru [3] предназначена для мероприятий с акцентом на активный отдых и совместные поездки. Для организации мероприятий в своем городе платформа предлагает возможность публикации своих событий, просмотра чужих событий, добавления пользователей для участия в событиях, функцию личных сообщений между пользователями платформы. Платформа Pognali.ru получила высокую оценку экспертного совета конкурса Агентства стратегических инициатив (АСИ) «Сильные идеи для нового времени 2025". Недостатками является ориентация на узкую нишу мероприятий, ограниченный функционал для коммуникации и отсутствие инструментов управления задачами.

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

1. Методическая часть

1.1. Характеристика объекта автоматизации

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

На данный момент процесс организации мероприятий проходит следующим образом (рис. 1):

1. поиск участников мероприятия;
2. определение участников;
3. создание чата в мессенджере;
4. выбор места и даты мероприятия;
5. формирование списка необходимых вещей;
6. подсчет количества продуктов и необходимых принадлежностей;
7. распределение вещей из списка между участниками.

Рис. 1. Процесс планирования мероприятия

К основным недостаткам рассматриваемых способов планирования мероприятия (1-го этапа) можно отнести использование мессенджера и приложений для заметок. На этапе формировании списка (5-й этап), возникают проблемы с созданием списка вещей с нуля и неудобством редактирования списка, так как можно что-то упустить из обсуждения. При распределении задач из списка между участниками (7-й этап), нужно учесть необходимость скопировать/сделать скриншот из обсуждения и простановки отметок о выполнении того или иного действия из списка в мессенджере.

1.2. Инструментальные средства разработки

1.2.1. Архитектура программного кода

В основе приложения лежит многослойная архитектура Spring Boot приложения со строгим разделением ответственности и использованием современных подходов к разработке. Архитектура программного кода представлена на рисунке 2.

Рис. 2. Архитектура программного кода

В архитектуре программного кода содержатся следующие слои:

Слой клиентского взаимодействия; уровень представления; слой бизнес-логики; слой данных и инфраструктурный слой.

Слой клиентского взаимодействия отвечает за предоставление пользовательского интерфейса и взаимодействие с конечным пользователем. Он содержит такие компоненты, как HTML-шаблоны (Thymeleaf) для рендеринга динамических HTML-страниц; статические ресурсы для улучшения пользовательского опыта на стороне клиента, предоставляя стилизацию и интерактивность; Bootstrap для адаптивного дизайна и Font Awesome для иконок; JavaScript для обработки клиентской логики.

Уровень представления служит точкой входа для всех запросов к серверу и отвечает за их первоначальную обработку. Он содержит Web-контроллеры для обработки GET-запросов и возвращения имен Thymeleaf-шаблонов; REST-контроллеры для обработки HTTP-запросов к API; Конфигурация безопасности (SecurityConfiguration).

Слой бизнес-логики содержит основную бизнес-логику приложения и координирует операции между другими слоями. Он содержит в себе такие элементы, как сервисные классы для управления определенной предметной области и описания бизнес-правил, а также аспекты (AOP) для реализации сквозной функциональности: проверки прав доступа; сервисов проверки доступа для реализации конкретной логики проверки прав доступа.

Слой данных определяет основные бизнес-сущности и их отношения. Он включает сущности, репозитории (JPA Repositories) для выполнения CRUD-операций и сложных запросов к базе данных, мапперы для автоматического преобразования между DTO и сущностями.

Инфраструктурный слой обеспечивает поддержку основных функций приложения. Он включает базу данных PostgreSQL для хранения данных; миграции Liquibase для контролирования версии схемы БД; «Application Configuration» для сборки и внедрения зависимостей.

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

1.2.2. Программное обеспечение системы

Система состоит из двух основных модулей: основного сервиса events-app, содержащего всю бизнес-логику, и базы данных PostgreSQL. Технологический стек включает Java 21 и Spring Boot 3 для бэкенда, PostgreSQL 16 и Liquibase для работы с данными, а также MapStruct для маппинга объектов. Развертывание осуществляется в изолированных Docker-контейнерах.

1.2.3. Безопасность программного кода

Безопасность программного кода включает HTTPS-шифрование, JWT-аутентификацию и строгую валидацию данных. Для повышения производительности реализованы пагинация, поддержка HATEOAS и кэширование.

1.2.4. Реализованные архитектурные паттерны

1.2.4.1. Механизм проверки прав доступа на основе AOP

Реализована кастомная, гибкая систему авторизации с использованием аспектно-ориентированного программирования (AOP) [4, 5]. Это решение позволяет централизовать и значительно упростить управление правами доступа.

Основой системы является пользовательская аннотация @Access, которая помечает методы, требующие проверки прав доступа. За перехват вызовов таких методов отвечает аспект AccessCheckAspect. Он анализирует тип требуемой проверки и делегирует выполнение соответствующему сервису-проверщику, например, EventCheckerService или CommentCheckerService. Эти специализированные сервисы инкапсулируют всю сложную логику проверки, например определение права пользователя на удаление участника события в зависимости от его роли или статуса создателя.

Пример использования для удаления комментария:

@DeleteMapping("/{commentId}")

@PreAuthorize("hasRole('ROLE_USER')")

@Access(checkBy = AccessCheckType.COMMENT) // Аспект проверки доступа

public ResponseEntity deleteComment(...) {

// ... логика удаления

}

1.2.4.2. Использование DTO

В архитектуре приложения критически важным решением является отказ от прямой передачи сущностей JPA (таких как Event, User) через API. Вместо этого используются объекты передачи данных (DTO) — EventDto, UserDto и другие. Для эффективного и автоматизированного преобразования между этими сущностями и DTO применяется высокопроизводительная библиотека сопоставления MapStruct [6].

2. Экспериментальные исследования

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

2.1. Описание разработанного веб-приложения

Разработка веб-приложения представляет собой комплексный full-stack проект, включающий создание серверной части на Spring Boot и клиентского интерфейса с использованием современных веб-технологий. В рамках Spring Framework требуется работа с контроллерами, сервисами и репозиториями для обработки бизнес-логики, а также использование Thymeleaf для составления шаблонов и отображения данных, что особенно важно при работе со списками мероприятий и динамическим контентом.

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

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

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

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

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

2.2. Интеграционное тестирование сервисов

Интеграционное тестирование проводилось с использованием JUnit 5 и Spring Test, а также Testcontainers для работы с реальными БД в Docker-контейнерах, что обеспечивало реалистичность тестов и надежность. Тесты охватывали ключевые сервисы [7].

Было реализовано и успешно выполнено 20 тестовых сценариев, покрывающих основные и критические пути системы:

— UserService, где проверена корректность регистрации пользователя с шифрованием пароля, обработка попыток регистрации с дублирующимися именами пользователей (username) и email — адресами, а также функционал поиска пользователя.

— EventService, в котором подтверждена работоспособность создания мероприятий, управления участниками и контроля прав доступа (только создатель события может его редактировать и удалять).

— ChatService и TaskService: в них протестированы CRUD-операции для сообщений и задач со строгим соблюдением прав доступа (редактировать и удалять сообщение/задачу может только ее автор).

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

2.3. Тестирование REST API

Для тестирования REST API использовался инструмент Postman. С его помощью выполнялись ручные запросы к различным конечным точкам API для проверки их функциональности, ответов и обработки данных. Было выполнено 14 запросов, охватывающих основные функции системы: пользователи, события, комментарии, участники, чат, задачи (таблица 1).

Таблица 1

Параметры тестирования основных функций системы

Все тесты завершились успешно (100 % прохождение) со средним временем выполнения 298 мс. Наибольшее время выполнения (818 мс) зафиксировано при создании события, что связано с обработкой дополнительных данных. Представленные значения взяты из сводной таблицы результатов тестирования (рисунок 3).

Рис. 3. Результаты проведения REST API тестирования

2.4. Нагрузочное тестирование

Для оценки производительности и стабильности под нагрузкой использовался Apache JMeter. В процессе нагрузочного тестирования было выполнено 500 запросов, направленных на проверку производительности HTTP-запросов (рисунок 4). Среднее время отклика составило 171 миллисекунду, медианное значение — 148 миллисекунд. Это указывает на стабильно быстрый отклик для большинства запросов. Максимальное время отклика было зафиксировано на уровне 744 миллисекунд, в то время как минимальное составило всего 11 миллисекунд. Важно отметить, что 100 % запросов завершились успешно, при этом процент ошибок равен 0.00 %, что свидетельствует о высокой надежности и отсутствии сбоев под нагрузкой.

Пропускная способность системы достигла 246.8 запросов в секунду, что подтверждает её способность обрабатывать значительный объем операций. Общий объем полученных данных составил 104.36 кБ в секунду, а отправленных — 35.67 кБ в секунду.

Рис. 4. Экранная форма результатов нагрузочного тестирования

Эти данные подтверждают высокую производительность и надежность при работе с потоком запросов.

3. Обсуждение результатов

Было проведено комплексное сравнение производительности представленного в данной статье веб-приложения с рыночными программными аналогами: afisha.timepad.ru, pognali.ru и fixmeet.ru [1–3]. Сравнительный анализ данных, представленный в таблице 2, проводился по следующим параметрам:

 First Contentful Paint (FCP) — параметр, указывающий время, которое проходит с момента открытия страницы и до момента, когда посетитель увидит какое-либо её содержимое;

 Largest Contentful Paint (LCP) отображает время загрузки самого большого визуального элемента сайта.

 Cumulative Layout Shift (CLS) измеряет нестабильность контента, складывая смещение всех элементов, происходящее независимо от действий пользователей.

 Total Blocking Time (TBT) — это сумма всех периодов времени, когда основной поток страницы был заблокирован достаточно долго, чтобы предотвратить реагирование на действия пользователя.

 Индекс скорости (Speed Index) показывает, насколько быстро отображается контент страницы во время загрузки, т. е. как быстро заполняется видимая часть страницы.

Таблица 2

Производительности разработанного приложения и рыночных программных аналогов [8–10]

Представленное в данное статье веб-приложение демонстрирует хорошие показатели: LCP = 1.0 с, TBT = 0 с и CLS = 0 с, что гарантирует мгновенную загрузку контента без блокировок интерфейса.

В отличие от разработанного веб-приложения, конкурентные аналоги испытывают системные проблемы: LCP = 3.1 с, CLS = 1.05 с для afisha.timepad.ru; CLS = 0.69 с в случае pognali.ru. Это наглядно показывает, что найденное решение обеспечивает стабильный пользовательский опыт. Индекс скорости разработанного приложения, равный 1.5 с, значительно превосходит показатели индекса скорости для приложений afisha.timepad.ru и pognali.ru, у которых время визуализации контента составляет соответственно 3.8 с и 2.6 с. Однако в случае приложения fixmeet.ru с временем визуализации контента в 1.4 с, разработанный программный продукт немного уступает по данному параметру.

Косвенные данные по конкурентам, полученные через анализ фронтенд-метрик, указывают на системные проблемы их серверной инфраструктуры. Медленные показатели LCP (до 3.1 с у afisha.timepad.ru) и TBT (590 мс у afisha.timepad.ru) свидетельствуют либо о недостаточной вычислительной мощности серверов, либо о недостаточно оптимизированных запросах к базе данных. Высокие значения параметра CLS у конкурентов (до 1,05 c у afisha.timepad.ru) может быть связано с неравномерной скоростью отдачи контента различными серверными компонентами. Также показательно сравнение с fixmeet.ru: при относительно быстром открытии контента FCP (0.6 с) и TBT (1.160 мс) — время загрузки самого большого визуального элемента сайта (LCP) достигает 2.1 с, что указывает на проблемы с асинхронной обработкой запросов или неравномерной нагрузкой на серверные компоненты.

Заключение

В статье представлен новый программный продукт — веб-приложение для организации мероприятий. Реализованная трехуровневая архитектура с использованием Java Spring Boot и PostgreSQL обеспечивает масштабируемость и надежность системы.

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

Литература:

1. TimePad: сервис организации событий: [сайт]. — Разд. сайта «Афиша». — URL: https://afisha.timepad.ru/ (дата обращения: 09.09.2025). — Текст: электронный.
2. Fixmeet: онлайн-сервис поиска мастеров: [сайт]. — URL: https://fixmeet.ru/ (дата обращения: 09.09.2025). — Текст: электронный.
3. Pognali: сервис для поиска попутчиков: [сайт]. — URL: https://pognali.ru/ (дата обращения: 09.09.2025). — Текст: электронный.
4. Authorization. Spring Security Documentation: [сайт]. — URL: https://docs.spring.io/spring-security/site/docs/5.2.x/reference/html/authorization.html (дата обращения: 09.09.2025). — Текст: электронный.
5. Primer Spring AOP: аспекты, советы, пойнткаты, джоинпойнты, аннотации: [блог]. — URL: https://arenda-server.cloud/blog/primer-spring-aop-aspekty-sovety-pointkaty-dzhoinpointy-annotacii/ (дата обращения: 09.09.2025). — Текст: электронный.
6. Yayauheny. MapStruct — смаппь меня, если сможешь // Хабр. — 2024. — 30 мая. — URL: https://habr.com/ru/articles/818489/ (дата обращения: 09.09.2025). — Текст: электронный.
7. Testcontainers: [сайт]. — LeanTech. — URL: https://leantech.ai/testcontainers (дата обращения: 09.09.2025). — Текст: электронный.
8. Отчет о проверке сайта afisha.timepad.ru: [сайт]. — Dubkov.org. — URL: https://dubkov.org/report/afisha.timepad.ru/ (дата обращения: 09.09.2025). — Текст: электронный.
9. Отчет о проверке сайта pognali.ru: [сайт]. — Dubkov.org. — URL: https://dubkov.org/report/pognali.ru/ (дата обращения: 09.09.2025). — Текст: электронный.
10. Отчет о проверке сайта fixmeet.ru: [сайт]. — Dubkov.org. — URL: https://dubkov.org/report/fixmeet.ru/ (дата обращения: 09.09.2025). — Текст: электронный.