Hacker News new | past | comments | ask | show | jobs | submit login

>I do client-side in-memory caching of videos data, only.

This works only if the user does not navigate from and back to your website or refresh the page, but if they do, you make the same api calls all over again. You should set HTTP Cache-Control headers in your response from the server, so that the browser knows that it can serve that data from its cache and does not need to make those requests again. You would then probably not need the client-side in-memory cache at all.




I could do this, but it would introduce other cache invalidation issues. Take this sequence of events, for example:

* The user performs a search, reviews the matches, then closes the browser tab.

* The title or description for one or more of the videos on that YouTube channel are updated.

* 45 minutes later, the user remembers that they wanted to search for something else on that same YouTube channel. They return to VideoMentions Search to perform another search.

If I had sent cache-control headers in the first response telling the browser to cache the results of those HTTP requests, they would not be refetched for subsequent requests and the user would potentially be shown incorrect matches.

By fetching the data fresh whenever the user opens VideoMentions Search in a new browser tab, I guarantee that they're getting correct matches based on the titles, descriptions and spoken words that the videos have at the time the search is performed.

So as it's implemented currently, I'm choosing to take a performance hit in exchange for improved accuracy. And I'm comfortable with that tradeoff since searches seem decently speedy to me when I use the tool.

Thanks for your thoughts, and the alternative client-side caching idea!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: