Цель дипломного проекта - разработать фронтенд- и бэкенд-части для сайта-агрегатора с реализацией возможности бронирования гостиниц на диапазон дат. Проект подытожит навыки, которые вы получили в рамках прохождения курса, этот проект вы сможете добавить в свое портфолио разработчика.
Во время выполнения дипломного проекта вы закрепите умения в веб-разработке, разработав следующие элементы веб-сайта:
- пользовательский интерфейс
- публичный API
- API пользователя
- API администратора
- чат консультанта
- Чеклист готовности к работе над проектом
- Инструкция к работе над проектом
- Общие требования к интерфейсу приложения
- Инструменты и дополнительные материалы для выполнения задания
- Роадмап
- Рекомендации по работе над дипломом
- Правила сдачи работы
- Критерии оценки
- 1. Описание базовых модулей
- 1.1. Модуль «Пользователи»
- 1.2. Модуль «Гостиницы»
- 1.3. Модуль «Брони»
- 1.4. Модуль «Чат техподдержки»
- 2. Описание модулей WEB API
- 2.1.1. Поиск номеров
- 2.1.2. Информация о конкретном номере
- 2.1.3. Добавление гостиницы
- 2.1.4. Получение списка гостиниц
- 2.1.5. Изменение описания гостиницы
- 2.1.6. Добавление номера
- 2.1.7. Изменение описания номера
- 2.2. API Модуля «Бронирование»
- 2.2.1. Бронирование номера клиентом
- 2.2.2. Список броней текущего пользователя
- 2.2.3. Отмена бронирования клиентом
- 2.2.4. Список броней конкретного пользователя
- 2.2.5. Отмена бронирования менеджером
- 2.3. API Модуля «Аутентификация и авторизация»
- 2.3.1. Вход
- 2.3.2. Выход
- 2.3.3. Регистрация
- 2.4. API Модуля «Управление пользователями»
- 2.4.1. Создание пользователя
- 2.4.2. Получение списка пользователей
- 2.5. API модуля «Чат с техподдержкой»
- 2.5.1. Создание обращения в поддержку
- 2.5.2. Получение списка обращений в поддержку для клиента
- 2.5.3. Получение списка обращений в поддержку для менеджера
- 2.5.4. Получение истории сообщений из обращения в техподдержку
- 2.5.5. Отправка сообщения
- 2.5.6. Отправка события, что сообщения прочитаны
- 2.5.7. Подписка на сообщения из чата техподдержки
- Запуск приложения
Убедитесь, что совместимы и корректно работают последние версии фреймворков и библиотек:
- React
- Redux
- React Router
- Node.js
- Nest.js
- MongoDB
- WebSocket
В проекте рекомендуется использовать версии фреймворков и библиотек, актуальные на момент ведения разработки, например, NodeJS не ниже 18.0, React не ниже 18.0, WebPack не ниже 5.0.
- Работа над проектом ведется с использованием системы контроля версий Git с публикацией результатов в публичном репозитории(ях) автора на Github.com.
- Публиковаться в репозиторий должны не только окончательные версии файлов, но и промежуточные результаты с возможным тегированием стадий разработки.
- Возможно опубликование проекта как в едином монорепозитории содержащем код бэкенда и фронтенда, так и в двух отдельных репозиториях. Разбиение кода на большее количество репозиториев (например, с выделением библиотек и модулей) не рекомендуется, т.к. это существенно усложнит работу на стадиях разработки, развёртывания и проверки результатов.
- Допускается использование дополнительных инструментов и модулей, не перечисленных в данном задании, если это необходимо для реализации требуемой функциональности и существенно не усложняет ведение проекта и его дальнейшее развёртывание на открытых платформах.
- Не допускается использование библиотек и инструментов, требующих оплаты или заключения лицензионных договоров при своем использовании в открытых проектах такого масштаба.
- Не допускается использование в проекте дополнительных ресурсов, которые потребуют существенных трудовых и финансовых затрат на их организацию и развёртывание при проверке работоспособности проекта.
- Должна быть максимально использована концепция SPA (single page application), т.е. весь переменный контент на странице (списки пользователей и файлов и т.п.) должен формироваться кодом на JavaScript с использованием библиотеки React. Для получения данных должны использоваться асинхронные api-вызовы к серверу приложения;
- Все страницы приложения должны содержать навигационное меню, формируемое в зависимости от состояния аутентификации пользователя (кнопки «Вход», «Выход» и «Регистрация»).
Последние версии Chrome, Firefox, Opera, Safari.
Реализация адаптивности не обязательно. По желанию можно реализовать адаптацию к мобильным устройствам и планшетам. Также по желанию можно реализовать «резину».
- Реализация защиты от XSS-атак
- Безопасность передачи паролей
Оплату бронирования реализовывать не нужно.
В документе приводятся описания разных интерфейсов и типов. Для упрощения описания в этом разделе приводятся общие типы.
type ID = string | ObjectId;
- Интерфейс может быть реализован по вашему усмотрению. Время, отводимое на дипломную работу, не предполагает существенных усилий по оформлению приложения. Ознакомьтесь с нашим предложением по интерфейсу по ссылке: Визуальная часть проекта
- По желанию вы можете использовать CSS фреймворки типа Bootstrap, любой Material Design или какой вам интересен (при использовании фреймворка укажите это в Readme.md файле своего проекта). Главное, чтобы интерфейс приложения был логичным и интуитивно понятным пользователю.
Работа над проектом рассчитана на 1 месяц. Для планирования своего времени рекомендуется разбить блоки работы в равных пропорциях на этот период времени. Вы можете начать как с backend части, и потом перейти в frontend, так и работать по модулям, делая сразу и frontend модуля, и backend.
Отправляйте проект на проверку дипломному руководителю поэтапно, чтобы избежать больших правок и более оперативно получать обратную связь от вашего руководителя.
Мы предлагаем такое деление проекта на этапы и задачи:
1 неделя - модуль «Пользователи»
2 неделя - модуль «Гостиницы»
3 неделя - модули «Брони», «Аутентификация и авторизация»
4 неделя - модуль «Чат техподдержки», оформление документации
5 неделя - получение обратной связи от руководителя, при необходимости доработка проекта с повторной проверкой.
- Не откладывайте надолго начало работы над дипломом. В таком случае у вас останется больше времени на получение рекомендаций от руководителя и доработку диплома.
- Разбейте работу над дипломом на части и выполняйте их поочерёдно. Вы будете успевать учитывать комментарии от руководителя и не терять мотивацию на полпути.
- Опубликуйте все изменения в файлах проекта в публичном(ых) репозитории(ях) на github.com. Убедитесь, что репозитории содержат действительно последние версии со всеми изменениями.
- Попробуйте самостоятельно полностью с нуля развернуть приложение, следуя инструкции, описанной вами в README.md. Убедитесь, что приложение разворачивается успешно и работоспособно, протестируйте основные функции.
- Приложите в личном кабинете ссылки на репозиторий(ии) и развёрнутое приложение либо указание, что приложение может быть развёрнуто вами в течение не более 1 рабочего дня по запросу проверяющего.
- Отправьте дипломную работу на проверку.
- В случае возвращения работы на доработку и устранения замечаний выполните необходимые действия в короткий срок и повторно сдайте работу на проверку. В случае необходимости уточнения и каких-либо вопросов, связанных с результатом проверки, свяжитесь с руководителем вашей дипломной работы.
-
Результаты работы должны быть сданы в виде ссылок на публичный(е) репозиторий(и) с кодом на github.com.
-
В корневой папке репозиториев должны обязательно содержаться файлы README.md с детальным описанием структуры папок и файлов проекта, а также инструкции по его развёртыванию и запуску, достаточно подробные для выполнения специалистом, прошедшим обучение по профессии.
-
В случае использования дополнительных инструментов, которые не изучались в программе профессии, должны быть приложены ссылки на документацию по их установке и использованию.
-
В случае опубликования кода фронтенда и бэкенда в раздельных репозиториях общие инструкции по развёртыванию приложения должны быть описаны в README.MD в репозитории с бэкендом, в репозитории с фронтендом должны быть инструкции по сборке и подготовке артефактов фронтенда, которые необходимы для развёртывания.
-
В связи с тем, что профессия Fullstack-разработчика предполагает владение всеми технологиями, используемыми при разработке комплексных приложений с пользовательским интерфейсом, оценке подлежит также удобство пользования приложением. Недостатки, ведущие к существенным трудностям в работе пользователя с приложением могут быть основанием для отправки работы на доработку и устранением замечаний.
Базовые модули используются для описания бизнес-логики и хранения данных.
Модуль «Пользователи» предназначается для создания, хранения и поиска профилей пользователей.
Модуль «Пользователи» используется функциональными модулями для регистрации и аутентификации.
Данные пользователя должны храниться в MongoDB.
Модель данных User
пользователя должна содержать поля:
Название | Тип | Обязательное | Уникальное | По умолчанию |
---|---|---|---|---|
_id | ObjectId |
да | да | |
string |
да | да | ||
passwordHash | string |
да | нет | |
name | string |
да | нет | |
contactPhone | string |
нет | нет | |
role | string |
да | нет | client |
Модуль «Пользователи» должен быть реализован в виде NestJS-модуля и экспортировать сервисы с интерфейсами:
interface SearchUserParams {
limit: number;
offset: number;
email: string;
name: string;
contactPhone: string;
}
interface IUserService {
create(data: Partial<User>): Promise<User>;
findById(id: ID): Promise<User>;
findByEmail(email: string): Promise<User>;
findAll(params: SearchUserParams): Promise<User[]>;
}
Поле role
может принимать одно из значений:
client
,admin
,manager
.
При поиске IUserService.findAll()
поля email
, name
и contactPhone
должны проверяться на частичное совпадение.
Модуль «Гостиницы» предназначается для хранения и поиска гостиниц и комнат.
Модуль «Гостиницы» используется функциональными модулями для показа списка мест для бронирования, а также для их добавления, включения и выключения.
Данные должны храниться в MongoDB.
Модель данных Hotel
должна содержать поля:
Название | Тип | Обязательное | Уникальное | По умолчанию |
---|---|---|---|---|
_id | ObjectId |
да | да | |
title | ObjectId |
да | нет | |
description | string |
нет | нет | |
createdAt | Date |
да | нет | |
updatedAt | Date |
да | нет |
Модель данных HotelRoom
должна содержать поля:
Название | Тип | Обязательное | Уникальное | По умолчанию |
---|---|---|---|---|
_id | ObjectId |
да | да | |
hotel | ObjectId |
да | нет | |
description | string |
нет | нет | |
images | string[] |
нет | нет | [] |
createdAt | Date |
да | нет | |
updatedAt | Date |
да | нет | |
isEnabled | boolean |
да | нет | true |
Свойство hotel
должно ссылаться на модель Hotel
.
Модуль «Гостиницы» должен быть реализован в виде NestJS-модуля и экспортировать сервисы с интерфейсами:
interface SearchHotelParams {
limit: number;
offset: number;
title: string;
}
interface UpdateHotelParams {
title: string;
description: string;
}
interface IHotelService {
create(data: any): Promise<Hotel>;
findById(id: ID): Promise<Hotel>;
search(params: SearchHotelParams): Promise<Hotel[]>;
update(id: ID, data: UpdateHotelParams): Promise<Hotel>;
}
interface SearchRoomsParams {
limit: number;
offset: number;
hotel: ID;
isEnabled?: boolean;
}
interface HotelRoomService {
create(data: Partial<HotelRoom>): Promise<HotelRoom>;
findById(id: ID): Promise<HotelRoom>;
search(params: SearchRoomsParams): Promise<HotelRoom[]>;
update(id: ID, data: Partial<HotelRoom>): Promise<HotelRoom>;
}
В методе search
флаг isEnabled
может принимать только boolean значения или может быть не передан, тогда должны вернутся все записи:
true
— флаг должен использоваться в фильтрации;undefined
— если не передан параметр, флаг должен игнорироваться.
Модуль «Брони» предназначен для хранения и получения броней гостиниц конкретного пользователя.
Модуль «Брони» не должен использовать модуль «Пользователи» и модуль «Гостиницы» для получения данных.
Модуль «Брони» не должен хранить данные пользователей и гостиниц.
Модуль «Брони» должен использовать соединение с базой данных.
Данные должны храниться в MongoDB.
Модель данных Reservation
должна содержать поля:
Название | Тип | Обязательное | Уникальное | По умолчанию |
---|---|---|---|---|
_id | ObjectId |
да | да | |
userId | ObjectId |
да | нет | |
hotelId | ObjectId |
да | нет | |
roomId | ObjectId |
да | нет | |
dateStart | Date |
да | нет | |
dateEnd | Date |
да | нет |
Модуль «Брони» должен быть реализован в виде NestJS-модуля и экспортировать сервисы с интерфейсами:
interface ReservationDto {
userId: ID;
hotelId: ID;
roomId: ID;
dateStart: Date;
dateEnd: Date;
}
interface ReservationSearchOptions {
userId: ID;
dateStart: Date;
dateEnd: Date;
}
interface IReservation {
addReservation(data: ReservationDto): Promise<Reservation>;
removeReservation(id: ID): Promise<void>;
getReservations(
filter: ReservationSearchOptions
): Promise<Array<Reservation>>;
}
Метод IReservation.addReservation
должен проверять, доступен ли номер на заданную дату.
Модуль «Чат техподдержки» предназначается для хранения обращений в техподдержку и сообщений в чате обращения.
Модуль «Чат техподдержки» используется функциональными модулями для реализации возможности общения пользователей с поддержкой.
Данные чатов должны храниться в MongoDB.
Модель данных чата SupportRequest
должна содержать поля:
Название | Тип | Обязательное | Уникальное |
---|---|---|---|
_id | ObjectId |
да | да |
user | ObjectId |
да | нет |
createdAt | Date |
да | нет |
messages | Message[] |
нет | нет |
isActive | bool |
нет | нет |
Модель сообщения Message
должна содержать поля:
Название | Тип | Обязательное | Уникальное |
---|---|---|---|
_id | ObjectId |
да | да |
author | ObjectId |
да | нет |
sentAt | Date |
да | нет |
text | string |
да | нет |
readAt | Date |
нет | нет |
Сообщение считается прочитанным, когда поле readAt
не пустое.
Модуль «Чат техподдержки» должен быть реализован в виде NestJS-модуля и должен экспортировать сервисы с интерфейсами:
interface CreateSupportRequestDto {
user: ID;
text: string;
}
interface SendMessageDto {
author: ID;
supportRequest: ID;
text: string;
}
interface MarkMessagesAsReadDto {
user: ID;
supportRequest: ID;
createdBefore: Date;
}
interface GetChatListParams {
user: ID | null;
isActive: bool;
}
interface ISupportRequestService {
findSupportRequests(params: GetChatListParams): Promise<SupportRequest[]>;
sendMessage(data: SendMessageDto): Promise<Message>;
getMessages(supportRequest: ID): Promise<Message[]>;
subscribe(
handler: (supportRequest: SupportRequest, message: Message) => void
): () => void;
}
interface ISupportRequestClientService {
createSupportRequest(data: CreateSupportRequestDto): Promise<SupportRequest>;
markMessagesAsRead(params: MarkMessagesAsReadDto);
getUnreadCount(supportRequest: ID): Promise<Message[]>;
}
interface ISupportRequestEmployeeService {
markMessagesAsRead(params: MarkMessagesAsReadDto);
getUnreadCount(supportRequest: ID): Promise<Message[]>;
closeRequest(supportRequest: ID): Promise<void>;
}
- Метод
ISupportRequestClientService.getUnreadCount
должен возвращать количество сообщений, которые были отправлены любым сотрудником поддержки и не отмечены прочитанным. - Метод
ISupportRequestClientService.markMessagesAsRead
должен выставлять текущую дату в поле readAt всем сообщениям, которые не были прочитаны и были отправлены не пользователем. - Метод
ISupportRequestEmployeeService.getUnreadCount
должен возвращать количество сообщений, которые были отправлены пользователем и не отмечены прочитанными. - Метод
ISupportRequestEmployeeService.markMessagesAsRead
должен выставлять текущую дату в поле readAt всем сообщениям, которые не были прочитаны и были отправлены пользователем. - Метод
ISupportRequestEmployeeService.closeRequest
должен менять флагisActive
наfalse
. - Оповещения должны быть реализованы через механизм
EventEmitter
.
Бэкенд должен быть оформлен в виде отдельного NestJS-модуля.
Если пользователь не аутентифицирован или его роль client
, то при поиске всегда должен использоваться флаг isEnabled: true
.
Обязательные поля:
- Заезд
- Выезд
Выдача результатов поиска.
На одной странице отображается 10 отелей. Если найдено менее 10 отелей, пагинация не отображается. При переходе на следующую страницу пагинации, происходит прокрутка вверх к первому результату.
GET /api/common/hotel-rooms
- limit — количество записей в ответе;
- offset — сдвиг от начала списка;
- hotel — ID гостиницы для фильтра.
[
{
"id": string,
"description": string,
"images": [string],
"hotel": {
"id": string,
"title": string
}
}
]
Доступно всем пользователям, включая неаутентифицированных.
Получение подробной информации о номере.
GET /api/common/hotel-rooms/:id
Отсутствуют.
{
"id": string,
"description": string,
"images": [string],
"hotel": {
"id": string,
"title": string,
"description": string
}
}
Доступно всем пользователям, включая неаутентифицированных.
Добавление гостиницы администратором.
POST /api/admin/hotels/
{
"title": string,
"description": string
}
{
"id": string,
"title": string,
"description": string
}
Доступно только аутентифицированным пользователям с ролью admin
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неadmin
.
Получение списка гостиниц администратором.
GET /api/admin/hotels/
- limit - количество записей в ответе;
- offset - сдвиг от начала списка.
{
"id": string,
"title": string,
"description": string
}
Доступно только аутентифицированным пользователям с ролью admin
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неadmin
.
Изменение описания гостиницы администратором.
Страница редактирования гостиницы заполненная: Изображения можно менять местами перетаскиванием. Перетаскивание меняет порядок отображения на странице гостиницы. Кнопка добавления фото после добавления 10 фото исчезает. Любое добавленное фото можно удалить. Превью фото должно быть оптимизировано по размеру превью. По клику на добавленное фото, в модальном окне отображается полноразмерное фото. Клик по кнопке Сохранить приводит к возврату на страницу гостиницы. Клик по кнопке Отменить приводит к возврату на страницу гостиницы.
Страница редактирования гостиницы пустая: Обязательные поля:
- Фото (минимум одно, максимум 10), максимальный объем 10Мб, минимальная ширина фото 1000пикселей, максимальный размер фото 5000 пикселей по любой из сторон, допустимые форматы: png, jpg, jpeg, webp
- Название (минимум 5 символов)
- Описание (минимум 100 символов)
Кнопке Сохранить до прохождения валидации присвоено состояние disabled.
Клик по кнопке Редактировать приводит к переходу на страницу редактирования гостиницы. Высота изображений одинакова, даже если загружены фото разной высоты. Ширина подстраивается. Отображается первое фото гостиницы. Кнопка Подробнее ведет на страницу отеля.
PUT /api/admin/hotels/:id
{
"title": string,
"description": string
}
{
"id": string,
"title": string,
"description": string
}
Доступно только аутентифицированным пользователям с ролью admin
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неadmin
.
Добавление номера гостиницы администратором.
POST /api/admin/hotel-rooms/
Этот запрос предполагает загрузку файлов и должен использовать формат multipart/form-data
.
description: string
hotelId: string
images[]: File
{
"id": string,
"description": string,
"images": [string],
"isEnabled": boolean,
"hotel": {
"id": string,
"title": string,
"description": string
}
}
Доступно только аутентифицированным пользователям с ролью admin
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неadmin
.
Изменение описания номера гостиницы администратором.
PUT /api/admin/hotel-rooms/:id
Этот запрос предполагает загрузку файлов и дожен использовать формат multipart/form-data
.
description: string
hotelId: string
isEnabled: boolean
images[]: File | string
При обновлении может быть отправлен одновременно список ссылок на уже загруженные картинки и список файлов с новыми картинками.
При использовании multer
список загруженных файлов можно получить через @UploadedFiles()
. Этот список нужно объединить со списком, который пришёл в body
.
{
"id": string,
"description": string,
"images": [string],
"isEnabled": boolean,
"hotel": {
"id": string,
"title": string,
"description": string
}
}
Доступно только аутентифицированным пользователям с ролью admin
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неadmin
.
Должно быть оформлено в виде отдельного NestJS-модуля.
Создаёт бронь на номер на выбранную дату для текущего пользователя.
POST /api/client/reservations
{
"hotelRoom": string,
"startDate": string,
"endDate": string
}
{
"startDate": string,
"endDate": string,
"hotelRoom": {
"description": string,
"images": [string]
},
"hotel": {
"title": string,
"description": string
}
}
Доступно только аутентифицированным пользователям с ролью client
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неclient
;400
- если номера с указанным ID не существует или он отключён.
Список броней текущего пользователя.
GET /api/client/reservations
[
{
"startDate": string,
"endDate": string,
"hotelRoom": {
"description": string,
"images": [string]
},
"hotel": {
"title": string,
"description": string
}
}
]
Доступно только аутентифицированным пользователям с ролью client
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неclient
.
Отменяет бронь пользователя.
DELETE /api/client/reservations/:id
Пустой ответ.
Доступно только аутентифицированным пользователям с ролью client
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неclient
;403
- еслиID
текущего пользователя не совпадает сID
пользователя в брони;400
- если брони с указанным ID не существует.
Список броней конкретного пользователя.
GET /api/manager/reservations/:userId
[
{
"startDate": string,
"endDate": string,
"hotelRoom": {
"description": string,
"images": [string]
},
"hotel": {
"title": string,
"description": string
}
}
]
Доступно только аутентифицированным пользователям с ролью manager
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неmanager
.
Отменяет бронь пользователя по id брони.
DELETE /api/manager/reservations/:id
Пустой ответ.
Доступно только аутентифицированным пользователям с ролью manager
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неmanager
;400
- если брони с указанным ID не существует.
Должно быть оформлено в виде отдельного NestJS-модуля.
Модуль «Аутентификация и авторизация» предназначен для:
- управления сессией пользователя,
- регистрации пользователей.
Хранение сессии должно реализовываться посредством библиотеки passport.js с хранением сессии в памяти приложения.
Аутентификация пользователя производится с помощью модуля «Пользователи». Каждому пользователю назначается одна из ролей - клиент, администратор, консультант.
Стартует сессию пользователя и выставляет Cookies.
POST /api/auth/login
{
"email": string,
"password": string
}
{
"email": string,
"name": string,
"contactPhone": string
}
Доступно только не аутентифицированным пользователям.
401
- если пользователя с указанным email не существует или пароль неверный.
Завершает сессию пользователя и удаляет Cookies.
POST /api/auth/logout
Пустой ответ.
Доступно только аутентифицированным пользователям.
Позволяет создать пользователя с ролью client
в системе.
POST /api/client/register
{
"email": string,
"password": string,
"name": string,
"contactPhone": string
}
{
"id": string,
"email": string,
"name": string
}
Доступно только не аутентифицированным пользователям.
400
- если email уже занят.
Позволяет пользователю с ролью admin
создать пользователя в системе.
POST /api/admin/users/
{
"email": string,
"password": string,
"name": string,
"contactPhone": string,
"role": string
}
{
"id": string,
"email": string,
"name": string,
"contactPhone": string,
"role": string
}
Доступно только пользователям с ролью admin
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя неadmin
.
Позволяет пользователю с ролью admin
создать пользователя в системе.
GET /api/admin/users/
GET /api/manager/users/
- limit - количество записей в ответе;
- offset - сдвиг от начала списка;
- name - фильтр по полю;
- email - фильтр по полю;
- contactPhone - фильтр по полю.
[
{
"id": string,
"email": string,
"name": string,
"contactPhone": string
}
]
GET /api/admin/users/
Доступно только пользователям с ролью admin
.
GET /api/manager/users/
Доступно только пользователям с ролью manager
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя не подходит.
Позволяет пользователю с ролью client
создать обращение в техподдержку.
POST /api/client/support-requests/
{
"text": string
}
[
{
"id": string,
"createdAt": string,
"isActive": boolean,
"hasNewMessages": boolean
}
]
Доступно только пользователям с ролью client
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя не подходит.
Позволяет пользователю с ролью client
получить список обращений для текущего пользователя.
GET /api/client/support-requests/
- limit - количество записей в ответе;
- offset - сдвиг от начала списка;
- isActive - фильтр по полю.
[
{
"id": string,
"createdAt": string,
"isActive": boolean,
"hasNewMessages": boolean
}
]
Доступно только пользователям с ролью client
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя не подходит.
Позволяет пользователю с ролью manager
получить список обращений от клиентов.
GET /api/manager/support-requests/
- limit - количество записей в ответе;
- offset - сдвиг от начала списка;
- isActive - фильтр по полю.
[
{
"id": string,
"createdAt": string,
"isActive": boolean,
"hasNewMessages": boolean,
"client": {
"id": string,
"name": string,
"email": string,
"contactPhone": string
}
}
]
Доступно только пользователям с ролью manager
.
401
- если пользователь не аутентифицирован;403
- если роль пользователя не подходит.
Позволяет пользователю с ролью manager
или client
получить все сообщения из чата.
GET /api/common/support-requests/:id/messages
[
{
"id": string,
"createdAt": string,
"text": string,
"readAt": string,
"author": {
"id": string,
"name": string
}
}
]
Доступно только пользователям с ролью manager
и пользователю с ролью client
, который создал обращение.
401
- если пользователь не аутентифицирован;403
- если роль пользователя не подходит.
Позволяет пользователю с ролью manager
или client
отправлять сообщения в чат.
POST /api/common/support-requests/:id/messages
{
"text": string
}
[
{
"id": string,
"createdAt": string,
"text": string,
"readAt": string,
"author": {
"id": string,
"name": string
}
}
]
Доступно только пользователям с ролью manager
и пользователю с ролью client
, который создал обращение.
401
- если пользователь не аутентифицирован;403
- если роль пользователя не подходит.
Позволяет пользователю с ролью manager
или client
отправлять отметку, что сообщения прочитаны.
POST /api/common/support-requests/:id/messages/read
{
"createdBefore": string
}
{
"success": true
}
Доступно только пользователям с ролью manager
и пользователю с ролью client
, который создал обращение.
401
- если пользователь не аутентифицирован;403
- если роль пользователя не подходит.
Позволяет пользователю с ролью manager
или client
получать новые сообщения в чате через WebSocket.
message: subscribeToChat payload: chatId
{
"id": string,
"createdAt": string,
"text": string,
"readAt": string,
"author": {
"id": string,
"name": string
}
}
Доступно только пользователям с ролью manager
и пользователю с ролью client
, который создал обращение.
Для запуска приложения в корне проекта должны находиться следующие файлы:
package.json
иpackage-lock.json
с описанными зависимостями,Dockerfile
для сборки образа приложения,docker-compose.yaml
с сервисом приложения и сервисом MondoDB,README.me
с описанием проекта и вариантами его запуска.
Настройка параметров приложения должна производиться через переменные окружения. Это требование как для запуска в окружении хоста, так и при работе с Docker.
Список переменных окружения должен быть описан в файле .env-example
. Этот файл не должен содержать значений. Пример файла:
HTTP_HOST=
HTTP_PORT=
MONGO_URL=
Для запуска приложения должен использоваться скрипт npm start
, описанный в package.json
.