Question 1

What was the motivation to build something like this?

Accepted Answer

A few years ago the idea of a server-side Redis cache came up in a Nuxt project I was working on. As an old-school frontend developer that layer had never been my problem, so I wanted to take one apart properly: what belongs in which cache, and what each layer actually buys you.

Question 2

Why cache a public API at all?

Accepted Answer

NASA's APOD API is slow and rate-limited, and the gallery asks for 60 days at once. Cached, that becomes one request per day, served instantly to everyone after the first visitor.

Question 3

What does each layer actually store?

Accepted Answer

All three store the same normalized APOD JSON: Vue Query in the browser and in localStorage, Nitro in the server process, Redis shared and persistent for 24 hours. The images are not in the chain. They ride the browser's HTTP cache and Netlify's Image CDN.

Question 4

What is Vue Query, and what does it do here?

Accepted Answer

TanStack Vue Query is a data cache in the browser: one entry per query key, shared by every component that asks for it. Here it holds the APOD JSON under ["apod"] for the list and ["apod", date] for a single day, fresh for 24 hours, with no refetch on mount or window focus. The server passes its cache to the client in the page payload, so hydration costs no second request, and each entry is written to localStorage for repeat visits. It is the layer the footer's invalidate button acts on.

Question 5

Is Vue Query actually needed here?

Accepted Answer

Yes, for the part that matters here. Nuxt's useAsyncData also carries server-fetched data into the client without a second request, but on an internal navigation it would fetch again: its default cache only reads the payload while hydrating, and Nuxt purges that data on navigation by design. Vue Query keeps one entry per key with a 24 hour stale time instead, so moving between the gallery, a picture and back costs no request at all. It also adds localStorage persistence and the invalidate API the footer button uses.

Question 6

Why a Nitro cache and Redis? Isn't one enough?

Accepted Answer

For most projects one is enough. They are both here because they fail differently: a Nitro hit never leaves the server process and beats the Redis network hop, but it dies with the process and is not shared between instances. Redis survives both. Clear one in the footer and the request falls through to the other.

Question 7

What is the difference between defineCachedFunction and defineCachedEventHandler?

Accepted Answer

Both come from Nitro rather than from Nuxt itself, and both have been available since Nuxt 3 (this project runs Nitro 2.13). They share the same options: maxAge, staleMaxAge, swr and getKey. defineCachedEventHandler caches a whole HTTP response for a route, keyed by the request, so on a hit the handler does not run at all. defineCachedFunction caches the return value of a single function, keyed by its arguments, and the handler around it still runs on every request.

Question 8

Why does the Nitro layer cache a function here and not the route?

Accepted Answer

Because the response carries a flag saying which layer answered it, and that flag has to stay true. A cached event handler would serve the entire stored response, flag included, so the badge would claim Nitro forever and clearing Redis would change nothing on screen. Caching only the inner function keeps the handler running, so it can re-label every response. The event handler would work and would skip slightly more work per request, it just cannot report on itself, which is the same reason the HTML is not cached.

Question 9

Why isn't the rendered HTML cached too?

Accepted Answer

The badges are written at render time, so a cached page would report a cache state as old as the copy. Route rules, prerendering and ISR are perfectly good tools; they just cache something else than this demo is about.

Question 10

Why is the first load of a picture slow and the second instant?

Accepted Answer

Images are not part of the JSON chain. On first view Netlify's Image CDN fetches the NASA original and converts it to AVIF at the requested width; that conversion is the wait. Afterwards the variant is cached at the edge and in your browser.

Question 11

How long does anything stay cached?

Accepted Answer

Redis 24 hours, for the list and for every single day. Nitro counts a value as fresh for 30 seconds and may then serve it stale for up to a day while it revalidates. Vue Query 24 hours in the browser. The daily miss is not a TTL: the list key contains its date range (last 60 days, ending yesterday), so at midnight it becomes a different key.

Question 12

Would you build a production app exactly like this?

Accepted Answer

No: one server cache instead of two, and the HTML cached as well. The extra layers exist here to make the trade-offs visible and clickable.

Questions about the cache