اعمل Short Links داخلي بـ Cloudflare Workers وKV

{
  "name": "short-links",
  "main": "src/index.js",
  "compatibility_date": "2026-04-25",
  "kv_namespaces": [
    {
      "binding": "LINKS",
      "id": "ضع-id-الخاص-بك-هنا"
    }
  ],
  "routes": [
    {
      "pattern": "go.example.com",
      "custom_domain": true
    }
  ]
}

استخدم 302 بدل 301 لو الروابط قابلة للتغيير. 301 ممكن يتخزن عند المتصفح أو محركات البحث بشكل أشرس، وده ضد فكرة إن الرابط الداخلي يتغير بسرعة.

التحقق من أنه يعمل

ضيف رابط تجريبي، ثم افتحه بـ curl. النتيجة المتوقعة إنك تشوف header باسم location فيه الوجهة الطويلة.

لو ظهر 404، غالبًا الـ slug غير موجود في KV. لو ظهر 500، راجع إن القيمة تبدأ بـ https://. الافتراض هنا إن كل وجهاتك public URLs وليست روابط داخلية حساسة.

الأرقام والـ trade-offs

في فريق صغير، تعديل رابط حملة يدويًا في 4 أماكن ممكن ياخد 10 إلى 15 دقيقة، غير احتمال نسيان قناة. باستخدام KV، التعديل يتحول إلى أمر واحد ياخد حوالي دقيقتين مع اختبار سريع. المكسب واضح: نقطة تحكم واحدة. التكلفة: أنت بقيت مسؤول عن naming convention، صلاحيات Wrangler، ومراجعة الروابط قبل نشرها.

الـ trade-off هنا إن Workers KV ممتاز للقراءات الكثيرة والكتابات القليلة، لكنه مش قاعدة بيانات relational ولا مناسب لتحديث نفس المفتاح عشرات المرات في الثانية. حسب حدود Cloudflare الحالية، الكتابة لنفس المفتاح محدودة بـ 1 write/second، وقيمة المفتاح نفسها لها حدود معلنة. لذلك استخدمه لروابط حملات وlanding pages، مش لنظام analytics لحظي.

متى لا تستخدم هذه الطريقة

لا تستخدمها لو محتاج لوحة إدارة كاملة، صلاحيات متعددة، تقارير clicks تفصيلية، أو A/B testing متقدم. في الحالة دي استخدم أداة متخصصة أو ابنِ backend كامل مع قاعدة بيانات. كمان لا تستخدمها لو الفريق غير مستعد لإدارة secrets وCloudflare permissions؛ الخطأ هنا ممكن يوجّه حملة كاملة لوجهة غلط.

المصادر

• Cloudflare KV namespaces
• Wrangler KV commands
• Cloudflare Workers custom domains
• Cloudflare Workers KV limits

الخطوة التالية

اختار حملة واحدة عندك، واعمل لها slug واحد فقط اليوم. لو التعديل من KV أخد أكثر من دقيقتين، المشكلة غالبًا في naming أو صلاحيات النشر، مش في Cloudflare Workers نفسه.