W zależności od tego czy Twoja struktura to SSR czy CSR update progress baru możesz wykonać na różne sposoby.
Mogą to być przeładowania strony wymuszane co sekundę przez klienta,(słabe, ale proste bo fullSSR)
Mogą to być elementy dynamiczne na stronie klienta: Vanilla JS i jedziesz AJAXem.
W przypadki AJAX musisz pomyśleć o async/await wtedy też inaczej wykonasz endpoint API aby był kompatybilny; inną opcją jest wykonanie long pollingu na endpoincie, ale to będzie duży load na serwerze przy wielu klientach.
Ogólnie to to co chcesz zrobić już na samym podłożu źle ująłeś, konceptualnie tj. nie sprawdzas postępu pętli; sprawdzasz postęp pracy wykonaną przez skrypt na backend web appki zatem nazwij to tak. Stwórz sobie, wymodeluj coś takiego jak AbstractJob, dziedzicz od tego i stwórz ConcretAJob a w tym konkretną robotę i to dopiero wywołuj z poziomu publicznego API - czy to by był SSR czy CSR(tj. Web API czy RESTful).
Dodano po 58 [minuty]: Dżyszla napisał:
Generalnie protokół HTTP średnio nadaje się do monitorowania wykonania programu po stronie serwera w czasie rzeczywistym.
No, a tu błąd. Bo to zależy od zastosowania: streamowanie takie jak on chce wykonać, a nawet większych usług chodzi po HTTP i ma się jakkolwiek dobrze (streaming video na przykład); nie jest to oczywiście najlepsze są lepsze, ale z jakiegoś powodu inny mocny protokół do komunikacji i streamowania gRPC jest zbudowany nad HTTP, więc nad tą uwagą to zastanowiłbym się. Zresztą zwracanie uwagi na to, że HTTP się nie nadaje(przy tym nie rozważenie tak na prawdę wszystkich przypadów użycia) bez podania alternatywy rzekomo jakkolwiek lepszej, jest całkowicie bez sensu.
