Calendula

Not a flower, actually, because was written in one week

Бекенд календаря

• Можно создавать встречи
• Можно указывать уведомления для встреч за 50 дней
• Можно указывать участников встречи, но они могут отказаться
• Можно сделать повторяющуюся раз в 20 лет встречу
• Можно принять приглашение или отказаться
• Можно получить одно событие или все события пользователя за определенный период
• Можно просчитать свободное время всех участников для встречи любой продолжительности
• Есть создание сессий и авторизация пользователей по сессии

Так же подключен Swagger (документация API). Описание API можно посмотреть, запустив приложение и открыв localhost:8000/docs

Разработка

Полная описание методов и сущностей: DevDoc.md

Зависимости

Все примеры приведены для локальной установки

Для разработки нужен postgresql

После установки, нужно создать базу:

psql -d postgres
CREATE USER calendar_admin;
ALTER USER calendar_admin WITH PASSWORD 'password';
CREATE DATABASE calendar_db OWNER calendar_admin;
CREATE DATABASE calendar_db_test OWNER calendar_admin;
ALTER SCHEMA calendar_db.public OWNER TO calendar_admin;
ALTER SCHEMA calendar_db_test.public OWNER TO calendar_admin;

Переменные окружения

DEV_MODE=1|0 - режим разработки (по-умолчанию = 0) DB_PASSWORD - пароль к базе (можно указать в переменной окружения вместо конфига)

Конфиг

В репозитории лежит конфиг по-умолчанию (config.yaml)

Конфиг логера по-умолчанию можно найти в lib.config.config

Если DEV_MODE=1, логи имеют формат, разделяемый табами и пишутся в stdout Иначе логи имеют формат json и пишутся в файл (по-умолчанию /logs/calendar.log)

Тестирование

Есть юнит тесты, проверяющие работу каждого метода API

Запускаются при помощи pytest: pytest .

Часть тестов запускается над базой данных (которая чиститься, поэтому рекомендуется для тестов использовать отдельную базу)

Переменные окружения для тестирования:

• POSTGRES_RECIPE_HOST: хосты базы данных
• POSTGRES_RECIPE_PORT: порт базы данных
• POSTGRES_RECIPE_DBNAME: имя базы данных для тестирования
• POSTGRES_RECIPE_USER: имя пользователя
• POSTGRES_RECIPE_PASSWORD: опционально, пароль
• POSTGRES_RECIPE_MAX_CONNECTIONS: максимальное кол-во соединений

При написании асинхронных тестов, их следует оборачивать в декоратор tests/full_wait.pu::full_wait_pending() так как pytest не умеет дожидаться выполнения всех асинхронных задач при вызове теста, этот декоратор позволяет дождаться выполнения всех задач. Если не применить декоратор, в модуле с двумя асинхронными тестами, все кроме первого будут падать.

О работе:

• За основу взят фреймворк FastApi, из коробки имеющий валидацию запросов и Swagger. Он работает через uvicorn (аналог http сервера unicorn, но более быстрый).

• Так же, вместо стандартного асинхронного лупа используется uvloop.

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

• Логгер на продакшене пишет логи в формате json для удобного их сбора.

• Для работы с данными в базе решено не использовать ORM, а оперировать голыми SQL запросами, обернутыми в функции. Так очевиднее, что именно и как каждый раз запрашивается из базы.

• Аутентификация написана самым простейшим возможным образом при помощи id сессии. Для создания сессии нужно выполнить запрос в бекенд, пока без пароля. Так же авторизация выполнена отдельным модулем, чтобы масштабировать ее в будущем (скажем на отдельный микросервис). Пока аутентификация нигде не используется.

TODO:

• Нужно сделать лочки для нотификатора, иначе при работе на нескольких хостах могут быть дублирования. Я пока не успел это сделать.