Допустим, требуется выполнить операцию над списком,
на странице требуется отобразить прогресс.
Изначально использовался fetch.
Получается три пути:
1) использовать вебсокеты и делать большую часть работы на сервере
и втаскивать помимо fetch еще и ws в клиента.
либо нагромождать большее кол-во методов HTTP API
2)
DoSomething(); // запустить фоновой процесс
CheckSomethingStatus();// выполнять пока не закончится каждые 5 секунд и обновлять UI
3)

GetInitState(); // получить исходное состояние
for e in list do
Something(e); // вызвать с клиента для каждого элемента
UpdateUI(e);

Какой по вашему более разумный?

Здравствуйте, vaa, Вы писали:

vaa>Допустим, требуется выполнить операцию над списком,
vaa>на странице требуется отобразить прогресс.
vaa>Изначально использовался fetch.
vaa>Получается три пути:
vaa>1) использовать вебсокеты и делать большую часть работы на сервере
vaa>и втаскивать помимо fetch еще и ws в клиента.
vaa>либо нагромождать большее кол-во методов HTTP API
vaa>2)
vaa>DoSomething(); // запустить фоновой процесс
vaa>CheckSomethingStatus();// выполнять пока не закончится каждые 5 секунд и обновлять UI
vaa>3)

vaa>GetInitState(); // получить исходное состояние
vaa>for e in list do
vaa> Something(e); // вызвать с клиента для каждого элемента
vaa> UpdateUI(e);

vaa>Какой по вашему более разумный?

Нет никакого абстрактного "более разумного". Каждый вариант рабочий, у каждого варианта есть плюсы/минусы и цена. Надо смотреть с учетом вашего контекста. Чего вы хотите добиться? Какая цель? Если уже есть работающее решение, то зачем вы хотите что-то поменять? Что не устраивает сейчас? Какого рода у вас операции: 100 операций по 100 мс каждая, или 5 операций по часу? Насколько критично отзывчивость UI: одно дело, когда юзер залил фотки на обработку и ждет их готовность через час, другое — система, которую использует оператор на производстве, где требуется возможность повлиять на ситуацию в течение секунды. Все это сильно влияет на принятие решения о методе реализации. От такой постановки задачи и надо отталкиваться.

Некоторые размышления о плюсах/минусах:
— если на фронте уже используются веб-сокеты, лучше заюзать их
— во втором случае вам скорее всего потребуется какая-то очередной на бэке. Это дополнительный геморрой, потребует поддержки в будущем, плюс большая вероятность, что там появятся какие-то ошибки, да и надо будет отдельную таблицу или даже несколько, миграция схемы БД, или тащить какую-нить кафку или другой мессадж брокер
— во втором случае бэк может отдавать ETA (эстимацию по длительности выполнения), на основе чего можно прикрутить простое вычисление оптимальной частоты пингования бэка для получения обновлений. Простое и быстрое в реализации решение. Я бы начал с него

В целом: чем проще решение, тем лучше Начинать лучше с самого простого, которое удовлетворит вашим критериям. То есть не тащить вебсокеты без необходимости, не вносить асинхронность там, где без нее можно обойтись, не создавать новые таблицы на бэке, если можно сделать без них. Все это сыграет в плюс в долгосрочной перспективе.

Здравствуйте, vaa, Вы писали:

vaa>Какой по вашему более разумный?

В конкретном проекте, как уже сказали, может быть удобным любой из них.
Но если рассуждать из того что написано, то
* первый похоже потребует больше усилий (из-за добавления и дальнейшей поддержки сокетов)
* второй (+ передача ETA чтобы не гонять запросы каждые 5 сек) и третий выглядят наиболее универсально, но там есть принципиальная разница — в третьем варианте по сути каждый шаг независимый, если что-то пойдет не так на 100 шаге, то откатить прошлые 99 может оказаться нереальной задачей. Во втором варианте все может происходить в рамках одной транзакции. Тут уже надо смотреть на сам процесс.

> POST /operation?x=1&y=2
< 123

> GET /operation-status?id=123
< PROGRESS

> GET /operation-status?id=123
< PROGRESS

> GET /operation-status?id=123
< FINISHED

> GET /operation-results?id=123
< 456