Подключите нашего Telegram-бота для уведомлений о новых проектах
Сервис на python(регулярные задачи, компоненты работы с api/парсингом, сохранение)
Срочный заказ
|
f
Заказчик
Отзывы фрилансеров:
+ 1
- 0
Зарегистрирован на сайте 11 месяцев
Исполнитель определен:
Егор Верхозин
Компонент API. (Application Interface)
Реализует компонент связывающий приложение и CRM стандартом REST.
Реализовать асинхронно, с помощью фреймворка FastAPI.
Приложение (NotificationHandler)
Выполняет необходимые задачи, принимаемые из очереди или запускаемые по графику Celery.
Приложение синхронное, в случае увеличения нагрузки будут подниматься автоскейлом инстансы, консюмящие очередь.
Компонент репозитория инкапсулирует детали доступа к данным, будь они за API, компонентом парсинга, в базе или где-либо еще. За референсом обращаться к комментариям Мартина Фаулера PofEAA.
Mapping.
За референсом обращаться к паттерну IdentityMapper. Слой максимально привязанный к инфраструктуре, использование ОРМ(sqlalchemy) по желанию.
Externals.
Компонент, включающий варианты доступа к внешним данным. Одна из частей компонента – резолвер капчи, подключаемый в случае необходимости использовать стратегию парсинга, как, например, в случае autoins.
Очередь.
Нужно сделать как минимум две очереди – задачи, падающие с ЦРМ, имеют максимальный приоритет, и должны, по возможности, быть обработаны приложением как можно быстрее.
---
Детали:
Зависимости прокидывать через DI, с использованием DI контейнера, лично я предпочитаю punk из за простоты, но допустимы dishka и т.п.
Обязательно покрытие тестами слои, между слоями ходят исключительно примитивы, или DTO.
Код будет распологаться в репозитории GitLab с настроенным CI пайплайном (black, isort, ruff).
Сущности “доменного” слоя реализовать с использованием Dataclasses.
Компоненты, обозначенные в схеме flow приложения как Celery, а так же детали функционирования репозиторного слоя приложения (*check if exists) касательно кеша в redis, разрабатывать не нужно.
Готовое решение поставить с использованием docker-compose.
Flow приложения, а так же компонентную схему можно посмотреть в приложении.
Реализует компонент связывающий приложение и CRM стандартом REST.
Реализовать асинхронно, с помощью фреймворка FastAPI.
Приложение (NotificationHandler)
Выполняет необходимые задачи, принимаемые из очереди или запускаемые по графику Celery.
Приложение синхронное, в случае увеличения нагрузки будут подниматься автоскейлом инстансы, консюмящие очередь.
Компонент репозитория инкапсулирует детали доступа к данным, будь они за API, компонентом парсинга, в базе или где-либо еще. За референсом обращаться к комментариям Мартина Фаулера PofEAA.
Mapping.
За референсом обращаться к паттерну IdentityMapper. Слой максимально привязанный к инфраструктуре, использование ОРМ(sqlalchemy) по желанию.
Externals.
Компонент, включающий варианты доступа к внешним данным. Одна из частей компонента – резолвер капчи, подключаемый в случае необходимости использовать стратегию парсинга, как, например, в случае autoins.
Очередь.
Нужно сделать как минимум две очереди – задачи, падающие с ЦРМ, имеют максимальный приоритет, и должны, по возможности, быть обработаны приложением как можно быстрее.
---
Детали:
Зависимости прокидывать через DI, с использованием DI контейнера, лично я предпочитаю punk из за простоты, но допустимы dishka и т.п.
Обязательно покрытие тестами слои, между слоями ходят исключительно примитивы, или DTO.
Код будет распологаться в репозитории GitLab с настроенным CI пайплайном (black, isort, ruff).
Сущности “доменного” слоя реализовать с использованием Dataclasses.
Компоненты, обозначенные в схеме flow приложения как Celery, а так же детали функционирования репозиторного слоя приложения (*check if exists) касательно кеша в redis, разрабатывать не нужно.
Готовое решение поставить с использованием docker-compose.
Flow приложения, а так же компонентную схему можно посмотреть в приложении.
Разделы:
Заказ
Опубликован:
22.09.2024 | 11:28 [поднят: 22.09.2024 | 11:28] [последние изменения: 24.09.2024 | 03:24]