بنيتَ بالفعل على Cloud API. لست مضطرًا لبنائه من جديد.

الجزء الذي يستغرق صباحًا والجزء الذي يستغرق سنة

الرسالة الأولى سهلة. أما القائمة أدناه فهي ما يتراكم بعدها، ولا شيء منها عمل ممتع.

• تقديم القوالب وحالات اعتمادها وأسباب رفضها وقواعد ربط متغيّراتها
• تسليم الويب هوك وإعادة محاولاته، ووسيلة لرؤية ما وصل فعلًا
• رفع الوسائط وتنزيلها، والروابط التي تنتهي صلاحيتها
• مطابقة إشعارات التسليم والقراءة مع سجلاتك أنت
• تحديد معدّل ينظّم الإرسال بدل الاصطدام بحدود الحساب
• بريد وارد، لأن العملاء يردّون ولا بدّ لأحد أن يقرأ
• إيقاف الإصدارات، وفق جدول Meta لا جدولك

جنبًا إلى جنب

الشراء لا يعني التخلي عن الواجهة البرمجية

هذا ليس اختيارًا بين شفرة ولوحة تحكم. يبقى لديك الوصول البرمجي — طلبات موقّعة، وصلاحيات لكل مفتاح، وويب هوك بسجل تسليم، ومقاطع شيفرة مولّدة، وساحة تجربة — وتحصل فوق ذلك على الأجزاء التي كنت ستكتبها بنفسك. فالفريق الذي يريد لوحة تحكم يحصل عليها، والمطوّر يحتفظ بواجهة برمجية.

والانتقال ليس إعادة كتابة

السبب المعتاد لبقاء الفرق على تكامل مباشر ليس أنه أفضل، بل أن الانتقال يبدو مكلفًا. ونقاط النهاية المتوافقة تزيل هذه الحجة: المسارات نفسها، وأجسام الطلبات نفسها، والاستجابات نفسها، وغلاف الأخطاء نفسه. غيّر الرابط الأساسي، وبدّل الرمز، واجعل مجموعة اختباراتك الحالية هي فحص الانتقال.