@JRBRO

Как связать WEB UI с Python?

Такой вопрос, чисто творческий.

Есть на Python вывод состоящий из:
Название из цикла
Переменная

Как правильно делать интерфейс, чтобы он работал с этой информацией?

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

Суть в том, что Python скрипт гоняется по кругу и я хочу информацию выводить куда-то наглядно, желательно Web. Как в принципе это происходит.

Чтобы было понятно, приложу пример кода (это оценка разницы изображения, если что-то меняется, он дает меньший score). В интерфейсе я хочу видеть Порядковый номер изображения (в моем случае это объект из цикла) ну и саму оценку(изображений будет больше 10).

Если есть другие решения для мониторинга буду рад послушать

CLICK
from skimage.measure import compare_ssim
import argparse
import imutils
import cv2

# 2. Construct the argument parse and parse the arguments
ap = argparse.ArgumentParser()
ap.add_argument("-f", "--first", required=True, help="Directory of the image that will be compared")
ap.add_argument("-s", "--second", required=True, help="Directory of the image that will be used to compare")
args = vars(ap.parse_args())

# 3. Load the two input images
imageA = cv2.imread(args["first"])
imageB = cv2.imread(args["second"])

# 4. Convert the images to grayscale
grayA = cv2.cvtColor(imageA, cv2.COLOR_BGR2GRAY)
grayB = cv2.cvtColor(imageB, cv2.COLOR_BGR2GRAY)

# 5. Compute the Structural Similarity Index (SSIM) between the two
#    images, ensuring that the difference image is returned
(score, diff) = compare_ssim(grayA, grayB, full=True)
diff = (diff * 255).astype("uint8")

# 6. You can print only the score if you want
print("SSIM: {}".format(score))


НЕБОЛЬШОЙ АПДЕЙТ

Между фласком и джанго выбор пал на первый. Как по мнению экспертов, это будет достаточно мощный инструмент для мониторинга?
  • Вопрос задан
  • 237 просмотров
Решения вопроса 2
Vindicar
@Vindicar
RTFM!
Пусть Flask-приложение стартует первым и запускает твой worker-скрипт в отдельном процессе. Так они друг другу мешать не будут, и если твой worker вылетит, Flask выживет и сможет сообщить о случившемся (ну и перезапустить worker, если надо будет).
Вопрос тут в выборе способа обмена данными между скриптом и Flask, а также между Flask и браузером.

1. Worker -> Flask:
- запуск worker через multiprocessing, обмен данными через очередь (multiprocessing.Queue).
Плюс: возможен обмен простыми структурами данных, типа списков и кортежей.
Минус: требует переделки скрипта-worker, чтобы вместо print() он отправлял данные в Queue, да и в целом его надо будет импортировать в Flask-приложение. Что-то кроме питона той же версии так не запустишь.
- запуск worker через subprocess, обмен данными через перехват stdout.
Плюс: worker остаётся без изменений, и может быть запущен отдельно. Строго говоря, любая консольная программа, не требующая ввода, может быть так запущена.
Минус: обмен данными только как последовательность строк. Что-то другое потребует сериализации на стороне воркера, и десериализации на стороне Flask.

2. Flask -> browser:
- Самый простой и дубовый способ - long-running request.
Твой обработчик запроса на Flask запускает воркера, но не закрывает соединение, а потихоньку читает поступающие от воркера данные и отдаёт клиенту. Проблема в том, что если клиент отрубился, восстановить соединение будет нельзя.
- Чуточку более сложный - polling. Один обработчик запроса на Flask запускает воркера и всё. Другой обработчик пытается прочитать накопившиеся у воркера данные, и отдаёт их клиенту. Тогда на клиенте должен крутиться JS-скрипт, который будет периодически дергать второй обработчик. Проблема в том, что если данные от воркера долго не считываются (клиент отключился), очередь/pipe для связи между процессами переполнится, и воркер "подвиснет" на операции отдачи данных Flask. Также этот подход не будет работать с двумя и более клиентами.
- Ещё более сложный, но надёжный - buffered polling. Данные от worker помещаются в какое-то хранилище (грубо говоря, в переменную). Хранилище может хранить как полную историю вывода, так и только последний полученный блок данных - смотря что тебе интересно. Тогда Flask-приложение должно отдельным потоком забирать данные у worker, и помещать их в хранилище. Основной поток будет обслуживать запросы, и отдельный обработчик запроса будет отдавать клиенту текущее состояние хранилища (целиком или последние изменения, смотря сколько хранишь).
Плюс: такая схема будет работать при любом разумном числе клиентов, в том числе при нуле.
Минус: доступ к хранилищу нужно аккуратно синхронизировать, например, с помощью threading.Lock().
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Не нужен тебе никакой фласк и джанго. У тебя - задача мониторинга процесса. Мониторинг решается через Graphana например. Она всеядная. Можешь писать свою телеметрию в текстовый лог-файл. И Графана просто будет его показывать графиком или числами или кругами вобщем посмотри сам. Там много виджетов.

Помимо графаны есть еще масса способов отобразить статус процесса. Но я использовал только Гр.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы