Reactive state for the backend

[Music] Hi. So, I'm Ree. I'm an engineer here on the domains team at Bell. And I wanted to really kind of go over uh use cache, what it unlocks, kind of how we got here, and why I'm excited about it. So, going over the agenda, we're going to look at kind of the evolution of use cache and X.js, JS the functionality that it unlocks and then how you can kind of use use cache to make it hide away into the background and more of an

implementation detail. So from the talk title what is reactive state? Um so it's kind of this concept of when you make a change all of the people should see that change reflected without having to kind of encounter stale data. It's a common problem that kind of many apps that you have use. For example, how many times have you flipped a toggle on one browser tab, but the other browser tab that you have open doesn't reflect the changes that you just made? This scenario here kind of highlights it, but it might not be super

common where you have two tabs open at the same time, but you can imagine, you know, your teammates updating state at the same time and the page doesn't reflect that state. Same thing, we're kind of leaving a comment and then not seeing that uh reflected. On the front end, we have a lot of tools to solve this problem. We have the ability to listen to changes to data over websockets or SSE and it's pretty fixable in that you set up sub subscription on the client to the data that's changing and then reflect refresh the state based on that and we've seen

more apps kind of adopt this over time. For example, one of our products v0 when you send a message it updates in real time across the browser clients. um it's a fair bit easier to kind of ship updates to splike apps as you can start a listener on the client. But whereas when you're serverside rendering your pages in either a distributed or a serverless setup, you don't have that persisted client to kind of start a connection and along with that um you might be managing multiple cache locations, whether that be your data cache or your CDN cache. Um it's a lot

of state that you have to track. So kind of reactive state and now kind of my background. Um a lot of the experience that I have is building really high fast performing high scale sites for nextjs. In the past few years years I've helped build next faster which is a demo e-commerce site with over a million products and instant page navigations. Answer overflow an x.js app that has over 2 million pages. And then

the cell domains which is a real-time search for domain names. And so kind of what do all of these have in common? Well, they all make really heavy use of caching. And the reason they use caching so extensively is to get data close to the user. And so if caching is so great, then why aren't all sites fast and why don't we just cach everything so it loads instantly? Well, you have to count all of the places the cache data is used in order to revalidate them and also make sure that that data isn't stale. And so with next faster and overflow,

while both of them are great at serving lots of pages, they're not super reactive to the changes that are made. And so kind of looking at why that is and how caching has evolved with the next.js in Nex.js. Uh starting with the pages router, you have two options for caching. The first one was either manually writing data to Reddus or some similar data store. This would be what you would use if you wanted to cache the results of a call uh in between kind of deployments or keep it in memory. Uh the other one would be writing pages to ISR

cache and this would be done by adding get dynamic props or get static props along with specifying revalidate time and you'd use that when you wanted to kind of serve pages from the edge cache or CDN cache. That's how you cache data from the pages router. But then invalidation was a much more painful story. You'd have to call a route handler and then figure out all of the places your data was used and then call revalidate for every single path that that data was used on. This meant you had to be doing a bunch of manual