Data fetching on the web still sucks

Relay modern does all of the things that this article sets as a criteria for good data fetching.

What are examples of data-fetching libs/standards outside the web, that check all (or a relevant subset) of those criteria?

> You shouldn’t have to ship kilobytes of metadata describing your data schema to clients in order to fetch data.

I feel like this requirement makes every other requirement impossible unless you use some kind of compiled language feature and even then you're not going to be able to have type safety without some kind of metadata.

Also, I don't think it's possible to make any one library that solves all "data fetching" scenarios. How could you reasonably live data (eg stock ticker), enormous data sets (eg looking through individual analytics events) slow but largely static lookups (eg searching a library catalog) and fast but uncachable (eg a SPA forum) into the same API without making it horrendous?

I didn't see "show download progress" as one of the needs. I remember seeing complaints about the fetch api not exposing an easy way to do that. Issues like this one seem to remain: https://github.com/AnthumChris/fetch-progress-indicators/iss...

> Realtime updates. Sometimes, you want data to be pushed, not pulled (eg. for things like notifications). But the APIs for pushing and pulling data are often different, both on the client and on the server.

Two and a half months since Google announced the removal of HTTP Push[1]. There'd been a number of threads open (some 5 years old now) asking the Fetch spec to please include some way to allow the page to be notified of Push[2], which would have made HTTP Push super interesting & useful.

After 5 years, we never got anywhere, never got any help from standards body/google in trying to get Push useful. The topic came up a couple times when Abort was being worked on, and it seemed like maybe we'd see some progress, but those finer points got drowned among the noise of the Abort work.

And then Google announced we developers weren't using Push enough, & that they were going to drop it. Without ever having tried to make it useful in the first place.

HTTP/2 seemed to have such promise, was such elation finally getting released in 2015. Seeing so much promise go unfulfilled & then get cancelled has been quite dark. Unlike so so many of the alternatives that we are up to for data fetching, this path was both realtime & still http/resource centric. It still felt like core web architecture, in a way few others do. The unfulfilment of this destiny, this loss, has been jarring, & continues to leave us with these open quandries of what new entirely different alternatives do we invent, over WebSockets, over SSE, over WebTransport, &c. HTTP (almost) was here.

[1] https://news.ycombinator.com/item?id=25064855

[2] https://github.com/whatwg/fetch/issues/51

Edit: there was a deleted comment saying that this kind of use case is not what Push was for, is not there to send unprompted data. Technically, Push can only be done in reply to a http request, so there is a factual limitation. Web Push Protocol gets around this by holding a GET open, to allow "unprompted" data. I think a sizable amount of engineers at the time were indeed thinking of Push as an optimization, a way to get pages to load faster. But this contingent of folks who saw HTTP/2 Push enabling pushing data capabilities, who were hungry for it, who counted on it's maturation: I think they had reasonable expectations, and that we're in a very weird place on the web, with HTTP technically having the ability to push semi-unprompted, but browsers never delivering that capability that's now inbuilt in HTTP.

Using Push is still possible for so called unprompted updates even! At least it was till Push got removed. The trick is that the server needed some way to tell the browser which resources to send: so the server might be pushing resources, then using SSE to notify the page of those updates, for ex.