< Shouvik Mitra />

Dealing with user activity in web applications is almost always an afterthought. To that, we should also understand that this is not something new and has been happening for quite a long time by major platforms and websites out there.  I am no judge to say if it is a good practice or not, but as an engineer, I will try to note down the recent development in this space over the years. And, moreover, if you are tasked to do something similar for your new app, how you can go about doing it. Let's talk about the basics Our primary goal is to reliable track user's activity without affecting the application performance. Now, what is categorized as user activity is something we will address in a future blog, but regardless of the granularity of the data what is our concern at the moment is how we collect metrics data from a technical perspective. Overarchingly, we have two kinds of data being passed around the server and browser. Namely, analytical data and transactional data. Our fir

Today, we are going to talk about an additional tool to help you maintain a fine balance between instancy and freshness when delivering data to your web applications. RFC5861 states two independent Cache-Control extensions that allow for the cache to respond to a request with the most up-to-date response held. 1. The stale-if-error HTTP Cache-Control extension allows a cache to return a stale response when an error such as Internal Server Error is encountered, rather than returning a hard error. This improves availability. 2. The stale-while-revalidate HTTP Cache-Control extension allows a cache to immediately return a stale response while it revalidates it in the background, thereby hiding latency (both in the network and on the server) from clients In this blog, we will be talking more about the stale-while-revalidate HTTP header. The basic idea of this header is to reduce the latency of serving cached content by your web browser to your application and have a refresh mechanism via w