Image endpoint: Avoid checking updates per request

[jvwong]

A reasonable estimate is that 99.9% of the time, submitted pathways / documents are never updated by the author after the fact. A very minor case (handful) is when it is updated, by us during post-curation or the author does do it post-submission.

This suggests that we can prioritize the case where the network image stays the same on submit. Importantly, checking the time of last update on each document on image fetch is unnecessary and introduces a performance burden on each webpage load (home, search).

---

Originally posted by @jvwong in #1143 (comment)

I'm finding the getDoc call to be a major offender following an initial load:

factoid/src/server/routes/api/document/index.js

Lines 1453 to 1466 in eca68a1

	const main = async () => {
	try {
	const doc = await getDoc(id);
	const lastEditedDate = '' + doc.lastEditedDate();
	const cache = imageCache.get(id);
	const canUseCache = imageCache.has(id) && cache.lastEditedDate === lastEditedDate;
	if( canUseCache ){
	res.send(cache.img);
	} else {
	const cache = await fillCache(doc, lastEditedDate);
	res.send(cache.img);
	}

Alternative to handle imgCache staleness is:

• Fetch the JSON results from /api/document/ (ttl is 24 hours)
• Find the matching document and it's lastEditedDate
• Hit the cache or regenerate as usual

So the downside is authors won't see updates to their submitted docs within 24 hours. The p-limit code is still valid on initial load, the rest of the time the entire search browse page loads almost instantly.

[maxkfranz]

The getDoc() you linked to is setting up loading via live synch. That may be expensive regardless of whether you’re hitting the docs list JSON cache.

Doesn’t @lindajiawenli’s code now load in documents directly from the JSON? If so, things like image generation should be using that instead of more expensive live synchers.

Whether we use the JSON cache or not is a trade-off. Yes, it’s faster. It also means that users don’t see their submissions when they submit. If that’s still important to them, then it should be considered.

An alternative re. caching JSON: Don’t ever check the date for when the doc was last edited. Instead, manually bust the cache whenever someone hits the submit button. Same effect but probably cheaper.

[maxkfranz]

Other notes:

• If the docs are rarely changed, then don't even bother with cache invalidation. Even when we do correct an author's document, do we change it visually? It's probably just the grounding or interaction type, which doesn't make a visual change.
• Store images in the DB.
  • Pro: Simple.
  • Pro: Would make social cards faster and more reliable. I think Twitter may bail out if the image loads too slowly.
  • Con: Bigger DB.

[jvwong]

Other notes:

• If the docs are rarely changed, then don't even bother with cache invalidation. Even when we do correct an author's document, do we change it visually? It's probably just the grounding or interaction type, which doesn't make a visual change.

For whatever reason, the cache is returning true on every has(id), regardless of the ttl, which in fact, is being set as expected. This means it behaves like you said above.

NB: The lru-cache we use is v4 and so some of the newer features aren't available (e.g. status tracking)