Лучший способ интегрировать существующие инструменты Python с Django?

У меня есть несколько инструментов Python, которые я запускаю, в основном для скраппинга веб-сайтов или получения данных из различных веб-интерфейсов API.

В настоящее время все они запускаются из bash с параметрами, передаваемыми в качестве аргументов командной строки, например, 

$ python my_tool.py -arg1 -arg2 --output foobar.json

Я хочу отказаться от использования командной строки и вместо этого запускать инструменты через веб-интерфейс. Моя цель - создать систему, в которой пользователь может авторизоваться на сайте, ввести аргументы через веб-форму, нажать кнопку для запуска инструментов и получить возвращенные данные в формате json в базе данных для последующего анализа.

Я выбрал Django в качестве фреймворка для веб-интерфейса и db, поскольку у меня уже есть опыт работы с Python. Однако мне нужен совет по поводу лучшей практики интеграции инструментов Python, которые у меня уже есть, с Django. Лучше всего интегрировать инструменты непосредственно как приложения Django, или оставить их отдельно, но с возможностью взаимодействия с Django? Я буду благодарен за советы и опыт других в этом вопросе.

Я думаю, что вы определенно должны создать пакет, содержащий все ваши скрипты. Если вы должны включить или исключить их из приложения, это зависит от того, что вы хотите. Если ваши скрипты предназначены для использования по всему проекту, пакет должен быть вне приложения, в противном случае - внутри.

Inside the app
    ├── scrape
    │   ├── db_tools
    │   │   ├── __init__.py
    │   │   ├── scrape_etc.py
    │   ├── views.py
    │   └── forms.py

Outside the app
   ├── db_tools
   │   ├── __init__.py
   │   ├── scrape_etc.py
   ├── some_app
   └── other_app

В качестве дополнительного примечания, если вывод будет занимать много времени, вы можете создавать фоновые задачи (используя celery) и отправлять результат по электронной почте или хранить где-нибудь.

сопровождение API и его кода

Хорошая новость, у вас есть много вариантов!

Раньше вы вызывали my_tool.py из bash. Возможно, он начинается с import typer. Определенно, сейчас это работает, и хорошо протестировано.

В будущем большинство обращений (все обращения?) будут осуществляться через веб.

Плохая новость: биты будут гнить по прошествии месяцев. Инструмент будет обрастать новыми функциями, и приобретать исправления ошибок. Интерфейс, который не тестируется регулярно. в конечном итоге будет вести себя менее предсказуемо, чем хотелось бы.

Вот решение , которое вам сейчас предстоит принять:

Как люди будут вызывать код инструмента в будущем?

То есть, какой поддерживаемый способ называется? Есть несколько вариантов.

1. сохраните интерфейс CLI

API CLI уже поддерживается и работает. Возможно, у вас даже есть автоматизированные тесты, которые проверяют, все ли в порядке. Возможно, есть несколько абонентов, например, производственные пользователи в bash prompt, разработчики в bash prompt, Makefiles, задания cron. Web становится просто еще одним абонентом.

Вы можете выбрать сохранение этого статус-кво, и дополнительно поддерживать веб-сервер форк/исполнение инструмента в качестве дочернего процесса. По крайней мере, одним из преимуществ является то, что в случае утечки ресурсов, инструмент является недолговечным процесс, который освобождает ресурсы при выходе. Недостатком является необходимость повторного импорта python библиотек, что в некоторых случаях может занять более одной секунды.

2. поддерживать оба

По мере того, как будут проходить месяцы, будут появляться новые возможности добавляться, и некоторые из них могут добавить новые аргументы к существующему API.

Примите на себя обязательства по поддержке CLI и web как первоклассных потребителей кода. Позаботьтесь о добавлении автоматизированных тестов для обоих, и запускайте их с каждым релизом.

Это говорит о том, что django будет обращаться к публичные методы в рамках одного процесса. Это должно быть быстрее, так как импорты и datastructures уже инициализированы. Мы надеемся, что утечки ресурсов не будет.

3. только веб

Отмена/отсутствие поддержки интерфейса CLI, для экономии затрат на поддержку.

Обратите внимание, что вам по-прежнему нужны автоматизированные тесты, чтобы вселить уверенность в новых релизах в будущем. Вы можете обнаружить, что поддержка CLI может оказаться на этапе тестирования.

В конце концов, решение за вами. Жизнь полна компромиссов.

Вернуться на верх