5 ms·

I wonder why they didn't consider 103 Early Hints instead, as it solves the same problem in a much more elegant way, and doesn't require to re-architecture your

by byroot 3y ago

I wonder why they didn't consider 103 Early Hints instead, as it solves the same problem in a much more elegant way, and doesn't require to re-architecture your application.

memco 3y ago
Can you share more? How are they implemented and how do they help?
- byroot 3y ago
  See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 As they mention in the article, the main goal of streaming your response is to deliver the <head> tag to the browser sooner, so that it can start downloading assets sooner. However it has many downsides like explained in the article (can't change response code or headers once they are sent etc), which requires many hacks. 103 early hints allow to asynchronously send "provisional" headers, including `Link rel=preload` headers, which the browser can use to start downloading assets, but without restricting in any way the final response rendering. That's basically the same goal than HTTP2 Server Push (which was deprecated), but much simpler to implement (works with HTTP/1), and allow the browser not to download resources it already have in cache.
LinusU 3y ago
103 Early Hints is "experimental technology" (according to MDN) and isn't supported by Safari and Firefox. In Chrome it's only supported when using HTTP/2 or later (Firefox Nightly support it for HTTP/1). ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103
vrnvu 3y ago
Simple solutions don't get software engineers promoted for their architecture skills, and catchy blog posts can't be written.
dmw_ng 3y ago
Early hints solves a different problem, there you have a list of asset URLs you know your rendered page will need. This is about producing pieces of rendered page as computation completes on the backend. Implementing this is a pain in the ass, any new intermediary (haproxy, nginx, ...) introduces a potential new source of buffering or IO loop that attempts to helpfully batch up your writes. But when the technique is implemented, it is legitimately an amazing way to reduce latency at the client. I use this technique in an app where an opening chunk is used to ensure the browser has begun fetching/executing the app JS bundle before a list response is rendered. After the list is rendered (incrementally as each chunk becomes available) it is again used to execute a slow summary query without having to break out a separate request. All that fits in a single HTTP response body, no additional latency is introduced by making separate API requests for the list or for the counts. Because of the initial chunk causing the JS to execute, it is also possible for the app to display certain dialogs (depending on query string parameters) that are immediately ready for user input even before the subsequent responses have finished rendering or downloading. In the case of this specific app, the technique means some dialogs are usable 300ms earlier than otherwise Another issue not touched on in the post is how all this newly unbuffered incrementally-arriving data interacts with visual rendering on the client, there is potential for a lot of flicker and burned CPU continually re-rendering UI elements. It sounds like Airbnb are disabling compression to make their implementation work. So long as CPU isn't a problem, you can also implement compression in the backend, and flush the compressor each time some useful unit of work is produced (some task completes, or some amount of data e.g. aligned to the size of an Ethernet MTU is available for writing). Assuming all the stars align, this should produce compressed output in a form the browser can act on every time it manages to read any amount of data from the backend. All this effort seems like nonsense until finding you have a perfectly functional app on a crappy airport wifi network where it was otherwise impossible to even get Google to load
- byroot 3y ago
  > Early hints solves a different problem I think it saves the same main problem which is to trigger assets download early. However you are right streaming the response has a few extra advantages. I still think getting most of the results with a tiny fraction of the effort is a better solution, but your mileage may vary.

by byroot 3y ago

I wonder why they didn't consider 103 Early Hints instead, as it solves the same problem in a much more elegant way, and doesn't require to re-architecture your application.

memco 3y ago

Can you share more? How are they implemented and how do they help?

byroot 3y ago
See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 As they mention in the article, the main goal of streaming your response is to deliver the <head> tag to the browser sooner, so that it can start downloading assets sooner. However it has many downsides like explained in the article (can't change response code or headers once they are sent etc), which requires many hacks. 103 early hints allow to asynchronously send "provisional" headers, including `Link rel=preload` headers, which the browser can use to start downloading assets, but without restricting in any way the final response rendering. That's basically the same goal than HTTP2 Server Push (which was deprecated), but much simpler to implement (works with HTTP/1), and allow the browser not to download resources it already have in cache.

LinusU 3y ago

103 Early Hints is "experimental technology" (according to MDN) and isn't supported by Safari and Firefox. In Chrome it's only supported when using HTTP/2 or later (Firefox Nightly support it for HTTP/1). ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103

vrnvu 3y ago

Simple solutions don't get software engineers promoted for their architecture skills, and catchy blog posts can't be written.

dmw_ng 3y ago

Early hints solves a different problem, there you have a list of asset URLs you know your rendered page will need. This is about producing pieces of rendered page as computation completes on the backend. Implementing this is a pain in the ass, any new intermediary (haproxy, nginx, ...) introduces a potential new source of buffering or IO loop that attempts to helpfully batch up your writes. But when the technique is implemented, it is legitimately an amazing way to reduce latency at the client. I use this technique in an app where an opening chunk is used to ensure the browser has begun fetching/executing the app JS bundle before a list response is rendered. After the list is rendered (incrementally as each chunk becomes available) it is again used to execute a slow summary query without having to break out a separate request. All that fits in a single HTTP response body, no additional latency is introduced by making separate API requests for the list or for the counts. Because of the initial chunk causing the JS to execute, it is also possible for the app to display certain dialogs (depending on query string parameters) that are immediately ready for user input even before the subsequent responses have finished rendering or downloading. In the case of this specific app, the technique means some dialogs are usable 300ms earlier than otherwise Another issue not touched on in the post is how all this newly unbuffered incrementally-arriving data interacts with visual rendering on the client, there is potential for a lot of flicker and burned CPU continually re-rendering UI elements. It sounds like Airbnb are disabling compression to make their implementation work. So long as CPU isn't a problem, you can also implement compression in the backend, and flush the compressor each time some useful unit of work is produced (some task completes, or some amount of data e.g. aligned to the size of an Ethernet MTU is available for writing). Assuming all the stars align, this should produce compressed output in a form the browser can act on every time it manages to read any amount of data from the backend. All this effort seems like nonsense until finding you have a perfectly functional app on a crappy airport wifi network where it was otherwise impossible to even get Google to load

byroot 3y ago
> Early hints solves a different problem I think it saves the same main problem which is to trigger assets download early. However you are right streaming the response has a few extra advantages. I still think getting most of the results with a tiny fraction of the effort is a better solution, but your mileage may vary.