تكوين الحافة قوي تمامًا لأن حالة الاستخدام ضيقة. إنه ليس قاعدة بيانات عامة. إنه مكان سريع، متاح عالميًا لقراءة القيم الصغيرة التي تؤثر في معالجة الطلبات بالقرب من المستخدم.
## أين يثمر؟
أفضل حالات الاستخدام هي قرارات صغيرة، تعتمد على القراءة في الغالب:
- مفاتيح الميزات
- مفاتيح القتل الطارئة
- التوجيه بناءً على الدولة
- تبديلات الإعلانات
- تكوين التجارب
يمكن أن تؤثر هذه البيانات على زمن الاستجابة الأول (TTFB) وتجربة المستخدم إذا كان يتعين على كل طلب العودة إلى الأصل أولاً.
تبدو قراءة الحافة النموذجية على النحو التالي:
```ts
import { get } from "@vercel/edge-config";
const homepageVariant = await get("homepage-variant");
هذا صغير، ولكنه يمكن أن يزيل اعتمادًا كاملًا على الأصل من مسار الطلب.
السؤال الهام في المراجعة هو ما إذا كانت القيمة صغيرة، تعتمد على القراءة بشكل كبير، وحساسة من حيث زمن الانتظار. إذا كانت الإجابة لا، فإن نقلها إلى الحافة يمكن أن ينشئ نظامًا أكثر تعقيدًا دون تحقيق مكسب ذي معنى في قياسات Core Web Vitals.
ما يجب عدم وضعه هناك
تكوين الحافة هو الأداة الخاطئة لـ:
- أحمال الكتابة العالية
- الاستعلامات العلائقية
- الوثائق الكبيرة
- البيانات التي تحتاج إلى ضمانات معاملات
إذا نمت قرار المنصة إلى ما هو أبعد من القراءة الديناميكية الصغيرة، فأنت لا تتحدث بعد الآن عن التكوين. أنت تتحدث عن هندسة البيانات.
قاعدة أفضل
استخدم تكوين الحافة عندما تحتاج قيمة صغيرة إلى قرب عالمي ويهم مسار القراءة زمن الانتظار. لا ترقٍّها إلى قاعدة بيانات فقط لأنها ملائمة.
قراءة إضافية