HN Explorer

Ask HN: RFC for progress info in API calls? (tired of spinners)

2 points by jacobn ↗ HN
As the web we build (especially with the rise of GenAI & LLMs) becomes more and more dependent on API calls, I find it exceedingly frustrating that there are spinners absolutely everywhere, when it's "just" an informational disconnect - at some point in the stack it is / should be fairly well known how long something is going to take, we "just" don't propagate that information to the end user.

So here's a tentative proposal: add an HTTP header like "X-Wants-Progress: 1" to the request indicating that the client wants progress information.

A compliant server then includes a "X-Has-Progress: 1" header in its response and streams newline delimited numbers-as-strings in the [0.0-100.0] range as progress is made.

Floats allowed, monotonically increasing, same number can be repeated, clients should protect themselves by updating with max(old_value, new_value).

Once the progress part has completed, an empty newline is inserted and the real HTTP result is appended, status code, headers, body and all.

This way clients and servers can opt-in to being "progress capable", and if you ensure you have that capability all the way through then you can switch from the dreaded spinner-of-death to a smooth progress bar.

Thoughts?

9 comments

[ 1.9 ms ] story [ 31.9 ms ] thread
al2o3cr 

    at some point in the stack it is / should be fairly well
    known how long something is going to take
You should cite sources for a statement like this, because it doesn't seem like it's always true for interacting with a third-party API
jacobn
Yeah, knowable and known are two different things for sure - I guess you could create some elaborate tracking system that would measure it (yes, I have done this in my own systems ;) but I realize that will be going quite a ways above and beyond for most situations.

Just having some breakdown of the task and some however crude percentage allocation to them would still be a huge improvement over the status quo.

verdverm
This is too complex, difficult, and case dependent to make it a standard that requires implementation by frameworks. Nothing in the system can know how long each other part will take, let alone what downstream parts will be used to serve a request... so what float value should it be sending back when?
jacobn
It doesn't have to be exact - if you know you're making 10 sub-calls, you can just make each 10% and call it a day. Still leaps and bounds better than a spinner.
verdverm
How do those functions communicate their completion for reporting to the progress bar? And then what happens when some other engineers change how the backend works, meaning a different number of functions are used? It's significantly more complex to engineer all of this, and what value does it really provide? It's going to be just as bad if not worse

I guess you have not dealt with the 100% progress bar that never goes away?

codegeek
API calls cannot have deterministic progress calculated in advance due to various factors like current system resources available, load, amount of data stored and various other things that can impact the time it takes to finish an API call. So I don't see how you can get a progress percentage out of such call. Spinners are the only way as of now. It is not always like a File upload where you know the size of the file and the chunks uploaded to the server already.
jacobn
Well, it will depend on the specifics of the API. Sure, there will be degenerate cases where there's no meaningful progress that could be reported, but we throw in the towel without even trying?
ra0x3
I think you might be confusing application level and protocol level features? Of course you could always add custom headers (X-Wants-Progress) in your application. But the protocol (HTTP) doesn't really have insight into (or care about) any of your application context per se :)
schoen
Wasn't there a deprecation of the X- prefix in protocol headers?

Other thoughts:

You could probably make this play better with HTTP libraries by returning the header on an existing HTTP message, instead of changing the overall reply semantics. It's a little less efficient, but probably much more broadly compatible.

You could also have min-est-completion-time and max-est-completion-time rather than a percentage (partly to address people's concerns about the uncertainty or unknowability of overall progress as a percentage). Perhaps these could customarily be described as 90% intervals (or they could explicitly include a confidence estimate! like "90% of requests at this approximate degree of completion were completed within 7 and 32 seconds").