Hello, I have a Web Dev web service (python script) that does multiple things and takes a few minutes to complete at which time it returns a dictionary to indicate to the user that it finished. What I don't like is that when they call the service, its hard for them to know if anything is happening. Is there a way I can return things multiple times throughout the script to indicate what it is doing and not just at the end?
Not per-call, no. (Well, not without bending the API until it breaks.) Consider allocating a UUID for the operation, and making it a key into a global dictionary with progress information. Spawn an asynchronous function to do the work, and have it update the status map regularly. The caller can then call a companion API at some reasonable pace to get the latest progress. When complete, have that last status call prune the map.
1 Like
Thanks Phil, unfortunately, the caller of this API is a human not a machine... They go to the URL I have provided them to call the API but cant see its doing anything until I return success at the end. I could do something like what you have described but I don't want them to have to go to another (or same if I am able to do so) URL to check status intermittently, I was wanting their page from the first URL to update intermittently but I don't think this is possible.
Have the first URL return a React page with preset UUID that will dynamically monitor the followup page until complete. Or if old-school, repeatedly return pages with timed reload META elements until complete.
1 Like
First option sounds like the best but I am completely unfamiliar with React let alone how to get it working on/with Ignition.
For second option - I can return a page? Like another URL? - how?
In your <head>, add <meta http-equiv="refresh" content="1">, where 1 is the delay in seconds. This will tell the user agent (browser) to issue another request to your server (webdev endpoint) every N seconds. It's up to you to maintain the state of the original request (and how it's progressing) between requests.
You also don't need React to do a barebones dynamic page.
In A, return a page with plain old Javascript (Using the Fetch API - Web APIs | MDN) in the script tag (written in a Webdev resource, ideally) that will issue a request to url B, that starts your long-running backend task, and then on an interval issues a request to url C, which indicates the status of the task. Your original load of url A should include all of the information about what to do while the task is running on the background.
2 Likes
What version of Ignition is this? Do you have Perspective?
Seems like that would be a much easier solution than WebDev given that the "API" is consumed by a human and we're now discussing hacks that involve displaying your own janky webpage...
3 Likes
Unfortunately we have not yet been able to justify Perspective to our higher ups - will add this as another point in favor.
1 Like
Thanks, I feel like I can get something working pretty quick by maintaining the state, reading and printing the state in the body and refreshing.
I think your second paragraph eludes to being able to do something similar except only updating the page when the state changes (rather than intermittently)? That would be cool but I still don't understand how to return a page. Are you maybe able to provide an example such as making it print 'Hello World' and then 1 second later, 'Goodbye World' using 2 urls?
You can't [1] do this with HTML and Javascript. JS can only fetch periodically; the entire structure of HTML is that the user agent fetches a page once, and then has it. You can't "push" from a server to the user agent.
[1] Websockets kind of allow you to do server initiated messaging, but that's way out of scope here and there's no support for it in webdev anyways. But that's how Perspective is able to work.
1 Like