Cal.com — Backend часть #263
Description
Связанное
- Поднять docker-compose с calcom #386
- Добавить автоматическую регистрацию пользователя в calcom #388
- Добавить метод получения session-token из calcom #389
Описание
Как и обсуждали с тобой, Серег, далее описал основную бизнес-логику по бронированию сессий
(+ допчик по бэк логике, на всякий случай)
Бизнес-логика для юзеров:
-
Настройка профиля ученика:
После регистрации ученик должен настроить свой профиль, включая интеграцию с Google Календарем. -
Бронирование сессии:
Когда ученик выбирает наставника, он может забронировать сессию на дату и время, соответствующие графику доступности наставника. Система должна автоматически учитывать часовой пояс как ученика, так и наставника при бронировании. -
Подтверждение бронирования:
После бронирования ученик получает подтверждение вместе с деталями сессии. Это также обновляется в его интегрированном Google Календаре. -
Изменение времени сессии:
Если ученик хочет перенести сессию, он может сделать это, если до сессии осталось более 36 часов. Он предлагает новое время в рамках доступности наставника. -
Обработка предложений об изменении времени:
Если наставник предлагает новое время для сессии, ученик может принять его или предложить другое время.
Бизнес-логика для менторов:
-
Настройка профиля наставника:
После регистрации наставники настраивают свой профиль, включая график доступности и интеграцию с Google Календарем. -
Получение и подтверждение бронирований:
Наставники получают запросы на бронирование сессий от учеников. Они могут подтверждать эти бронирования, которые затем обновляются в их интегрированном Google Календаре. -
Перенос сессии:
Если наставник хочет перенести сессию, он может предложить новое время, если до сессии осталось более 36 часов. Он должен убедиться, что новое время все еще входит в его график доступности, если это не особый случай. -
Обработка предложений об изменении времени:
Если ученик предлагает новое время для сессии, наставник может принять его или предложить другое время. -
Переопределение основного графика:
В исключительных случаях наставник может переопределить свой основной график, чтобы принять бронирование сессии вне своих обычных часов.
Дополнительные случаи
-
Отмена сессии:
И ученики, и наставники должны иметь возможность отменить сессию. Система должна определить правила для отмены, такие как штрафы, если отмена происходит менее чем за 36 часов до сессии, и т. д. -
Уведомления:
Как наставники, так и ученики должны получать напоминания о сессии на своей платформе и в Google Календаре. Они должны быть отправлены за 48 часов до сессии и затем последнее напоминание за час до начала сессии.
⬇️ ⬇️ ⬇️
Backend логика:
Логика бронирования:
-
Получение доступности наставника:
Когда ученик выбирает наставника, серверная часть должна получить доступность наставника из базы данных и преобразовать ее в часовой пояс ученика. Для получения доступности можно использовать API Cal.com, который синхронизирован с календарем наставника в Google. -
Бронирование сессии:
Когда ученик выбирает дату и время, серверная часть должна отправить POST-запрос для создания новой записи о сессии в базе данных. Тело запроса должно содержать необходимые данные, включая id юзера, id ментора, время сессии, стоимость и т.д.
На этом этапе API Cal.com должен быть обновлен для отражения этого бронирования в календарях как наставника, так и ученика в Google. -
Изменение времени сессии:
Если сессию нужно перенести, серверная часть должна обработать PUT-запрос для обновления записи о сессии в базе данных. -
Обработка предложений об изменении времени:
Когда пользователь предлагает новое время для сессии, серверная часть должна отправить PATCH-запрос для обновления поля "proposed_time" в записи о сессии и отправить уведомление другому пользователю (см. логику уведомлений ниже). -
Переопределение основного графика:
Если наставник переопределяет свой основной график, должен быть сделан PATCH-запрос для обновления доступности наставника в базе данных. API Cal.com должен быть обновлен для отражения этого изменения в календаре Google.
Логика уведомлений:
-
Подтверждение бронирования:
После успешного бронирования серверная часть должна инициировать уведомление как для ученика, так и для наставника. Это должно быть сделано по электронной почте + через уведомления в приложении (для начала можем юзать только почту). -
Изменение времени сессии:
Если сессия переносится или предлагается новое время, должно быть инициировано уведомление другому пользователю. Это также должно включать запрос пользователю на принятие нового времени или предложение другого времени. (опять же, можно по идее добавлять ссылки сразу внутрь писем — полагаю, что в Cal.com уже и так есть такая функциональность — нужно проверить) -
Предложения об изменении времени:
Аналогично, когда делается предложение об изменении времени, серверная часть должна инициировать уведомление другой стороне, участвующей в сессии. -
Предварительные оповещения перед сессией:
Серверная часть должна отправлять напоминания о предстоящих сессиях. Они должны быть отправлены за 48 часа и за 1 час до начала сессии. Эти уведомления также должны быть обновлены в календаре Google через API Cal.com.
Соображения для серверной части: — ну ещё довесок от ChatGPT 😁
-
Согласованность данных:
Обеспечьте согласованность данных между вашей базой данных и календарем Google через API Cal.com. Любое изменение времени сессии, доступности пользователя или отмены сессии должно точно отражаться на обеих сторонах. -
Преобразование часового пояса:
Учитывайте часовые пояса обоих пользователей при получении и обновлении доступности и при планировании сессий. Это может быть сложно, особенно учитывая переход на летнее время. -
Обработка ошибок:
Будьте готовы обрабатывать различные исключительные ситуации, такие как сбои в API, и разработайте серверную часть таким образом, чтобы она грациозно обрабатывала такие сценарии. Реализуйте логику повтора для временных сбоев и предоставьте понятные сообщения об ошибках для обработки на стороне клиента. -
Ограничение скорости API:
API Cal.com может иметь ограничение скорости. Разработайте ваш сервис таким образом, чтобы он обрабатывал такие сценарии, возможно, ставя запросы в очередь и обрабатывая и