La configuration Edge est puissante précisément parce que le cas d'utilisation est étroit. Ce n'est pas une base de données générale. C'est un endroit rapide et disponible à l'échelle mondiale pour lire de petites valeurs qui influencent le traitement des requêtes près de l'utilisateur.
Où cela rapporte
Les meilleurs cas d'utilisation sont de petites décisions principalement en lecture :
- drapeaux de fonctionnalités
- interrupteurs d'arrêt d'urgence
- routage basé sur le pays
- basculements de bannières
- configuration d'expériences
Ce type de données peut affecter TTFB et l'expérience utilisateur si chaque requête doit d'abord revenir à l'origine.
Une lecture typique à la périphérie ressemble à ceci :
import { get } from "@vercel/edge-config";
const homepageVariant = await get("homepage-variant");
C'est petit, mais cela peut éliminer toute dépendance à l'origine du chemin de demande.
La question d'audit importante est de savoir si la valeur est petite, principalement en lecture et sensible à la latence. Si la réponse est non, le déplacer vers l'edge peut créer un système plus compliqué sans un gain significatif sur les Core Web Vitals.
Ce qu'il ne faut pas y mettre
La configuration Edge est le mauvais outil pour :
- charges de travail à écriture élevée
- requêtes relationnelles
- grands documents
- données nécessitant des garanties transactionnelles
Si la décision de la plate-forme dépasse le cadre des petites lectures dynamiques, vous ne parlez plus de configuration. Vous parlez d'architecture de données.
Meilleure règle
Utilisez la configuration Edge lorsqu'une petite valeur nécessite une proximité mondiale et que le chemin de lecture importe en termes de latence. Ne la promouvez pas en tant que base de données juste parce que cela est pratique.
Lectures complémentaires