Am calling an ajax call to validate n number of data.Since it takes lot of time to complete, I thought of showing the user the progress bar or tell that 1/n completed In-order to display that, I should get the status from the controller.Can someone please tell me is there any way to get the status from controller before completing? Or Is there any other better way to implement.
Since ordinary AJAX is a classic request-response you cannot get progress information from the server with the same connection. You have to make a new AJAX call to ask the server for the task progress. This is called a heartbeat pooling technique.
Better solution is to use some kind of persistent connection, for example Websockets. That way server can push a message with progress information to the client over the same connection that initiated the task. Websocket adoption is strong among browsers.
XMLHttpRequest Monitoring progress:
see here: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest#Monitoring_progress
more here:
How to get progress from XMLHttpRequest
looks like this is in the standard
https://www.w3.org/TR/progress-events/#firing-events-using-the-progressevent-interface-for-http
Related
The logic of my code is basic.
The user sends a request to the server side, where it is processed and shown in an admin panel. Afterwards a person with access to the admin panel analyses the data and sends a response with some delay.
How can I create a response listener on the client side, so that I can catch the message I get from back-end, no matter the delay?
I tried doing it with fetch, but no wonder it didn't work, because once it is compiled, it makes the action immediately. Is AJAX an option in my case?
You'll need to have some sort of bidirectional communication layer here. The most common approaches are polling, web hooks, or sockets. Polling will probably be the easiest to set up in a beginner use-case.
If you're referring to jQuery's $.ajax, which uses XMLHttpRequest, it's not likely to be a good idea unless the server can respond very quickly every time. From what I understand, if the request isn't fulfilled within a reasonably short period of time, the browser or OS will terminate it. Fetch might have different limitations, but I still wouldn't trust it for something like this.
There are better approaches. Either create a websocket, so that the server can push information to the client on demand, or (less elegant) have the client repeatedly make requests to the server (say, every minute) and have the server respond positively if/when the admin panel has been dealt with.
Please excuse any misconceptions I may have, I'm new to HTTP requests.
I am using a file conversion API (online-convert.com) to convert an uploaded MIDI file to MP3.
The conversion process involves 3 HTTP requests that must be completed serially, I'm using Fetch for this.
The 2nd HTTP request uploads the input file to the server, and the 3rd HTTP request gets the completed job details. The issue is, if I try to make the 3rd request as soon as the 2nd request is completed, then the response states that the conversion process is still underway and the output is not ready.
My naive solution was to set up an intervalic loop that continues to make this 3rd request every x milliseconds, until the response indicates that the job is complete. This feels like an unnatural solution, and I was wondering if there's a better way to do this.
Sorry if my question is specific to the API I'm using, but any advice would be appreciated!
Thanks to Patrick Evans' comments above.
I have decided to get the completed job's details by polling as opposed to by callback URL.
I was able to implement this easily using Fetch and async/await, and found this to be easier than setting up server side scripts for a simple web tool that probably did not require them.
I'm developing a AngularJS driven SPA. I want to show a fullscreen overlay saying something like "Sorry - Server is not available atm" as soon as the connection between client and server is interrupted.
So I wrote a simple while(true) loop which is basically just calling /api/ping which always returns true. When there is no http response tho, then the message shall appear.
I don't like this approach since it creates a lot of overhead. Especially considering mobile connections.
So what would be a decent solution for my case?
I could imagine work with a websocket and an onInterrupted (or similar) event.
Basically, when an HTTP endpoint is offline you'll receive a HTTP/404 Not found status code.
I would say that it should be better wait for the error rather than querying the server overtime to check if it's online or not.
Use Angular $http provider's interceptors to catch all unsuccessful HTTP status codes and perform an action when you catch one like showing notification to the user to notify that there's no connection available to the server or the server is offline.
With WebSockets you still need to have some sort of ping mechanism, since there is functionally no difference between an inactive/very slow connection and a dropped connection.
Having said that, the overhead regarding wire traffic is much lower, since no HTTP headers are sent on each request, and this will result in lower processing overheads as well.
I have a service project that provides a HTTP server via TIdHTTPServer, and a web frontend. A number of functions that the user may initiate can take 5-10 seconds to complete, during which time they only see a gif animation while the ajax request waits for my delphi code to complete and return a status.
I'd like to implement a progress bar, or percentage (perhaps estimated time remaining, etc), but I'm not sure how it should be implemented. XMLHTTPRequest() has a progress event, which seems easy enough to implement on the client, but how do I have the server respond with it's progress?
From Ajaxpatterns.org:
Another way to deal with long XMLHttpRequest Calls is to explicitly
introduce a second monitoring channel. While the primary request takes
place, a sequence of monitoring requests are issued to ask the server
for a progress estimates. For example, the server might be looping
through 1000 records, running a transformation on each of those and
saving it to the database. The loop variable can be exposed so that a
monitoring service can convert it into a percentage remaining figure.
I have a synchronous API to invoke a server (HTTP GET) currently implemented with XMLHttpRequest.
The API does caching and will, if cache isn't deemed too old, return from the cache and invoke the server asynchronous to refresh cache.
Sometimes cache isn't available or too old, and then the API will synchronous call the server to fetch an accurate value before returning result to caller.
Result will contain a boolean success flag along with payload and clients handles result accordingly by looking at this flag.
There are two problems I can see with doing like this;
When cache isn't available and server isn't reachable or answering slow I would like to bring up a spinner so that the user is aware we are waiting for server.
In addition I would like to set a timeout value where we abort server request and handle the error accordingly.
Seems like I should be able to use setTimout operations but I have not been successful.
Preferably I would like to keep clients intact (not change the API to asynchronous).
Is there a way to achieve this?
The synchronous API was made responsive by maintaining a cache that was pulled from server asynchronous.
The cache was protected by a grace period under which we do not pull new value from server to avoid hammering the server.
For the most cases this was enough to assert there was always a cached value that could be provided to the client.
For a few cases where we have to pull new data the best solution would be to go fully asynchronous, that is also update client code.
Currently that is not an option, so in addition to above a heartbeat mechanism was put in place that toggles online/offline status to prevent trying synchronous pulls when offline.