والآن يأتي السؤال الثاني: REST أم GraphQL؟
هنا معظم الشركات تخطئ. تختار تقنية متقدمة قبل أن تحتاج إليها، ثم تقضي أسابيع في معادلة المشكلة التي لم تكن موجودة بعد.
الفرق الحقيقي، بدون الضجة
REST ممل. كل مورد (منتجات، عملاء، طلبيات) له نقطة نهاية منفصلة. تطبيقك يطلب المنتج من /api/products/123، فيعود JSON كامل بـ 50 حقل. أنت تستخدم 5 منها فقط. الـ 45 حقل الأخرى: حشو. هذا يُسمى over-fetching.
GraphQL: تحدد بدقة ما تريده. «أعطني الاسم والسعر والصور فقط.» الخادم يرد: «تمام.» لا أكثر، لا أقل. النطاق الترددي ينخفض بـ 20-40%. التطبيق يصبح أسرع.
المقارنة السريعة:
| المعيار | REST | GraphQL |
|---|---|---|
| وقت التطوير | أسبوعان | شهر واحد |
| التعقيد | بسيط | متوسط (منحنى تعليمي) |
| المرونة | محدودة | عالية جداً |
| استهلاك النطاق | أعلى | أقل (20-40%) |
| التكلفة الشهرية | 1000-1500 د.ك | 1500-2500 د.ك |
من تجربتي في قيادة مشاريع في الكويت والخليج، أكبر خطأ يحدث هو اختيار GraphQL قبل الحاجة. فريق يبني API متقدم ويقضي شهرين في معقدية الكود قبل أن يأتيهم أول عميل حقيقي. بعدها يكتشفون أن REST كان يكفيهم.
الخلاصة: ابدأ بـ REST. إذا شعرت بالألم الحقيقي لاحقاً، انتقل إلى GraphQL.
متى تختار REST فقط؟
اختر REST إذا:
- شركتك في السنة الأولى من الرقمنة
- فريقك 2-3 مهندسين فقط
- لديك تطبيق واحد حالياً (موقع ويب بدون جوال)
- ميزانيتك أقل من 5 آلاف دينار للمشروع كاملاً
تكلفة REST: 3-5 آلاف دينار (بناء) + 1000-1500 د.ك شهرياً (تشغيل). Laravel أو Node.js مع MySQL. معايير أمان قياسية. هذا كل ما تحتاج.
ملاحظتي الشخصية
رأيت هذا الخطأ يُغرق مشاريع ممولة جيداً: اختاروا GraphQL «للمستقبل»، ثم اكتشفوا بعد شهرين أنهم يحتاجون REST فقط. الندم يأتي متأخراً جداً. فكّر بسيط اليوم أفضل من تعقيد غير مؤكد.
GraphQL: متى يستحق فعلاً؟
GraphQL يسدد ديونه حين:
- تطبيقاتك متعددة الفعل (موقع + iOS + Android + نقطة بيع)
- كل تطبيق يريد بيانات مختلفة
- النطاق الترددي مكلف (عملاء في شرق إفريقيا أو جنوب آسيا)
- فريقك مليء بمهندسين متقدمين
شركة في الإمارات انتقلت من REST إلى GraphQL وقفزت فاتورة النطاق الترددي لأسفل بـ 40%. لكن الهجرة استغرقت 3 أشهر وكانت مؤلمة.
والآن: بوابات الدفع الكويتية
حين يأتيني عميل يسأل عن دمج الدفع، أول سؤال أطرحه: «هل تبيع مادياً أم رقمياً؟» السبب بسيط: بوابات الدفع الكويتية تتصرف بشكل مختلف تماماً عن بوابات العالم الأول.
KNET
البوابة الوطنية. 90% من المتاجر الكويتية تستخدمها. الدعم محلي تماماً. التكامل: 2-3 أيام عمل. الرسوم: 2-4% من كل عملية (بدون رسم شهري). الأمان: معايير PCI DSS كاملة. أوصيك بها كالخيار الأول.
K-Pay
بوابة محلية أحدث (من Zain). التطوير أسرع من KNET (ساعات بدل أيام). الرسوم: 3-5% (أعلى قليلاً من KNET). عدد العملاء أصغر لكنها تنمو. خيار جيد كـ ثاني بوابة.
Telr أو HyperPay
بوابات عالمية (الإمارات والسعودية). تدعم عدة دول. العملاء الكويتيون أقلية على هذه الخدمات. الرسوم: 2.5-3% (تنافسية). التطوير أسهل لكن المحلية أقل. اختر فقط إذا كان لديك عملاء خارج الكويت أيضاً.
نصيحتي الصريحة: استخدم KNET. انته. خيار ثانٍ إذا كنت تريد اختبار: K-Pay. الباقي: لا تحتاج حالياً.
كيف يعمل التكامل الآمن مع بوابة الدفع
رحلة طلبية واحدة من البدء إلى النهاية:
الخطوة 1: العميل يختار المنتجات
التطبيق يرسل POST إلى /api/cart/items مع معرّفات المنتجات. الخادم يحفظ العربة مؤقتاً.
الخطوة 2: إنشاء طلبية
POST إلى /api/orders بالعميل والمنتجات والمبلغ. الخادم ينشئ طلبية بحالة «قيد الانتظار» ويرجع معرّف فريد.
الخطوة 3: إعادة توجيه آمنة
التطبيق يوجه المتصفح إلى KNET مع معرّف الطلبية وتوقيع رياضي (HMAC-SHA256) يثبت أن الطلب من خادمك.
الخطوة 4: العميل يدفع
KNET (وليس أنت!) تأخذ رقم البطاقة والتفاصيل. البنك يتحقق. النتيجة: نجح أم فشل.
الخطوة 5: Webhook آمن
KNET ترسل POST إلى https://yoursite.com/webhooks/knet تقول: «الطلب #XYZ نجح، رقم المعاملة ABC123.» خادمك يتحقق من التوقيع (حماية من الويبهوك المزيف)، ثم يحدّث حالة الطلب إلى «مُكتملة» ويرسل إيصال للعميل.
الخطوة 6: التطبيق يتحقق
التطبيق يطلب GET من /api/orders/ORDER_ID. الخادم يرجع الحالة النهائية. شاشة «نشكرك».
الخطأ الأكبر: الشركات التي تثق في استجابة البوابة الفورية وحسب. قد يتأخر الـ webhook 5-10 دقائق. إذا اعتمدت على الرد الفوري فقط، ستفقد الطلبيات.
تحذير أمان: لا تتجاهله
لا تتحقق من صحة الـ webhook بناءً على معرّف الطلب والمبلغ فحسب. تحقق من التوقيع الرياضي (HMAC-SHA256). بدون هذا، أي شخص يمكنه إرسال webhook مزيف يقول: «حول 10 آلاف دينار للعميل #1»، وستفعل ذلك دون تفكير. معايير PCI DSS تفرض هذا. قانون البنك المركزي الكويتي يفرضه. افعله.
التكاليف الحقيقية: ما الذي تحتاج فعلاً
- تطوير API (REST)
- 3-5 آلاف دينار — فريق من 1-2 مهندس، أسبوعان
- تطوير API (GraphQL)
- 8-12 ألف دينار — نفس الفريق، شهر واحد
- استضافة (REST)
- 1000-1500 د.ك شهرياً — VPS خفيف الوزن، قاعدة بيانات MySQL
- استضافة (GraphQL)
- 1500-2500 د.ك شهرياً — موارد إضافية للكاش والمعالجة
- تكامل KNET
- 500-1000 د.ك — محفور في وقت التطوير الأساسي
- الدعم والصيانة (سنوي)
- 2-5 آلاف دينار — حسب التعقيد والعدد الساعات
الحساب البسيط: REST + KNET من الصفر = ~6-8 آلاف دينار للبدء + 1000-1500 د.ك شهرياً. معقول تماماً.
الخطوة التالية: اختر شريكك بحكمة
الأهم أنك تختار شريك تطوير يفهم السوق الكويتي والخليجي. ليس كل مهندس REST يفهم الفارق بين الرد الفوري و webhook، أو لماذا التوقيع مهم، أو الاختلافات بين KNET و K-Pay.
اسأل عن مشاريع سابقة. إذا قالوا: «شغلنا 15 متجر إلكتروني مع KNET»، أنت على المسار الصحيح. إذا قالوا: «استخدمنا Stripe»، فهموا العالمي لكنهم قد لا يفهمون التفاصيل المحلية.
وأخيراً: ابدأ بـ REST. آمن، رخيص، بسيط. انتقل إلى GraphQL حين تشعر بالألم الحقيقي — حين تخدم تطبيقاتك المتعددة من API واحد ويصبح النطاق الترددي مشكلة حقيقية، لا مشكلة مستقبلية محتملة.