Le cache programmable de Fastly est l’un des superpouvoirs de notre plateforme Compute. Envie de personnaliser une image pour ravir chaque utilisateur de votre application ? Fastly a ce qu’il vous faut ! D’ailleurs, y parvenir dans le contexte d’un flux de requête/réponse HTTP ne devrait pas être un fardeau. Fastly Compute résout cela grâce à la simplicité de nos nouvelles API de cache HTTP, un ensemble d’API SDK utilisables depuis le code Compute.
Comment cela fonctionne-t-il ?
Par défaut, lorsque les requêtes HTTP passent par la périphérie de Fastly, les réponses d’origine sont automatiquement mises en cache (à moins qu’elles ne soient explicitement ignorées via Cache-Control). Les requêtes ultérieures pour cette même ressource peuvent ensuite être livrées à partir du cache sans avoir à se connecter au back-end.
Les API de cache HTTP permettent aux développeurs de réaliser quelque chose qu’ils n’avaient jamais pu faire auparavant avec Compute. Vous pouvez désormais injecter des personnalisations dans ce flux par défaut, ouvrant la voie à de nouveaux cas d’utilisation et à de nouvelles possibilités pour les clients Compute.
Ce que vous devez savoir
API de cache HTTP : le TL;DR
Fournit une prise en charge HTTP de première classe dans votre langue préférée
Permet un accès programmatique détaillé au cache de Fastly
Prend en charge la personnalisation du contenu dynamique livré par Fastly Compute
Permet aux développeurs de personnaliser aisément le comportement de mise en cache
L’interface de cache HTTP se base sur les fondations établies par les interfaces Simple Cache et Core Cache et est optimisée pour la mise en cache des requêtes/réponses dans le cadre de la spécification HTTP. Il s’agit d’une API entièrement intégrée qui offre aux développeurs des fonctionnalités telles que la possibilité de modifier les propriétés de cache d’un objet, d’ajuster des en-têtes comme Cache-Control et bien plus encore, le tout, dans le contexte d’un flux HTTP.
Cas d’utilisation que nos clients apprécient
Voici un exemple simple en JavaScript de modification du temps de vie (TTL) de Fastly, tout en définissant un Surrogate-Control pour les caches en aval et un en-tête Cache-Control pour gérer les caches des navigateurs :
const backendResp = await fetch(clientReq, {
backend: 'example_backend',
cacheOverride: new CacheOverride({
afterSend(resp) {
resp.ttl = 300;
resp.headers.set('Cache-Control', 'max-age=86400'); // Rules for browsers
resp.headers.set('Surrogate-Control', 'max-age=31536000'); // Rules for downstream caches
resp.headers.delete('expires');
},
}),
});En outre, il existe d’innombrables autres architectures que vous pouvez mettre en œuvre. Voici quelques suggestions pour vous aider à démarrer :
Personnalisez les contrôles de cache d’une réponse du serveur back-end avant la mise en cache : les développeurs peuvent définir le temps de vie (TTL) du cache en fonction d’un en-tête de réponse non lié au cache, tel que Content-Type.
Avantage : cette flexibilité permet de mettre en place des stratégies de mise en cache plus intelligentes et efficaces. En définissant les TTL du cache en fonction du type de contenu, les développeurs peuvent optimiser les performances et l’utilisation des ressources. Par exemple, les actifs statiques comme les images ou les fichiers CSS peuvent être mis en cache pour des périodes plus longues, tandis que le contenu dynamique peut présenter des temps de vie plus courts. Cela se traduit par une amélioration de la vitesse du site web, une réduction de la charge d’origine et une meilleure expérience utilisateur, tout en s’assurant que le contenu demeure adapté à chaque type de ressource.Modifiez les en-têtes ou corps de réponse avant de les stocker dans le cache : par exemple, les développeurs peuvent mettre en cache la version HTML générée localement d’une réponse, plutôt que le JSON brut renvoyé par l’origine.
Avantage : cette capacité permet aux développeurs de stocker des versions optimisées du contenu dans le cache, réduisant ainsi le temps de traitement et améliorant la vitesse de distribution. En mettant en cache la version HTML plutôt que le JSON brut, les requêtes ultérieures peuvent être servies plus rapidement, l’étape de transformation étant supprimée. Cela améliore non seulement les performances, mais réduit également la charge de calcul sur le serveur d’origine et en périphérie, conduisant à des économies de coûts et une application globalement plus réactive.Déterminez la nécessité de la mise en cache, en fonction du contenu d’origine : idéal pour les situations où vous ne souhaitez pas mettre en cache une réponse HTTP 200 OK.
Avantage : ce niveau de contrôle garantit que seul le contenu valide et utile est mis en cache, préservant ainsi l’intégrité et la fiabilité du cache. En évitant de mettre en cache les réponses qui contiennent des erreurs malgré un statut 200 OK, les développeurs peuvent empêcher la propagation de données incorrectes aux utilisateurs. Résultat, l’expérience utilisateur est plus cohérente, le risque de fournir un contenu obsolète ou erroné est réduit, et il devient plus facile de maintenir la qualité et l’exactitude globales des sorties de l’application.
Pour obtenir plus d’informations et des exemples de code supplémentaires, accédez à notre portail développeur.
Passons à la mise en cache
Les API de cache Fastly sont parfaites pour étendre les limites de la personnalisation et offrir des expériences de pointe. Ces nouveaux contrôles de cache s’intègrent parfaitement aux flux de travail existants, rendant l’ajout de personnalisations simples extrêmement facile.
Envie d’essayer les API de cache HTTP ? Commencez à les utiliser dès aujourd’hui ou rejoignez la conversation sur le forum pour découvrir comment nous pouvons vous aider à tirer le meilleur parti de votre cache !
