Hey @hanniabu! I do client-side in-memory caching of videos data, only. No server-side caching. In fact, there is no database involved at all- the client-side app calls serverless function API endpoints to fetch the YouTube channel and video data it needs. Here are the tricks I'm using to make it fast:
- As soon as the "Channel URL" field loses focus, I start fetching the most recent 30 videos on that channel in the background. This way, by the time the user enters the keyword and date range, I've already fetched some (maybe even all!) of the data ahead of time, which means less wait time for them.
- Once a specific video's data (title, description, transcript, etc.) has been fetched once, it is saved in memory. All other searches the user performs from that point on will pull the video data from the in-memory cache, if it's there. Otherwise, it will fall back to fetching the video data over the network. This in-memory caching makes subsequent searches within the same date range (or a shorter date range) take <1 second.
- Network requests to fetch video data are processed concurrently rather than one at a time. So the browser fires off as many as it can in parallel to get them all resolved as quickly as possible.
- As soon as any matches are found, the UI updates to show the user. This way, the user can start scrolling through the matches and reviewing them while the search is still in progress– they don't have to wait until it finishes to start interacting with the matches.
>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!
- As soon as the "Channel URL" field loses focus, I start fetching the most recent 30 videos on that channel in the background. This way, by the time the user enters the keyword and date range, I've already fetched some (maybe even all!) of the data ahead of time, which means less wait time for them.
- Once a specific video's data (title, description, transcript, etc.) has been fetched once, it is saved in memory. All other searches the user performs from that point on will pull the video data from the in-memory cache, if it's there. Otherwise, it will fall back to fetching the video data over the network. This in-memory caching makes subsequent searches within the same date range (or a shorter date range) take <1 second.
- Network requests to fetch video data are processed concurrently rather than one at a time. So the browser fires off as many as it can in parallel to get them all resolved as quickly as possible.
- As soon as any matches are found, the UI updates to show the user. This way, the user can start scrolling through the matches and reviewing them while the search is still in progress– they don't have to wait until it finishes to start interacting with the matches.
Thanks for checking out my project!