3 ms·
The part I don’t get is why http push wasn’t cache friendly. The idea of fetching a graph of objects is so common. All I want to do as a web dev is a browser
by nojvek 6y ago
The part I don’t get is why http push wasn’t cache friendly.
The idea of fetching a graph of objects is so common.
All I want to do as a web dev is a browser client requests a tip REST object or an entrypoint js script. When the client receives that, the client can send the object/script back and all the connnected objects back together to avoid multiple round trips.
It makes me sad that this still isn’t a thing (server can reply with more than one cacheable url)
To work around this we invent all sorts of tools like graphql, webpack with layers of complexity.
Sure there is the problem of what if the client already has the resource. Then the answer is the response can optionally send content or just the url. You then have a 2nd roundtrip to fetch the content the browser doesn’t have.
At the end of the day, I just want the browser to essentially rsync-ish a bunch of url/resources from the server.
- treve 6y agoAgreed. We're building HATEOAS-powered SPA's for customers, and we've ultimately built an architecture that reimplements features we wished browsers did better. Our end-goal is ultimately exposing a graph, make everything addressable, have great cache control and means for different parts in the stack to decide when caches should expire. All of these are features of the 'web'. But clients and servers are a bit behind what we would like to see.