Data is not stored between page refreshes

[ljordan51]

No data is stored between page refreshes, therefore, the data is re-fetched each time the app is reloaded such as when refreshing the page or directly accessing a url (not using the links in the app). If we write the data locally and only re-fetch if we know new data should be available we can reduce API calls to the DB.

[ljordan51]

related https://github.com/airpartners/aq-web-client/issues/10

[davidt315]

Added a local cache (see fix-cache-refresh branch) but doesn't fix this behavior and I'm stuck. Would be nice if someone else could take a look.

[hsharriman]

Took a look at your implementation for the last few hours, and tried messing with a bunch of different things.

1. I confirmed that the way you have implemented the cache logic is correct--when an uncached object is encountered, it stores the object for future reference. However, that is only useful so long as the cache itself is maintained.
2. According to the docs, node-cache stores its cache data in a simple object within the class. It does not write anything to disk, so the cache is effectively held in memory. As you know, this option is great if you have a long-running application that will only be interrupted on occasion, i.e. you have a web server running 24/7 and it only experiences interruptions if the server goes down. From the best of my current understanding, the front end (i.e. our aq-web-client repo) would not be the best place for the aforementioned behavior.
3. Because the cache is held in an instance of a class, every time the page is refreshed, a new instance of the class is initialized with an empty cache, and there's pretty much nothing you can do to change that behavior.
4. There are a few different solutions that I either quickly tested or think would be a decent approach. They all involve writing the cache "to disk". a. Firstly, the browser has its own storage which you can access in a similar way to the node-cache library. window is a special variable in the front-end world, and it holds a lot of methods and information about the front-end. We can use window.localStorage to cache firebase results within a user's browser: link. The localStorage methods are bare bones, so you would have to take care of periodically deleting the cache entries, see: here, as well as converting the cached objects to json before storing. I tested this method and it provided the desired behavior (minus the periodic deletion which I did not implement). b. You can also go down the cookie route (we all know how annoying cookies are), but the basic idea is that you create a cookie for the data we want to store, as well as an expiration time, and retrieve it when we want the cached data. Cookies are a bit more complicated imo. c. Options A and B store the data in the user's local storage, but if you want to store things on our side instead, you could implement a cache on the server-side. I'm not sure I would recommend this option, as you can imagine this could blow up the necessary bandwidth for our server pretty drastically if we expand use cases for the cache to be specific to individual users of the app.
5. One other thing that I would mention is that you're going to need to deal with "cache invalidation". So, once you can reliably set/get from the cache, checking to see whether data grabbed from the cache is still "up-to-date" enough, or if you need to replace it by fetching data from Firebase again.

Let me know if you have any questions, I know that was pretty dense. Props to you for taking this on as your first web app task! I definitely would not have wanted to go anywhere near caching when I was just getting started. Also don't take this as the definitive, all-encompassing answer. I haven't had to implement a cache before, so this is purely based on my few hours of debugging and googling.