Привет! В прошлой статье мы познакомились с aiohttp и написали первое веб-приложение: стену с отзывами. Сегодня продолжим изучение и добавим асинхронное взаимодействие с базой данных PostgreSQL. Что будет в статье:  Поднимаем базу данных PostgreSQL в Docker-контейнере Создаем модель данных Работаем с файлами конфигурации приложения Подключаемся к базе данных и пишем свой Accessor Инстанцируем Gino Создаем модель сообщения Генерируем миграцию Alembic: добавляем взаимодействие с базой данных Добавляем новые возможности в интерфейс Материалы и ссылки Курс по асинхронному программированию на Python Эта статья дополняет код первой части — найти его можно здесь. Код для этой части статьи находится в репозитории по ссылке. Если вам интересно асинхронное программирование, приходите к нам на курс в KTS, где мы подробно разберем эту тему. Это подготовительный этап. Мы будем работать с сервером PostgreSQL версии 11 и старше. Так как Docker все равно понадобится вам для последующей публикации приложения в Интернете, то убьем двух зайцев сразу и запустим сервер PostgreSQL в Docker-контейнере.  Устанавливаем Docker c официального сайта: https://docs.docker.com/engine/install/#server.  Docker-контейнеры по умолчанию не хранят данные, поэтому необходимо создать volume, чтобы не потерять данные нашей базы после перезапуска или после остановки контейнера: Теперь запустим нашу базу командой: Мы запустили docker-контейнер с базой данных от имени root-пользователя. Давайте рассмотрим переданные параметры: -e POSTGRES_PASSWORD=forum_password — задали пароль для пользователя базы данных, передав его через переменную окружения в контейнер -e POSTGRES_USER=forum_user — задали имя пользователя базы данных аналогичным способом -p 5432:5432 — опубликовали 5432-ой порт контейнера во внешнюю среду. Подробнее о том, как устроена сеть Docker, можно прочитать тут --mount source=postgres-data,target=/var/lib/postgresql — примонтировали volume postgres-data к нашему контейнеру. Теперь все данные, которые приложение в контейнере записало в /var/lib/postgresql , сохранятся на жестком диске. Иначе при остановке или перезапуске контейнера мы бы их потеряли.  -d — запустили команду docker run в detached-режиме: можем закрыть консоль, а контейнер продолжит работать postgres:11 — имя образа, на основе которого необходимо запустить контейнер. Подробнее про docker-образы можно прочитать здесь Проверим, что база работает. Для этого подключимся к ней через CLI: Если все настроено верно, то указатель слева в терминале должен поменяться на postgres=#.  Создадим базу данных и дадим все права на нее нашему пользователю: Подготовка закончена, переходим к написанию приложения. Чтобы получить доступ к базе данных, нам нужен адрес ее сервера, имя и пароль для входа, а также название самой базы. При локальной разработке приложения на компьютере эти параметры могут быть одни, а при публикации в Интернете совершенно другие. Данные, которые могут меняться, обычно выносят в конфигурационный файл и подменяют этот файл в зависимости от окружения. В корень проекта добавим папку config, а в ней создадим файл config.yaml. Также сразу же создадим файл settings.py в папке app. Структура проекта должна выглядеть следующим образом: В файл config.yaml добавим следующую конфигурацию: Теперь нам надо научиться как-то работать с этими данными. Для этого откроем файл app/settings.py и запишем в него: Теперь в глобальной переменной config хранится словарь с конфигурацией. Например, чтобы получить порт, нам нужно обратиться к config[“common”][“port”]. Давайте прикрепим config к нашему приложению. Приведем файл main.py к следующему виду: После этого шага мы можем обратиться к app[“config”] и получить доступ к нашему конфигурационному файлу из любого места в приложении. Аксессор — сущность, которая помогает работать с данными, находящимися вне памяти приложения, например, бывает аксессор к базе данных или аксессор к стороннему API. В аксессоре сокрыты детали реализации, такие как установка соединения, выполнение SQL-команд, парсинг ответа и т.д. Остальной код приложения не должен "знать" о реализации того или иного метода аксессора, он просто должен вызвать метод и взаимодействовать со сторонним источником данных в удобной форме. Давайте создадим подключение к базе данных. Для этого в папке app/ создадим еще один модуль store/, в которой будут хранится наши аксессоры. Добавим в папку app/store/database три файла и не забудем добавить файл __init__.py в store/database: accessor.py — здесь будет располагаться код для подключения к базе models.py — здесь находится входная точка для наших моделей, о которых будет сказано ниже Теперь структура вашего проекта должна выглядеть следующим образом: Файлы __init__.py оставьте пустыми, они нужны лишь как признак python-модуля. В файл accessor.py добавим следующий код: Давайте кратко рассмотрим содержание этого файла. Мы создали класс PostgresAccessor, который отвечает за подключение к базе данных и отключение после завершения работы. Функция _on_connect берет данные о базе из конфигурационного файла и с помощью команды db.set_bind(self.config[“database_url”]) создает необходимое подключение к базе. Если указана неверная конфигурация базы, или по какой-то причине подключение невозможно, то функция бросит исключение, и сервер не запустится.  Важно, чтобы проблемы с подключением к необходимым для работы сторонним сервисам были видны на этапе запуска приложения — это позволит сразу же среагировать на проблему или откатиться к предыдущей версии приложения, а потом уже решать проблему. Функция _on_disconnect позволяет отключиться от базы после завершения работы приложения и освободить ресурсы базы, например “правильно” разорвать соединение с ней. Отдельно рассмотрим функцию on_setup — в ней мы используем сигналы aiohttp. Сигналы — это некоторые сообщения, которые говорят об изменении состояния приложения.  Например, необходимо создать подключение к базе в момент старта приложения. Для этого мы можем просто добавить в список application.on_startup новую функцию. При запуске приложение aiohttp автоматически пройдет по этому списку и вызовет все функции в порядке добавления. То же самое можно сделать с  _on_disconnect, добавив этот метод в список application.on_cleanup — при остановке приложения aiohttp автоматически вызовет эту функцию и отключится от базы данных. Теперь в models.py нужно добавить код: Это очень важный файл. Он инстацирует экземпляр Gino, с помощью которого мы можем выполнять команды в базе и еще множество других вещей. Мы создаем экземпляр Gino глобально, так как он необходим для проведения миграций. Чтобы понять, что такое Gino и зачем он нужен, посмотрите на картинку ниже. Зеленым цветом обозначены асинхронные объекты, а желтым — синхронные: Разберемся по шагам.  1. База данных слева может получать команды и отдавать данные по так называемому DB API, которое основано на собственном протоколе работы.   2. Чтобы выполнить SQL-скрипт из Python, необходимо установить пакет, который умеет работать с DB API. Самый популярный пакет — Psycopg. Но проблема в том, что он синхронный: когда запрос уйдет в базу, необходимо дождаться ответа. Во время ожидания никакой другой код выполнен не будет. Для решения этой проблемы создан Asyncpg — обертка над Psycopg, которая позволяет сделать его асинхронным. Важно понимать, зачем необходимо асинхронное соединение с базой данных. Пример: мы решили посчитать статистику всех продаж магазина за несколько лет. База выполняет подсчет за 20 секунд. На эти 20 секунд синхронный python-код остановит свою работу и не сможет обрабатывать запросы от других пользователей. Говоря по-простому, сервер просто «зависнет». Асинхронное соединение «заморозит» дальнейшее выполнение функции, сделавшей запрос к базе, пока не дождется ответа, и продолжит выполнять другую работу — например, обслуживать другие запросы клиентов.  3. Достаточно неудобно писать SQL-команды вручную. Гораздо быстрее, надежнее и безопаснее писать с использованием Python-кода, хотя из-за этого немного теряется производительность. Для этого существует пакет SQLAlchemy, который позволяет удобно работать с базой, генерируя SQL-команды по нашему Python-коду и не только. К сожалению, по умолчанию SQLAlchemy синхронный пакет, поэтому появляется необходимость в еще одной обертке — Gino.   4. Gino — последнее звено, после которого наше асинхронное приложение наконец-то может асинхронно общаться с базой. SQLAlchemy, начиная с версии 1.4 поддерживает asyncio "из коробки", поэтому острая необходимость в Gino в асинхронных приложениях отпадает. Но Gino продолжает развиваться и добавляет функционал в SQLAlchemy, поэтому не стоит сбрасывать его со счетов. Подробнее о жизни после SQLAlchemy 1.4 можно прочитать здесь. Осталось привязать к нашему приложению PostgresAccessor. Добавим подключение аксессора в main.py, написав функцию setup_accessors и изменив код setup_app:  В реляционных базах данных информация хранится в таблицах. Работать с ними не совсем удобно. Чтобы сделать работу с данными более удобной и прозрачной, создают модели — некие абстракции над данными, которые человек воспринимает лучше, чем строка таблицы. Удобство не единственная причина использования моделей, они также позволяют задавать структуру базы данных из кода и добавляют уровень абстракции. В нашем проекте нам нужно создать модель сообщения, в которой будет хранится такая информация: Id сообщения — для уникальности и сортировки сообщений text — сам текст сообщения created — дата и время создания сообщения Хранить эти данные мы будем в таблице Message: Конечно, можно создать эту таблицу вручную, но это не очень удобно и безопасно при запуске приложения из нового места или если проект ведут несколько разработчиков. Если из-за ошибок в коде структуры базы данных будут несколько различаться это может привести к серьезным и трудно-исправляемым сбоям сервиса. Миграции призваны решить данную проблему. Миграции — это набор операций, которые надо применить к базе, чтобы привести ее в необходимое состояние. С помощью них можно как повысить, так и понизить версию структуры базы данных. Пример: можно выполнить миграцию и создать новые таблицы, а в случае ошибки откатить миграцию обратно и удалить таблицы.  При таком подходе несколько разработчиков могут изменять структуру базы параллельно — каждый создает необходимые ему миграции, а во время слияния кода эти миграции объединяются и дают структуру базы, которая удовлетворяет всем новым условиям. Если же мы планируем запустить наше приложение в новом месте, то достаточно выполнить все миграции, чтобы получить новейшую структуру базы. Подошло время написать нашу первую модель Message. Для этого в папке forum/ создадим файл models.py и вставим в него следующий код: Этим кодом мы декларативно задали, данные каких типов хотим хранить в таблице message. Также наша модель стала наследником db.Model, где db — экземпляр Gino. Теперь у нас все готово, чтобы сгенерировать первую миграцию. Когда нам нужна работа с миграциями, на помощь приходит пакет Alembic. Он позволяет автоматизировать процесс применения миграции и их создание.  Наша миграция будет содержать создание таблицы message со всеми необходимыми полями. Для этого в корне нашего проекта выполним следующую команду: Если все правильно, в корне вашего проекта должны появиться директорий migrations и файл alembic.ini. Alembic может работать, ничего не зная о наших моделях, которые заданы в коде — но тогда теряется возможность автоматической генерации миграций. Чтобы дать возможность Alembic «познакомиться» с нашим кодом, необходимо сделать два действия: В файле alembic.ini заменить строку на и сохранить файл. 2. Заменить код файла migrations/env.py на следующий: Этими действиями мы привязали к конфигурации Alembic конфигурацию нашего приложения. Теперь Alembic знает о наших моделях. Чтобы сгенерировать миграцию, надо в корне выполнить следующие команды: Команда export необходима, чтобы Alembic смог понять, о каком приложении мы говорим, так как оно может не находиться в PYTHONPATH — директориях, где python ищет свои модули. Флаг -m во второй команде позволяет задать человекочитаемое название миграции, чтобы сделать назначение миграции понятнее. Если все прошло успешно, то в папке migrations/versions появится файл примерно с таким названием: 6356fd90ab82_create_table_message.py. Код в начале названия — уникальный идентификатор миграции, который используется для сопоставления миграции и состояния базы, а также для того, чтобы обеспечить верный порядок применения миграций.  Давайте рассмотрим фрагменты этого файла более детально: revision — тот же код, который хранится в названии down_revision — код миграции, которую надо применить для того, после этой при понижении версии базы. Сейчас он пустой, так как это первая миграция в нашем проекте. branch_labels — указывается, если несколько миграций должны быть выполнены после одной и той же родительской миграции — это может произойти например при слиянии кода нескольких разработчиков, которые создали миграции для одной и той же таблицы. depends_on — код миграции, только после исполнения которой, может быть выполнена данная. Например, мы создали модель пользователя User и привязали ее к нашей модели Message, как автора сообщения. Тогда миграция создающая модель Message будет зависима от миграции создающую модель User, так как Message нельзя будет создать, пока не существует User. Также стоит рассмотреть две функции из этого файла: upgrade() — вызывается при повышении версии базы данных, а downgrade() — при понижении. Повысим версию нашей базы до последней: Теперь при прямом подключении к БД мы можем увидеть созданную структуру: В последнем шаге на сегодня рассмотрим взаимодействие с базой данных: получение и создание записей. Для этого необходимо создать новый View в файле app/forum/views.py. Добавьте этот код в конец файла: В этом View мы получаем отсортированные по id сообщения в порядке убывания. Так как номера id добавляются в базу последовательно, то сначала будут отданы сообщения, добавленные последними. Затем преобразуем Python-модели в список словарей, преобразуем их в json-формат, а затем возвращаем их в ответ на запрос. Не забудьте указать путь, по которому будет доступен данный View. В файле app/forum/routes.py в функции setup_routes() добавьте: Для проверки вручную добавьте вручную пару сообщений. Для этого откройте psql: Теперь выполните команды: С помощью команды \c мы подключаемся к конкретной базе данных и можем выполнять запросы к ее таблицам, например, выполнить команду INSERT . Чтобы посмотреть имеющиеся таблицы в базе данных, после подключения к ней необходимо выполнить команду \d: Заметьте, что у нас существуют две таблицы и одна последовательность: alembic_version — в ней хранится номер последней примененной к базе миграции, которая должна соответствовать префиксу в последнем примененном файлом миграции: message — таблица, где содержатся данные о сообщениях: message_id_seq — последовательность, которая используется для генерации новых id сообщений в базе. Теперь, запустив наше приложение командой python main.py в корне проекта и перейдя в браузер по ссылке 0.0.0.0:8080/api/messages.list, мы должны увидеть такую картину: Готово! Мы получили данные, которые хранятся в нашей базе и передали их в ответ на запрос. Чтобы добавить данные не вручную, создайте еще один View. Откройте файл app/forum/views.py и добавьте в конец следующий код: Можно заметить, что в этом коде мы создаем новое сообщение в базе данных — то есть записываем новую строчку в базу, а затем возвращаем созданное сообщение обратно.  Отдельно остановимся на том, как мы получаем данные извне: строчка data = await self.request.json() позволяет получить json-информацию, которая пришла вместе с запросом. Почему нам приходится использовать await для получения данных из объекта запроса? Дело в том, что aiohttp стремится оптимизировать взаимодействие с сетью и не получать данных больше того, что необходимо в данный момент. Пример: мы можем получить первый HTTP-пакет запроса и увидеть, что метод запроса неверен. Тогда мы не будем выполнять дальнейшие операции, или читать небольшими порциями, а не считывать все данные запроса целиком.  Изначально объект self.request— это информация из первого считанного HTTP-пакета (их может быть несколько, если данных много), поэтому в нем сразу же доступны метод запроса, заголовки и адрес отправителя. Для получения тела запроса необходимо выполнить асинхронную операцию, после выполнения которой в data будет находиться обычный Python-словарь. Добавим путь к нашему новому View в app/forum/routes.py в функции setup_routes(): При добавлении нового сообщения мы используем HTTP-метод POST, что является правильным при запросе на создание новой информации. Браузер при выполнении запроса из поисковой строки выполняет GET-запрос. Поэтому если мы попробуем выполнить 0.0.0.0:8080/api/messages.create, получим следующую ошибку: Давайте добавим в наш интерфейс функции, которые будут отображать сообщения из нашего ListMessageView и создавать новые сообщения, используя CreateMessageView. Для этого в файл templates/index.html добавьте код, располагающийся по этой ссылке, сразу после строчки </body>, заменив имеющийся <script>…</script>. Теперь откроем в браузере 0.0.0.0:8080 и увидим следующее: Если мы введем и отправим сообщение, оно отобразится на странице и сохранится в базе. Подведем итоги. В этой статье мы: Научились поднимать базу данных PostgreSQL в Docker-контейнере  Поработали с файлами конфигурации приложения Написали свой Accessor, который позволил нашему приложению получать данные из сторонних источников. По аналогии с ним можно создать каналы получения данных из других источников, например из стороннего API. Создали модель Message, абстракцию над «сухой» строчкой в таблице базы данных  Узнали как асинхронно общаться с PostgreSQL из Python  Настроили alembic и с его помощью сгенерировали первую миграцию Обратились из Python-кода к данным в нашей базе данных и отдали их в виде HTTP-ответа Код для второй части статьи находится в этом репозитории. Полный цикл статей «Первые шаги в aiohttp»:  Пишем первое hello-world-приложение Подключаем базу данных Выкладываем проект в Интернет Другие наши статьи по бэкенду и асинхронному программированию для начинающих: Визуализация 5 алгоритмов сортировки на Python Разбираемся в асинхронности: где полезно, а где — нет? Другие наши статьи по бэкенду и асинхронному программированию для продвинутого уровня: Пишем свой Google, или асинхронный краулер с rate limits на Python Пишем асинхронного Телеграм-бота Пишем Websocket-сервер для геолокации на asyncio Асинхронное программирование (АП) сложнее последовательного, поэтому его часто обходят стороной на курсах по программированию с нуля. Однако без АП не получится решать сложные задачи, писать многопоточный и нагруженный код и работать с микросервисной архитектурой. Мы разработали курс, посвященный асинхронному программированию на Python. Он будет полезен тем, кто уже знаком с основами языка и готов к инструментам посложнее. В курс входят: 7 модулей с видеоуроками — чтобы шаг за шагом освоить тему домашние задания с автопроверкой — чтобы закрепить знания на практике Для тех, кто хочет больше погрузиться в тему, есть программы с онлайн-разборами ДЗ и с менторской поддержкой. 👉 Узнать больше о курсе:  https://vk.cc/cmUy1v  Backend-developer