Репозиторий-заготовка для выполнения тестового задания для вступления в команду бэкенда. Призван погрузить в стек проекта, познакомить с используемыми библиотеками, в том числе внутрипроектными.
- Язык программирования: Python 3.11+
- ORM-система: SQLAlchemy 1.4/2.0+
- Микро-фреймворк: Flask 2.0+
- ORM-Плагин: Flask-SQLAlchemy 3.0+
- При участии: Flask-RESTX
- А также: Flask-Fullstack 0.4.14
- Создать публичный fork репозитория
- Склонировать репозиторий себе
- Создать виртуальное окружение на python 3.11
- Установить зависимости:
pip install poetry==1.5.1
poetry install- Запусить файл
app.py, можно создать Run Configuration на его запуск - Проверить, документация работает: http://localhost:5000/doc/
- В проекте настроены тесты на pytest для удобства тестирования SIO-интерфейсов
- Все тесты лежат в папке
tests - Предопределённые фикстуры:
base_client: тестовый flask-клиент (модифицирован в ffs) без авторизацииclient: тестовый flask-клиент, авторизованный под пользователем изcommon/constants.pysocketio_client: тестовый socketio-клиент, созданный отclient
- Базовые тесты проверяют документацию, ошибки, авторизацию и выход из аккаунта
- Запуск командой:
pytest tests
Само задание будет кастомизированно для каждого!
В проекте во всю мощь используется библиотека flask-fullstack (FFS). В ней есть частичная документация, но вот пример использования вытащить из проекта не удалось. Стоит прочитать документацию в файлах:
Никто не запрещает читать код репозитория внутри проекта, где используется эта библиотека: xi.backend
Знание flask-restx и sqlalchemy сильно поможет в понимании ffs, уже с этими знаниями можно почитать информационный материал ниже:
FFS: Порядок декораторов
Все упаковщики запросов (.a_response, .marshal_with, .marshal_list_with или .lister) должны быть последним декоратором перед методами в Resource. Иначе вылет ошибки из других декораторов (.argument_parser, .database_searcher, .jwt_authorizer) будет либо подавлен, либо завёрнут в дополнительный слой ненужной вложенности, нарушая описанное в документации. Технически не относится к декораторам документирования, но ради лучшей читабельности и общности стоит везде складывать декораторы в одинаковом порядке.
- все декораторы документации параметров запроса
- все декораторы документации формата ответов
- декоратор авторизации (
.jwt_authorizer) - декоратор парсинга аргументов (
.argument_parser) - декоратор(-ы) поиска объектов в бд (
.database_searcher) - декоратор пост-обработки ответа (
.a_response,.marshal_with,.marshal_list_withили.lister)
FFS: Shortcut-ы для БД
К объекту db.session добавлено несколько методов, упрощающих работу с логикой БД. По сути это простые shortcut-ы. Все их можно увидеть тут
Ко всем классам, наследующим Base (именно Base из common, не db.Model!) теперь добавляется набор полезных методов, которые могут значительно уменьшить объём работы. Они создаются и документированы тут
FFS: Модели для marshalling-а
Реализуются через Pydantic, а точнее модификацию его модели из flask-fullstack: PydanticModel.
Модели стоит создавать внутри тела класса, наследующего Base. Так её название заполнится автоматически и будет привязано к тому ORM-объекту, который она конвертирует. А для моделей, содержащих колонки БД всё ещё проще: в PydanticModel (и её потомках) объявлены статические методы для добавления к модели колонок (column_model).
Проще всего понять это через пример. Две модели внутри User, первая (IndexProfile) с id, username, bio и avatar, взятыми из соответствующих колонок, и вторая (FullProfile) со всеми полями первой и name, surname, patronymic и group, взятыми из соответствующих колонок:
IndexProfile = PydanticModel.column_model(id, username, bio, avatar)
FullProfile = IndexProfile.column_model(name, surname, patronymic, group)- Модели объявляются в теле класса, наследующего Base!
- Названия переменных нужно держать в
snake_case, для json-а они будут автоматически конвертированы вkebab-case - Регистрировать новые модели не нужно, достаточно просто использовать их в методах, вроде
.marshal_withили.lister
FFS: SocketIO
Частично задокументированно внутри проекта, более отделённая документация появится позже...
FFS: Assert Contains (для тестов)
- Будет проверяться
- Соблюдение PEP8 обязательно
- Желательно не забывать Zen
- DRY приветствуется
- Автоматическое реформатирование рекомендуется
- Стоит поглядывать на стиль других файлов проекта
- Желательно соблюдать conventional commits
- Решить задачу в несколько коммитов
- Pull Request с мини-описанием приветствуется
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent