I've read the article now 3 times but still don't understand what exactly this offers or how this works. Where does the JSON come from? If it comes from the backend there is still some considerable latency overhead, why then not just cache the whole page?
Or, does this allow your browser to fire a JSON (POST) request to an edge node where the varnish server will reconstruct the page based on the request parameters? If this is the case, cool. But, as I understand this, it will still require some sort of Javascript framework on the client side to actually construct the proper JSON requests.
Or https://en.wikipedia.org/wiki/Edge_Side_Includes which Varnish is already supporting. I also have troubles seeing what the value of Edgestash is over something the can be already done with (not even so recent) technology and moderate effort.
Well just take the example on their page for example. With ESI you would fire off to a server process that has to then go seek a user, then build up some HTML using a templating language in python or whatever you're using and return it to varnish.
With edgestash it looks like varnish holds the template, compiles it, caches it, then injects values in to it from JSON, which is easier for the server to generate and easier for varnish to inject the values from.
For HTML that's very dynamic based on user data ESI isn't an ideal solution, you either end up with a ton of includes (and thus a ton of requests), or you end up basically having only the shell of a web page cached by varnish. With edgecache you would have a single request (or a handful) returning all the data as JSON, and varnish would have a cache of basically the entire page to inject the values in to. Your server-side code doesn't have to deal with HTML at all, it just provides data. I'd say it's less competitive with ESI and more closely competing with single page apps, but you're moving the load back on to your server so clients aren't downloading javascript for injecting data in to HTML templates.
So in the past, you'd just render your template server-side and send the resulting HTML to the user. Easy peasy.
Then many developers switched to single page applications where users download the template and the javascript code and data to populate it, then render the template client-side.
As Varnish Software points out in this blog post, SPAs often have terrible performance, especially on mobile. What they seem to be suggesting as the fix is a strange hybrid: Your application server continues to serve the unrendered template and data to populate it, your varnish cache renders the template, and the user receives HTML.
Why is client-side rendering slow enough that something like this is even worth considering? Our smartphones are supercomputers in our pockets, after all.
10 comments
[ 3.2 ms ] story [ 35.1 ms ] threadBest headline I read in a while. This made my day :)
Or, does this allow your browser to fire a JSON (POST) request to an edge node where the varnish server will reconstruct the page based on the request parameters? If this is the case, cool. But, as I understand this, it will still require some sort of Javascript framework on the client side to actually construct the proper JSON requests.
This is https://en.wikipedia.org/wiki/Server_Side_Includes with another alternative language, it seems?
With edgestash it looks like varnish holds the template, compiles it, caches it, then injects values in to it from JSON, which is easier for the server to generate and easier for varnish to inject the values from.
For HTML that's very dynamic based on user data ESI isn't an ideal solution, you either end up with a ton of includes (and thus a ton of requests), or you end up basically having only the shell of a web page cached by varnish. With edgecache you would have a single request (or a handful) returning all the data as JSON, and varnish would have a cache of basically the entire page to inject the values in to. Your server-side code doesn't have to deal with HTML at all, it just provides data. I'd say it's less competitive with ESI and more closely competing with single page apps, but you're moving the load back on to your server so clients aren't downloading javascript for injecting data in to HTML templates.
Then many developers switched to single page applications where users download the template and the javascript code and data to populate it, then render the template client-side.
As Varnish Software points out in this blog post, SPAs often have terrible performance, especially on mobile. What they seem to be suggesting as the fix is a strange hybrid: Your application server continues to serve the unrendered template and data to populate it, your varnish cache renders the template, and the user receives HTML.