رحلة غير متوقعة: كيف بنيت عملاً قائماً على واجهات برمجية (API) بالصدفة

Updated يونيو 13, 2026 22 min read

Aldawsari

دقائق القراءة: 22

في هذا المقال، سأشارككم رحلتي في بناء عمل تجاري قائم على واجهات برمجية (API)، والتقنيات التي اعتمدت عليها، وكيف يمكنكم بناء مشروعكم الخاص في المستقبل.

بدايةً، دعوني أقدم لكم نبذة عن العمل الذي بنيته: Listen Notes هو محرك بحث للبودكاست يتيح للمستخدمين البحث في ما يقرب من مليوني بودكاست وأكثر من 89 مليون حلقة حسب الأشخاص أو المواضيع. كما نوفر واجهة برمجية للبودكاست للمطورين لاستخدامها، تُعرف باسم Listen API، وقد أصبحت جزءاً أساسياً من أعمالنا.

التحول غير المتوقع: بناء عمل قائم على واجهة برمجية

تركت شركتي الناشئة الفاشلة السابقة في سبتمبر 2017. بعد بضعة أيام من التجريب، اخترت أحد مشاريعي الجانبية الناشئة لتحسين واجهة المستخدم الخاصة به قليلاً. كان هذا المشروع الجانبي هو Listen Notes، وهو موقع ويب لمحرك بحث عن البودكاست، والذي كان مجرد تطبيق React JS أحادي الصفحة يعمل على ثلاث خوادم افتراضية (DigitalOcean droplets) بتكلفة 10 دولارات شهرياً لكل منها. لم أكن أعلم قبل بضع سنوات أن مشروعي الجانبي الصغير المهمل سيتحول إلى هذا العمل المفيد الذي ازدهر.

نسخة مبكرة من Listen Notes

واصلت العمل على Listen Notes بدوام كامل، وتم تأسيس Listen Notes كشركة Delaware C-Corp في أكتوبر 2017. كان أحد أهدافي هو تجربة أكبر عدد ممكن من جوانب العمل، بدلاً من مجرد كتابة الكود خلف الكواليس. كانت خطتي الأولية كالتالي (لا تضحكوا!): بناء موقع ويب لمحرك بحث عن البودكاست وكسب بعض المال من الإعلانات، تماماً مثل Google. بسيط! إذا لم ينجح مشروع Listen Notes هذا في غضون شهرين أو ثلاثة، فسوف ينفد مني المال، وسأضطر إلى الاقتراض ببطاقات الائتمان للاستمرار لمدة شهر آخر أو نحو ذلك. وإذا لم ينجح بعد، فسيتعين علي البحث عن وظيفة بدوام كامل. على الرغم من أن والدي جيف بيزوس استثمرا 300 ألف دولار في Amazon في بداياتها، وأن والدي مارك زوكربيرج أقرضا 100 ألف دولار لـ Facebook في بداياتها، إلا أنه ليست كل عائلة قادرة على ضخ مبالغ ضخمة من المال في مشاريع الويب.

ثم حدث شيء ما. في 20 نوفمبر 2017، تلقيت بريداً إلكترونياً من مطور تطبيق بودكاست جديد، يسأل عما إذا كانت Listen Notes توفر واجهة برمجية (API). كان يرغب في البحث عن الحلقات في تطبيقه، لكنه لم يكن يريد بناء الواجهة الخلفية (backend) بأكملها. طرحت عليه بعض الأسئلة (على سبيل المثال، كيف ستبدو نقاط النهاية (endpoints)، وما هي حقول البيانات التي يحتاجها، وكم كان مستعداً للدفع…). تلقيت إجاباته. كان كل شيء في سلسلة رسائل بريد إلكتروني في غضون يومين.

في 30 نوفمبر 2017، قمت بتنفيذ ثلاث نقاط نهاية بسرعة (GET /search، GET /podcasts/{id}، و GET /episodes/{id})، والتي كانت في الأساس ثلاث طرق عرض (Django views). بحثت في Google عن “بوابة API” أو شيء من هذا القبيل ووجدت خدمة تسمى Mashape، والتي كانت سوقاً لواجهات API تتعامل مع الدفع وإدارة المستخدمين وتوثيق API. لذا، وضعت نقاط النهاية الثلاث الخاصة بي على Mashape وأنشأت خطتين هناك: FREE و PRO. أرسلت بريداً إلكترونياً للمطور لأخبره أن الواجهة البرمجية جاهزة للاستخدام.

سلسلة رسائل البريد الإلكتروني التي دفعتني لبناء Listen API

ثم لم يحدث شيء. لم يستخدم مطور تطبيق البودكاست واجهتنا البرمجية وبدلاً من ذلك أوقف مشروعه. في النهاية، انتقلت للتركيز بشكل أساسي على تطوير موقع listennotes.com. كانت الواجهة البرمجية تعمل بشكل تلقائي على الويب المفتوح. يمكن لأي شخص يكتشف واجهتنا البرمجية التسجيل دون التحدث إلى أي بشر. في 14 يناير 2018، حصلت على أول مستخدم يدفع. وصل عدد قليل من المستخدمين الآخرين الذين يدفعون في نفس العام.

إشعار البريد الإلكتروني الذي تلقيته لأول مستخدم يدفع

تحديات مع منصات الطرف الثالث: دروس مستفادة من RapidAPI

ما هي RapidAPI؟ حسناً، استحوذت شركة ناشئة تسمى RapidAPI على Mashape. لم يعيدوا تسمية Mashape إلى RapidAPI بالكامل حتى منتصف عام 2018. عادةً لا تقوم الشركات الناشئة بالأشياء بطريقة نظيفة ومنهجية، وهو أمر مفهوم تماماً. ثم حدث شيء ما. كان هناك انقطاع في خدمة RapidAPI في 29 نوفمبر 2018.

البريد الإلكتروني الذي أرسلته إلى RapidAPI عندما حدث الانقطاع

كانت RapidAPI قد أجرت ترقية كبيرة للواجهة الخلفية (backend) في ذلك الوقت. كمهندس، أتفهم تماماً أن الانقطاعات تحدث، خاصة عند إجراء تغييرات ضخمة في الواجهة الخلفية. لكنني شعرت بالعجز لأن دعم العملاء لديهم لم يرد على بريدي الإلكتروني. لم تنجح المكالمات الهاتفية، كما هو متوقع. عادةً ما كان دعم العملاء لديهم سريع الاستجابة جداً. ربما كان موسم العطلات وكان الناس في إجازة. لذلك استخدمت hunter.io للعثور على رسائل البريد الإلكتروني الوظيفية لموظفي RapidAPI، والمدير التنفيذي، وكذلك المدير التقني. تم حل المشكلة أخيراً، بعد ساعات عديدة. بعبارة أخرى، كانت واجهتنا البرمجية غير قابلة للاستخدام تماماً خلال ساعات التوقف تلك. شعرت بالأسف الشديد لمستخدمينا الذين يدفعون.

ثم في منتصف فبراير 2019 تقريباً، واجهت RapidAPI مشاكل في الفواتير وفشلت في دفع بضعة آلاف من الدولارات لنا. كان مستخدمونا الذين يدفعون، يدفعون لـ RapidAPI أولاً. كانت RapidAPI تأخذ نسبة 20%، ثم تدفع لنا الـ 80% المتبقية (مطروحاً منها رسوم PayPal). بعد عدة رسائل بريد إلكتروني ومكالمات هاتفية ذهاباً وإياباً، حصلنا أخيراً على دفعتنا. إنه أمر مفهوم. مرة أخرى، ترتكب الشركات الناشئة أخطاء.

التحكم في المصير: بناء نظام API الخاص بنا

في أواخر فبراير 2019، قررت بناء بديل خاص بنا لـ RapidAPI، لعدة أسباب:

أصبحت إيرادات واجهة API لدينا كبيرة.
كانت نسبة الـ 20% التي تأخذها RapidAPI مرتفعة جداً بالنسبة لنا.
أردنا أن تصل طلبات API إلى خوادمنا مباشرة، وبالتالي تقليل زمن الاستجابة لمستخدمينا.
لم أكن أرغب في الشعور بالعجز عندما تحدث انقطاعات في RapidAPI. بشكل عام، قاموا بعمل جيد في إدارة الخدمة، لكنني أردت التحكم في مصيري.
أردت التواصل مع مستخدمي API مباشرة. باستخدام RapidAPI، لم يتمكن مقدمو API مثلي من الوصول إلى عناوين البريد الإلكتروني لمستخدمينا. هذا أمر مفهوم، فهو يشبه شركات “Uber for X” التي لا تريد أن يتجاوزها العمال والعملاء ويعقدوا صفقات مباشرة. لا ترغب الأسواق في أن يتجاوز المستخدمون رسوم عمولة الوسيط.

بالإضافة إلى ذلك، تعهدت بالقيام بشيئين بشكل جيد حقاً لنظام API الجديد لدينا:

يجب أن نقدم خدمة عملاء ممتازة لمستخدمينا الذين يدفعون.
سنوفر للعملاء خدمة خلفية مستقرة وموثوقة للغاية.

بعد 30 يوماً من العمل الشاق، أطلقنا Listen API v2 في 27 مارس 2019. أصبحت الواجهة البرمجية القديمة المستضافة على RapidAPI هي Listen API v1، وهي نسخة لن نضيف إليها ميزات جديدة ولكننا لا نرغب في إيقافها لأن بعض التطبيقات لا تزال تستخدمها اعتباراً من ديسمبر 2020! نواصل تحسين Listen API v2 الجديدة لدينا عن طريق إضافة نقاط نهاية جديدة، وحقول بيانات جديدة، وتحسين الكفاءة التشغيلية، بالإضافة إلى تحسين لوحة تحكم المستخدم وأدواتنا الداخلية. تتسارع الأمور تدريجياً. لقد كنت سعيداً منذ ذلك الحين. هذه هي رحلة Listen API حتى الآن.

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

التقنيات وراء `Listen API`: البنية التحتية والتشغيل

يمكن للمطورين استخدام واجهتنا البرمجية للبحث عن البودكاست وجلب بيانات وصفية مفصلة للحلقات. لجعل هذا الأمر يعمل بالكامل، نحتاج إلى التأكد من وجود بعض المكونات الأساسية.

المكونات الرئيسية لـ Listen API والتقنيات المستخدمة

مخزن البيانات ومحرك البحث

هذا مكون مشترك مع موقعنا الإلكتروني. لذلك، لم أكن بحاجة إلى تغيير أي شيء في مخزن البيانات ومحرك البحث عند بناء البنية التحتية لواجهتنا البرمجية. نستخدم Postgres كمخزن بيانات رئيسي (على سبيل المثال، للبيانات الوصفية للبودكاست، وحسابات المستخدمين، وما إلى ذلك)، و Elasticsearch كمحرك بحث. لقد كتبت منشوراً قديماً على المدونة يحتوي على تفاصيل مكدس التقنية (tech stack) بأكمله.

الأدوات والعمليات الداخلية

إذا كنت قد عملت في أي شركات ويب، فربما تعرف ما أشير إليه هنا. من النادر أن يكون العمل التجاري عبر الإنترنت مؤتمتاً بنسبة 100%. تحتاج الشركة دائماً إلى بناء الكثير من الأدوات الداخلية وإعداد عمليات يدوية للحفاظ على الخدمة تعمل. لهذا السبب تتمتع شركات مثل Retool بتقييم عالٍ في الوقت الحاضر. تستثمر الشركات أموالاً طائلة في الأدوات الداخلية غير المرئية للمستخدمين النهائيين:

نسبة الوقت الذي يقضيه الفريق في الأدوات الداخلية. المصدر: Retool

لبدء عملنا القائم على واجهة برمجية، احتجنا إلى بناء (على الأقل) نوعين من الأدوات الداخلية:

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

تُستخدم الأدوات الداخلية من قبل الموظفين داخل الشركة. بعض هذه الأدوات مؤتمتة بالكامل، مثل مهام cron jobs التي تؤدي مهاماً مجدولة. لكن العديد من الأدوات يجب أن تُستخدم يدوياً من قبل الموظفين، على سبيل المثال عند إدخال رقم تعريف المستخدم والنقر على زر. معظم أدواتنا الداخلية تحتوي على واجهات مستخدم ويب قبيحة، مع تصميم Bootstrap الافتراضي 🙂

جزء من واجهة المستخدم لأداتنا الداخلية التي تتيح لنا تعليق حساب مستخدم API.

لحسن الحظ، تشارك واجهتنا البرمجية العديد من الأدوات الداخلية مع الموقع الإلكتروني. لذلك لم نكن بحاجة إلى بناء الكثير من الأشياء الجديدة هنا.

نظام التحليلات والفوترة

نموذج تسعير الواجهة البرمجية (API) عادة ما يكون قائماً على الاستخدام. تحقق من بعض الأمثلة الواقعية:

من الضروري تتبع عدد الطلبات التي يستخدمها المستخدم في الوقت الفعلي. نستخدم Redis لتتبع هذه الإحصائيات ونقوم بتفريغها بشكل دوري في Postgres للتخزين الدائم. ماذا يحدث إذا تعرض Redis لانقطاع؟ قد نفقد مؤقتاً بعض إحصائيات التتبع. في هذه الحالة، لدينا أداة داخلية لمزامنة الإحصائيات من سجلات Nginx الخام.

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

يجب التعامل مع فشل الدفع، وهو أمر شائع جداً، بشكل سلس. لا يمكننا تعليق المستخدمين على الفور. نحتاج إلى أن نكون قادرين على إخطار أنفسنا بأن “هذا المستخدم فشل في الدفع” وإخطار المستخدم بأن “فشلت في الدفع”. بعد بضع محاولات، نقوم بتعليق المستخدمين يدوياً – حسناً، كان بإمكاننا أتمتة هذه الخطوة الأخيرة. لكننا لا نعلق المستخدمين كثيراً في الوقت الحاضر، لذلك لا بأس في القيام بذلك يدوياً. ليست هناك حاجة لجعل كل شيء مثالياً (على الأقل في الوقت الحالي).

لدينا لوحة تحكم (God's view) لرؤية عدد الطلبات التي يستخدمها كل مستخدم في دورة الفوترة الحالية. ونحن قادرون على مراجعة السجلات الخام لكل مستخدم من واجهة مستخدم الويب، دون سحب ملفات السجل يدوياً من S3.

Stripe و PayPal (عبر Braintree) هما معالجا الدفع لدينا. يستخدم معظم مستخدمينا الدوليين PayPal. أخيراً، بجمع كل هذه العوامل معاً، يمكننا حساب المبلغ الفعلي الذي يجب أن يدفعه لنا المستخدم في الوقت الفعلي، بناءً على استخدامه. نقوم بتشغيل مهام غير متزامنة (async tasks) عبر Celery لتحصيل الفواتير المستحقة. ماذا يحدث إذا ألغى المستخدم اشتراكه في منتصف دورة الفوترة؟ نقوم بتحصيل رسوم متناسبة مع المدة والاستخدام. لا يحتاج المستخدمون إلى دفع رسوم شهر كامل في تلك الحالات.

خوادم `API`

نقوم بتشغيل تطبيقات Django لخدمة طلبات API. كل نقطة نهاية هي طريقة عرض Django بسيطة. يتحقق وسيط Django (Django middleware) مما إذا كان الطلب شرعياً، ثم ينشئ سجلاً أو يرفض الطلب على الفور. نقوم بتخزين بيانات الاستجابة مؤقتاً لكل مفتاح API + عنوان URL فريد في Redis. بشكل عام، أداء واجهتنا البرمجية جيد جداً.

نستخدم Nginx كموازن تحميل (load balancer) ونوفر عدة خوادم API. من السهل إجراء نشر متدرج (rolling deployment) هنا، مع مجموعة من فحوصات السلامة لضمان عمل API. بشكل عام، تزيد عملية النشر السهلة والقوية من ثقتي في إجراء تغييرات تدريجية في الكود بشكل متكرر والنشر بشكل متكرر.

نقطة نهاية API هي RESTful وتُرجع استجابة JSON، وهو معيار قياسي في الوقت الحاضر.

لوحة تحكم المستخدم ووثائق `API`

يمكن لكل مستخدم API الوصول إلى لوحة تحكم على موقعنا الإلكتروني لمعرفة عدد الطلبات التي استخدمها في دورة الفوترة الحالية وعرض السجلات الخام الحديثة. يمكنهم أيضاً تحديث طرق الدفع، وإنشاء أو إعادة تعيين مفاتيح API جديدة، وإعداد webhooks، وإضافة زملاء عمل إلى نفس حساب API.

لوحة تحكم مستخدم Listen API

ربما تكون وثائق API هي أهم واجهة مستخدم (UI) لأي عمل قائم على واجهة برمجية. لذلك، توظف العديد من شركات API فريقاً كاملاً من المهندسين بدوام كامل لبناء وصيانة صفحات وثائق API “فقط”. صفحة وثائق API ليست مجرد صفحة كاملة من الكلمات الإنجليزية. يجب أن تعرض مقتطفات برمجية للغات برمجة مختلفة. يجب أن يكون المستخدمون قادرين على تشغيل مثال الكود الخاص بك مباشرة من الصفحة. يُطلب منك تصميم عملية قابلة للتكرار (سواء كانت تلقائية أو يدوية) للحفاظ على مزامنة الوثائق مع الكود الخاص بك. هناك الكثير من الفروق الدقيقة. لقد قضينا الكثير من الوقت والطاقة في بناء وتكرار إصدارات متعددة من صفحة وثائق API الخاصة بنا. فيما يلي النتيجة النهائية:

صفحة وثائق Listen API

في البداية، جربنا بعض الحلول مفتوحة المصدر لتوثيق API. يستغرق الأمر وقتاً طويلاً لفهم مشروع مفتوح المصدر جيداً بما يكفي لتخصيصه. في النهاية، قررنا أنه سيكون أسرع بناء الصفحة من الصفر بدلاً من تخصيص حل مفتوح المصدر بناه آخرون. صفحة وثائق API الخاصة بنا هي في الأساس تطبيق React JS أحادي الصفحة. نقوم بترميز جميع نقاط النهاية، ومخطط بيانات الاستجابة، والاستجابة النموذجية في مواصفات OpenAPI spec. يقرأ تطبيق React JS الخاص بصفحة وثائق API مباشرة من مواصفات OpenAPI الخاصة بنا. التأثير الجانبي لاستخدام OpenAPI هو أنه يمكننا التكامل بسهولة مع أدوات مثل Postman، لأن OpenAPI هو معيار معتمد على نطاق واسع (نسبياً) لتوثيق API في الوقت الحاضر.

عوامل النجاح: لماذا يزدهر `Listen API`؟

لقد كان Listen API عملاً جيداً بالنسبة لي حتى الآن. لكن لا تتوقعوا مني أن أشارك أرقام الإيرادات علناً 🙂 بعض الشركات تقوم بهذا الأمر المفتوح للشركات الناشئة، حيث تشارك كل مقياس عمل للجمهور، وهو أمر رائع. لكن لا ينبغي أن نلوم غالبية الشركات (بما في ذلك شركتي الصغيرة Listen Notes, Inc.) التي لا ترغب في مشاركة مقاييس العمل علناً. ليس الجميع مرتاحاً لكونه عارياً في الأماكن العامة، حرفياً أو مجازياً.

وبالمثل، هناك الكثير من نصائح العمل (أو الكليشيهات) التي لا يتعين عليك اتباعها. ليس عليك العثور على شريك مؤسس – فوجود شريك مؤسس فظيع أسوأ بكثير من عدم وجوده. ليس عليك الكشف عن إيراداتك للجمهور أو القيام بأي شيء من “الشركات الناشئة المفتوحة”. لا يوجد ضغط. لا تشعر بالذنب إذا لم تكن تفعل ما يفعله “الأطفال الرائعون” الآخرون. أنت تدير شركتك الخاصة. أنت تتخذ قراراتك الخاصة. ليس عليك أن تفعل XYZ الذي يحثك عليه “فيلسوف رأس المال المخاطر على تويتر” في تغريدة تشبه “بسكويت الحظ”. ليس عليك أن تكون ممولاً ذاتياً بنسبة 100% ولا ممولاً من رأس المال المخاطر بنسبة 100%. العديد من الأشياء ليست إما هذا أو ذاك تماماً. عادة، هناك حل وسط. … والقائمة تطول.

الخلاصة هي أن لا شيء خاطئ تماماً أو صحيح تماماً. رؤية/معرفة كل فرد محدودة. قد تكون تفضيلات كل شخص مختلفة جداً. قد يكون العمل القائم على واجهات API غامضاً جداً لمعظم الناس في العالم، لكنني أحب عملي القائم على واجهات API كثيراً. قد يدرس الأشخاص من الشركات الكبيرة (مثل Apple أو Amazon أو Microsoft) عملي ويعتبرونه “لطيفاً”. لكنني سأعتبره نجاحاً بالنسبة لي شخصياً. والنجاح نسبي. المفتاح هو جلب السعادة للعملاء (من خلال توفير الوقت والمال ومساعدتهم في حل المشكلات)، ولنفسي (إنجاز مهني)، ولعائلتي (من خلال إبقاء الثلاجة ممتلئة).

إذاً، لماذا يعمل Listen API؟

الطلب والمنتج الأدنى القابل للتطبيق (`MVP`)

لم أبني حلاً لأجد له مشكلة. بل كانت المشكلة (تطبيق بودكاست أراد إضافة وظيفة البحث) هي التي وجدتنا – وبنينا حلاً بسيطاً جداً في البداية. لم نقضِ شهوراً في إطلاق الواجهة البرمجية. قضينا بضع ساعات. يكلف توظيف مهندس ليس سيئاً في سان فرانسيسكو ما لا يقل عن 100 دولار في الساعة، لذلك كانت تكلفة إطلاق هذا المنتج الأدنى القابل للتطبيق (API MVP) حوالي 200 دولار. حتى لو كانت 2000 دولار، كنت سأظل أعتقد أنها تستحق العناء.

سببان لتمكننا من إطلاق MVP بسرعة:

تم بالفعل إنجاز الجزء الصعب من بناء قاعدة بيانات بودكاست، ومحرك بحث، وأداة عمليات البيانات، بسبب موقع محرك البحث عن البودكاست الخاص بنا.
كانت Mashape / RapidAPI موجودة لتوفير حل جاهز لنا لإدارة المستخدمين وإنشاء خطط مدفوعة دون كتابة كود من جانبنا.

ومع ذلك، بالنظر إلى الوراء، من الشائع جداً أن يقوم محرك بحث تجاري بترخيص تقنيته (عبر API أو طرق أخرى). بعض الأمثلة:

كان Yahoo Search مدعوماً من Google حوالي عام 2000، وهو مدعوم من Bing اليوم.
في الأيام الأولى، كان نموذج عمل Baidu الوحيد هو وضع بحث ويب على بعض مواقع البوابات الصينية.
اليوم، يوفر Bing مجموعة من واجهات Search APIs.

من خلال إطلاق MVP بسرعة، تمكنا من الحصول على تعليقات مبكرة، خاصة بعد الحصول على أول مستخدم يدفع بعد شهر واحد فقط من الإطلاق.

وثائق ممتازة

تثبت ملاحظات المستخدمين أن صفحة وثائق API الخاصة بنا تلعب دوراً مهماً في قرارات العملاء لاستخدام واجهتنا البرمجية. يجب أن يكون هناك سبب لتوظيف شركات API فريقاً كاملاً من المهندسين “فقط” لصيانة صفحات وثائقهم. التوثيق الممتاز يبني الثقة.

خدمة خلفية مستقرة

الاستقرار هو القاعدة الأساسية في هرم ماسلو لاحتياجات عمل API. إذا كانت الواجهة البرمجية غير مستقرة على الإطلاق (على سبيل المثال، لديها انقطاعات متكررة أو تعمل ببطء شديد)، فلا يمكن استخدامها. ومع ذلك، من الممل أداء العمل لتحسين استقرار الواجهة الخلفية. معظم المهام لتحقيق استقرار خدمات الواجهة الخلفية وقائية، بما في ذلك المراقبة والتنبيهات الشاملة، وعملية نشر الكود بثقة، واختبارات الانحدار الشاملة (end-to-end regression tests)، وما إلى ذلك. لا أخبار هي أخبار جيدة. لا انقطاعات هي أخبار رائعة.

نستخدم Statuspage.io لربط مقاييس Datadog الخاصة بنا لبناء صفحة حالة: listennotesstatus.com.

صفحة حالة نظام Listen Notes

نأمل أن تقنع صفحة الحالة هذه مستخدمينا المحتملين بتجربة واجهتنا البرمجية 🙂

خدمة عملاء ممتازة

كلنا عملاء لمنتجات وخدمات الآخرين. وقد شعرنا جميعاً بالإحباط من سوء خدمة العملاء في مرحلة ما من حياتنا. من الواضح أن خدمة العملاء الممتازة تقطع شوطاً طويلاً – RIP, Tony. قد لا يدرك الكثير من الناس أن عليك دفع مبالغ كبيرة لـ AWS للوصول إلى خدمة عملاء أفضل! عملاؤنا لا يدفعون لنا فقط مقابل استخدام واجهتنا البرمجية، وهي خدمة عبر الإنترنت. بل يدفعون أيضاً مقابل الحصول على مساعدة عملاء عالية الجودة من بشر حقيقيين. في حالتنا، أنا الشخص الذي بنى هذا الشيء. أستخدم Superhuman لمعالجة رسائل البريد الإلكتروني بسرعة وكفاءة. ولدي الكثير من قوالب البريد الإلكتروني المكتوبة مسبقاً للتعامل مع تذاكر دعم العملاء الأكثر شيوعاً. غالباً ما أستطيع الرد على بريد إلكتروني في غضون 5 ثوانٍ، باستخدام CMD + K لتحديد قالب بريد إلكتروني.

الاستثمار في الأدوات والعمليات الداخلية

بالنسبة للعمل المعرفي، من الممكن أن يقوم شخص واحد (أو فريق صغير جداً) بإنشاء قيمة أكبر بـ 10 أضعاف، 100 ضعف، أو حتى 1000 ضعف من فريق كبير. لننظر إلى مثال متطرف: نشر الكتب. من المستحيل (تقريباً) توظيف 10,000 كاتب جيد للتعاون في كتاب واحد معاً على أمل أن يكون “أفضل” بشكل متماسك من هاري بوتر، الذي كتبته مؤلفة واحدة. جي كي رولينغ، شخص واحد، خلقت قيمة أكبر بكثير (من حيث المبلغ المقاس بالدولار والسعادة غير المقاسة، والأوقات الجيدة) من معظم الشركات التي تضم مئات الموظفين في العالم. في النهاية، ستنمو أعمال البرمجيات بطريقة مماثلة. لقد شهدنا بالفعل استحواذ Instagram التي تضم 13 موظفاً مقابل مليار دولار في عام 2012. متى سنرى شركة برمجيات/إنترنت تزيد قيمتها عن مليار دولار تضم 5 موظفين أو أقل تحقق نفس الإنجاز؟

توفر الأدوات والعمليات الداخلية الرائعة قوة دفع لتمكين فريق صغير من أن يكون فائق الكفاءة. هذا سهل الفهم. لقد بنينا نحن البشر بالفعل الكثير من الأدوات لتوسيع حدودنا الجسدية/العقلية بشكل كبير، على سبيل المثال الدراجات والسيارات (مقابل المشي)، وأجهزة الكمبيوتر (مقابل الحساب اليدوي)، وما إلى ذلك. بالنظر إلى أنه من المستحيل (تقريباً) أتمتة عمل تجاري عبر الإنترنت بنسبة 100%، يجب علينا تحسين كفاءة العمليات اليدوية. إنه استثمار رائع لزيادة إنتاجية المشغلين البشريين.

نصائح عملية لإدارة عمل قائم على `API`

إليكم بعض الأشياء التي لم أكن أعرفها من قبل…

من يمكنه التسجيل => يجب تقديم طلب أولاً

قبل بضع سنوات، لاحظت أن بعض واجهات API تطلب مني تقديم طلب أولاً، يصف حالة الاستخدام الخاصة بي، قبل إعطائي مفتاح API. لم أفهم المنطق وراء ذلك في ذلك الوقت. بعد إدارة عملي الخاص القائم على واجهة برمجية، أصبحت أفهم الآن. الإنترنت ضخم. العالم هائل. هناك أناس جيدون وأناس سيئون. إذا كانت الواجهة البرمجية التي تقدمها مفيدة، فسيحاول بعض الأشخاص إساءة استخدامها. هذا ما حدث عندما سمحنا في البداية لأي شخص بإنشاء حساب API. كنا نرى مستخدمين ينشئون عشرات الحسابات للتحايل على حد الحصة المجانية. اليوم، نطلب من الأشخاص تقديم طلب أولاً. نتلقى إشعاراً عبر Slack. ثم نستخدم أداتنا الداخلية لمراجعة الطلب والموافقة عليه أو رفضه. يتلقى مقدم الطلب بريداً إلكترونياً تلقائياً. من جانبنا، يستغرق الأمر نقرتين أو ثلاث نقرات لإنهاء كل هذه العمليات.

لمساعدة عملية المراجعة لدينا، نستخدم مجموعة من الاستدلالات (heuristics):

هل أنشأ هذا المستخدم حسابات متعددة من قبل؟
هل عنوان IP address هذا هو مرسل بريد عشوائي معروف يمكن اكتشافه عبر stopforumspam.com؟ (تلميح: هناك API لذلك)
وهكذا…

مرة أخرى، نرى حالات حافة جديدة من وقت لآخر. ومع ذلك، نتعلم أيضاً كيفية التعامل مع تلك الحالات الفريدة.

العملاء المثاليون والعملاء المثيرون للاهتمام

أفضل عملائنا هم في الغالب مؤسسو شركات ناشئة يعملون في مجال الأعمال منذ فترة طويلة. يمكنهم اتخاذ القرارات بأنفسهم. إنهم يفهمون القيمة التي نقدمها. لديهم القدرة على اتخاذ قرارات الشراء النهائية. وهم أكفاء بما يكفي لقراءة وثائقنا بشكل مستقل وطرح عدد قليل جداً من الأسئلة – أو حتى لا يتحدثون إلينا على الإطلاق.

من ناحية أخرى، غالباً ما يطلب الأشخاص من الشركات الناشئة الممولة جيداً من رأس المال المخاطر (VC-backed startups) أو الشركات الضخمة (بعض أكبر الشركات في العالم) خصماً أو تجربة مجانية، وهو ما لا نقدمه. لماذا؟ ليس لدي إجابة جيدة هنا. بالطبع، هناك دائماً استثناءات.

ورش عمل المطورين ومعسكرات البرمجة (`Coding Bootcamps`)

يستأجر العديد من مستخدمينا مستقلين أو ورش عمل تطوير (dev shops) في الخارج لبناء تطبيقات ومواقع ويب. بشكل عام، المطورون من ورش العمل ليسوا جيدين مثل المطورين الداخليين. على الرغم من أن هذا ليس صحيحاً بنسبة 100%، إلا أن الاحتمال مرتفع جداً. في جوهر الأمر، الكثير من ردودي على دعم العملاء هي لتعليم أساسيات علوم الحاسوب (Computer Science 101). أحياناً يرسلون مقتطفات برمجية بلغة PHP (أو لغة لا أعرفها) ليطلبوا منا تصحيحها عبر البريد الإلكتروني. أتفهم أن بعض هؤلاء المطورين من ورش العمل تخرجوا للتو من معسكرات البرمجة (أو أن ورشة العمل نفسها هي معسكر برمجة). في معظم الأحيان سأبحث لهم في Google وأرسل لهم رابط StackOverflow أو شيء من هذا القبيل. ولكن في بعض الأحيان، إذا كنت في مزاج سيء، فلن أرد على رسائل البريد الإلكتروني “ساعدني في تصحيح كود PHP الخاص بي” من المستخدمين المجانيين الذين لا يدفعون لنا.

أيضاً، تستخدم عدد لا بأس به من معسكرات البرمجة واجهتنا البرمجية لتعليم الطلاب كيفية كتابة الكود، وهو أمر رائع. في مشاريع الويب الواقعية، لا يمكنك تجنب استخدام واجهات REST APIs من جهات خارجية. تعليم المبرمجين الجدد كيفية التحدث إلى واجهة REST API أمر ضروري.

العمل القائم على `API` عمل بطيء

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

العمل القائم على `API` عمل مستقر

معدل التوقف عن استخدام الخدمة (churn rate) لدينا منخفض جداً. يقضي الناس شهوراً عديدة في بناء تطبيق باستخدام واجهتنا البرمجية، لذلك من غير المرجح أن يتحولوا إلى شيء آخر بين عشية وضحاها. أنا سعيد بهذه الحقيقة. وفي الوقت نفسه، أنا متفائل جداً بجميع أعمال API الأخرى الموجودة، مثل Stripe و Plaid و Twilio. (هذه ليست نصيحة استثمارية، ولكن انظر إلى سهم TWLO).

ابدأ بالعملاء الكبار، ثم نوع

في المرحلة المبكرة، قد يكون هناك عدد قليل من المستخدمين “الحيتان” الذين يمثلون جزءاً كبيراً أو حتى معظم الإيرادات. لا داعي للذعر. الحصول على إيرادات أفضل من عدم الحصول عليها على الإطلاق. نحن لسنا في وضع يسمح لنا بأن نكون انتقائيين في المرحلة المبكرة. يمكننا التنويع على طول الطريق. أحب قراءة تقارير S-1. ليس من غير المألوف رؤية بعض شركات SaaS أو API لديها عدد قليل من “الحيتان” عندما أصبحت شركات عامة. إذا فقدت واحدة أو اثنتين من هذه “الحيتان”، فإن إيراداتها ستنخفض بنسبة 10%، أو حتى 20% + على الفور! حسناً، إنها بالفعل شركة عامة. لا داعي للقلق بشأنها. إنهم يعرفون ما يجب فعله بعد ذلك.

التسعير عمل قيد التنفيذ

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

الكارهون / الانتقادات غير ذات الصلة

ربما رأيت هذه النظرية: عندما يكون لديك كارهون، فأنت تفعل شيئاً صحيحاً. هناك اقتباس مشابه من Zeng Guofan (أحد أهم القادة العسكريين والسياسيين في الصين في القرن التاسع عشر): 不招人妒者皆庸才. “إذا لم يحسدك أحد، فأنت غير كفء.”

ملاحظة جانبية: يمكنك العثور على حكمة Zeng Guofan داخل العديد من مكتبات المطارات في الصين. كان سيكون مستخدماً رائعاً لـ Twitter وسيتفوق على فلاسفة رأس المال المخاطر على Twitter لو ولد في عصرنا – من الصعب التغلب على شخصية تاريخية صينية في لعبة “بسكويت الحظ” 🙂

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

أحياناً يحاول الناس مقارنة شيئين لهما أسماء متشابهة. على سبيل المثال، إذا بحثت عن “podcast API” على Google، ستجد بعض واجهات API الأخرى التي تحمل “podcast API” في أسمائها. ومع ذلك، إذا قضيت بضع دقائق في تصفح الوثائق، ستجد اختلافات واضحة. إنه مثل مقارنة شخصين لهما نفس الاسم الأول واسم العائلة وهما شخصان مختلفان تماماً في النهاية.

الانتقادات أو الاقتراحات الوحيدة التي أهتم بها هي في الغالب من مستخدمينا. يمكنني رؤية استخدامهم لواجهة API. أعلم أنهم يعبرون عن حقائق ذات معنى. لذلك أستمع إليهم.

هل أنت مهتم ببناء عمل قائم على `API`؟

في الوقت الحاضر، “اقتصاد الشغف” (passion economy) أو “اقتصاد المبدعين” (creator economy) رائج. من هم المبدعون؟ كتاب، مقدمو بودكاست، مبثوثون… لا تنسوا أن مطوري البرمجيات هم أيضاً مبدعون! إذا كنت تدير موقعاً إلكترونياً بالفعل أو لديك بعض البيانات المثيرة للاهتمام، فقد تبدأ عملاً قائماً على واجهة برمجية أيضاً. شكراً لقراءتكم هذا المقال الطويل 🙂

دعوني أعرف رأيكم: wenbin@listennotes.com. ويمكنكم قراءة المزيد من منشوراتي على مدونتي.

الخلاصة التقنية

تُظهر قصة Listen API أن النجاح في عالم التقنية لا يتبع دائماً مساراً مخططاً له. بدأت كحل لمشكلة محددة، وتطورت لتصبح عملاً مستقلاً بفضل الطلب الفعلي، مع التركيز على بناء منتج أدنى قابل للتطبيق (MVP) سريعاً. أبرزت التجربة أهمية التحكم في البنية التحتية الخاصة (بعد تحديات مع RapidAPI)، والاستثمار في أدوات داخلية قوية، وتوفير وثائق API ممتازة، وخدمة عملاء استثنائية. كما كشفت عن طبيعة عمل API كعمل بطيء النمو ولكنه مستقر، مع الحاجة إلى استراتيجيات تسعير مرنة والقدرة على تصفية الانتقادات غير البناءة. هذه الرحلة تؤكد أن الابتكار الحقيقي ينبع من تلبية الاحتياجات العملية، مع تبني المرونة والتحسين المستمر.