Генерируем миграции

Чтобы сгенерировать миграции, требуется два состояния: желаемое (которое мы описали объектами SQLAlchemy) и реальное (база данных, в нашем случае пустая). Я решил, что проще всего поднять Postgres с помощью Docker и для удобства добавил команду make postgres, запускающую в фоновом режиме контейнер с PostgreSQL на 5432 порту

Рисунок 16 – Поднимаем PostgreSQL и генерируем миграцию

Alembic в целом хорошо справляется с рутинной работой генерации миграций, но я хотел бы обратить внимание на следующее:

• Пользовательские типы данных, указанные в создаваемых таблицах, создаются автоматически (в нашем случае — gender), но код для их удаления в downgrade не генерируется. Если применить, откатить и потом еще раз применить миграцию, это вызовет ошибку, так как указанный тип данных уже существует.

Рисунок 17 – Удаляем тип данных gender в методе downgrade

• В методе downgrade некоторые действия иногда можно убрать (если мы удаляем таблицу целиком, можно не удалять ее индексы отдельно):

def downgrade():

op.drop_table('relations')

# Следующим шагом мы удаляем таблицу citizens, индекс будет удален автоматически

# эту строчку можно удалить

op.drop_index(op.f('ix__citizens__town'), table_name='citizens')

op.drop_table('citizens')

op.drop_table('imports')

Когда миграция исправлена и готова, применим ее

Рисунок 18 – Реализация миграций

Приложение

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

В файле app.py происходит процесс создания экземпляра приложения, после идет подключение к postgres, регистрация обработчиков, далее создается swagger документация, а далее происходит сериализация данных в json формат для дальнейшей передачи данных в http ответах

Рисунок 19 – Код файла “app.py”

Рисунок 20– Код файла “app.py”

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

Рисунок 21– Код файла “main.py”

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

Чтобы логи не блокировали основной поток во время операции записи в stderr или в файл, я буферизирую логи и обрабатываю их в отдельном потоке ( при помощи aiomisc.basic config – настраивает автоматически буферизацию)

Далее выделяю память сокету из под привилегированного пользователя отдельным шагом, чтобы была возможность перед запуском приложения сменить пользователя ОС.

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

А далее я просто создаю приложения при помощи функции create_app из файла «app.py» и запускаю его

Рисунок 21– Код файла “_main_.py”

Сериализация данных

Все успешные ответы обработчиков будем возвращать в формате JSON. Информацию об ошибках клиентам тоже было бы удобно получать в сериализованном виде (например, чтобы увидеть, какие поля не прошли валидацию).

Поэтому реализую ряд методов:

“convert” – функция которая будет вызываться для обработки не сериализуемых

в JSON объектов . Функция должна вернуть либо сериализуемое в JSON значение, либо исключение TypeError

“convert_asyncpg_record” – Позволяет автоматически сериализовать результаты запроса, возвращаемые в asyncpg

“convert_date” – Метод для обработки объекта времени в определенном формате (ДД.ММ.ГГГГ.)

“convert_decimal” – Метод для обработки возвращаемых asyngcpg значений округленных перцентили в виде экземпляров Decimal

Класс “JsonPayload” – Заменяет функцию сериализации на более расширенную, чтобы эта функция умела упаковывать в JSON объекты asyncpg.Record и другие

Рисунок 22– Код конвертеров

Рисунок 23– Код конвертеров

Рисунок 24– Код конвертеров