Quand Deven, un développeur d'agence qui bâtit sur Canner, a demandé si notre cache pouvait se contourner lui-même pour les aperçus de brouillon, et si nous pourrions exposer un fournisseur de cache Astro, la réponse honnête était : l'un était une petite lacune, l'autre une occasion de faire de Canner un citoyen de première classe dans le système de mise en cache d'Astro. Cette semaine, les deux sont livrés — et « stale-while-revalidate » a suivi.
Ensemble, ils changent notre façon de parler de la mise en cache sur Canner. Ce n'est pas une fonctionnalité DatoCMS ni une fonctionnalité Astro. C'est un système de mise en cache indépendant du cadriciel et du CMS : marquez une réponse comme cachable, étiquetez-la, et invalidez-la avec précision — par étiquette de contenu ou par URL — depuis le CMS et le cadriciel que vous utilisez.
Un fournisseur de cache Astro natif
Astro 7 a introduit la mise en cache des routes: une seule API indépendante de la plateforme — Astro.cache.set() — où chaque hôte branche un fournisseur qui traduit vos directives dans sa propre mise en cache. Astro livre des fournisseurs pour Netlify, Vercel et Cloudflare. Depuis cette semaine, @canner-ca/astro-cache ajoute Canner à cette liste.
Configurez-le une fois :
// astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';
import { cacheCanner } from '@canner-ca/astro-cache';
export default defineConfig({
adapter: node({ mode: 'standalone' }),
cache: {
provider: cacheCanner({
slug: 'my-project',
token: process.env.CANNER_CACHE_TOKEN,
}),
},
});Puis mettez en cache par route, avec la même API que sur tout autre hôte :
---
// src/pages/blog/[slug].astro
const post = await getPost(Astro.params.slug);
Astro.cache.set({ maxAge: 3600, swr: 86400, tags: [post.id, 'blog-listing'] });
---Comme Canner met en cache à son propre proxy — devant votre application et partagé entre toutes les instances — le fournisseur ne dépense jamais la mémoire de votre application pour un cache interne. Il pose les directives, et invalidate() purge par étiquette ou par URL avec le même jeton.
Mode brouillon : l'aperçu sur la vraie URL, sans purge
Le scénario à l'origine de tout ceci : un rédacteur veut voir un brouillon non publié sur l'URL réelle de la page, mais vider le cache pour le lui montrer servirait une page lente et non mise en cache à tout le monde. La solution est de laisser une seule requête contourner le cache.
Chaque projet avec cache possède désormais un secret de contournement. Une requête qui le porte — dans un témoin __canner_bypass, un lien ?__canner_bypass= ou un en-tête X-Canner-Bypass— est rendue à neuf depuis l'origine, pendant que le public garde la page en cache. La réponse brouillon n'est jamais stockée et n'évince jamais la page publiée, donc le contenu brouillon ne peut pas fuir dans le cache public. C'est la même forme que le mode brouillon de Vercel, et les utilitaires de cadriciel vous donnent une route de brouillon clé en main :
// src/pages/api/draft.ts
import { enableDraft } from '@canner-ca/astro-cache';
export const GET = ({ url, cookies, redirect }) => {
if (url.searchParams.get('secret') !== import.meta.env.PREVIEW_SECRET) {
return new Response('Unauthorized', { status: 401 });
}
enableDraft(cookies, import.meta.env.CANNER_BYPASS_SECRET);
return redirect(url.searchParams.get('to') ?? '/');
};Les mêmes utilitaires sont livrés pour Next.js et Nuxt. Par défaut, le secret doit correspondre (mode strict); un mode optionnel contourne à la simple présence du témoin, pour les applications qui gèrent déjà leur propre session de brouillon.
« Stale-while-revalidate » : personne n'attend un rendu à froid
L'ancien comportement était simple et un peu impitoyable : une fois le TTL d'une page écoulé, le visiteur suivant déclenchait un rendu frais et l'attendait. Maintenant, si vous définissez une fenêtre stale-while-revalidate, Canner sert la copie périmée instantanémentpassé le TTL et la rafraîchit une fois en arrière-plan. Le rafraîchissement est à vol unique, donc une pointe de trafic au moment de l'expiration déclenche exactement une requête à l'origine — pas une par visiteur.
Activez-le en ajoutant la directive à votre Cache-Control, ou swrà n'importe quel utilitaire :
cache(Astro.response, { ttl: 3600, swr: 86400, tags: [post.id] });
// → Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400Invalidez par étiquette ou par URL
Les étiquettes restent le bon outil quand un contenu apparaît sur plusieurs routes : étiquetez chaque réponse avec l'id de l'entité, et une seule purge les vide toutes. Mais le fournisseur Astro suit les routes, il doit donc aussi purger par URL exacte — et maintenant vous pouvez, depuis le webhook de n'importe quel CMS :
curl -X POST https://api.canner.ca/projects/<slug>/cache/purge \
-H "Authorization: Bearer <jeton de purge>" \
-H "Content-Type: application/json" \
-d '{"paths": ["/blog/my-post"]}'Un chemin sans requête vide toutes ses variantes. Envoyez tags, paths, ou les deux dans une seule requête.
Un seul système, n'importe quelle pile
Rien de tout cela n'est lié à un CMS ou à un cadriciel particulier. Le fournisseur est l'API native d'Astro; les utilitaires d'en-têtes fonctionnent partout où vous pouvez poser un en-tête de réponse; le mode brouillon et « stale-while-revalidate » sont des propriétés du cache lui-même. DatoCMS est un exemple concret dans le guide — pas le cadre.
Et tout cela roule sur la même infrastructure canadienne que votre application : le cache, la purge et le rendu brouillon ne quittent jamais le pays. Si vous êtes sur Canner, activez la mise en cache sous Paramètres → Cache et dirigez votre cadriciel vers elle. Si vous soupesez un changement, c'est tout l'argumentaire — rapide, souverain, et maintenant avec un système de mise en cache qui rejoint votre pile là où elle est.