السلام عليكم ورحمة الله وبركاته،
ضمن خارطة الطريق القادمة لمنصة إتقان في مشروع فنار الذي يعمل على توزيع المحتوى القرآني، عندنا بند اسمه «الواجهات الذكية» (Smart APIs)، وفكرته باختصار:
بدلاً من أن يطلب المطوّر نص الآية من نقطة، والترجمة من نقطة ثانية، والتفسير من ثالثة — يطلبها كلها بطلب واحد، ويحدّد ما يريده عبر معامل include.
مثال للشكل المقترح:
GET /ayahs/2:255?include=translation,tafsir,words
فيرجع النص، والترجمة، والتفسير، وبيانات الكلمات — في استجابة واحدة، بدل أربعة طلبات منفصلة.
قبل أن نبني هذه الميزة، نريد أن نسمع منكم. نحن لا نسأل «هل تبدو الفكرة جميلة؟» — الفكرة تبدو جميلة دائماً على الورق. نسأل: هل ستستخدمونها فعلاً في تطبيقاتكم، أم أنها تكرار لما تفعلونه اليوم بطريقة تناسبكم أصلاً؟
السؤال الأول: هل هي مفيدة أم مكرّرة؟
بصراحة تامة، هذه حجج ضدّ الفكرة نطرحها نحن على أنفسنا:
- من يبني تطبيقاً جادّاً غالباً ينزّل البيانات مرة واحدة ويخزّنها محلياً، ولا يطلبها آية بآية أثناء التشغيل. فمن يحتاج هذه الواجهة إذن؟
- الطلبات المتعددة ليست مشكلة حقيقية في كثير من الحالات، خصوصاً مع التخزين المؤقت (caching).
- الواجهة المرنة أصعب في التخزين المؤقت وأثقل على الخادم من نقاط بسيطة ومحدّدة.
وهذه حجج مع الفكرة:
- صفحة «عرض آية» في تطبيق ويب أو موبايل تحتاج فعلاً كل هذه البيانات مجتمعة في لحظة واحدة.
- التجربة الأولى للمطوّر تصبح أسهل بكثير: طلب واحد يريه كل ما تقدّمه المنصة.
- حالات مثل نتائج البحث أو المشاركة أو الحفظ تحتاج الآية «كاملة» لا مجزّأة.
رأيكم أنتم هو المرجّح. إن كان أغلبكم ينزّل البيانات دفعة واحدة ويعمل offline، فربما الأولى أن نستثمر الجهد في تحسين التنزيل المجمّع والحزم بدل واجهة استعلام مرنة.
السؤال الثاني: كيف نتعامل مع تعدّد المصادر؟
هنا التصميم يصبح صعباً، ونحتاج رأيكم تحديداً:
تعدّد الترجمات والتفاسير
للآية الواحدة قد يوجد أكثر من ترجمة (بلغات مختلفة، أو عدة ترجمات في اللغة نفسها)، وأكثر من تفسير (الطبري، ابن كثير، السعدي، الميسّر…). فماذا يجب أن يحدث عند ?include=tafsir دون تحديد؟
- إرجاع كل التفاسير المتاحة — شامل، لكن الاستجابة قد تصبح ضخمة جداً.
- إلزام المطوّر بالتحديد، مثل
?tafsir=ibn-kathir,saadi&translation=ar.muyassar — أدقّ، لكن يتطلب معرفة مسبقة بالمعرّفات.
- إرجاع تفسير افتراضي واحد مع إتاحة التخصيص — أسهل بداية، لكن: من يقرّر الافتراضي؟ هذا قرار له بُعد شرعي وتحريري لا تقني فقط، ولا نريد أن نتخذه نيابة عنكم بلا نقاش.
ما رأيكم؟ وهل يجب أن يكون تحديد اللغة (?lang=ar,en) بُعداً مستقلاً عن تحديد المصدر؟
نصّ الآية نفسه
هل نُرجع النص الخام للآية ضمن الاستجابة؟ وبأي رسم؟
- الرسم العثماني — وهو المتوفر حالياً عندنا.
- النص الإملائي/المبسّط — مهم جداً لحالات البحث والمطابقة النصّية، لأن البحث في الرسم العثماني بالتشكيل صعب على المستخدم.
- بدون تشكيل — لحالات البحث والفهرسة.
سؤالنا العملي: هل تحتاجون أكثر من رسم في الاستجابة نفسها (مثلاً text.uthmani وtext.simple معاً)، أم أن رسماً واحداً يكفي وتتولّون التحويل عندكم؟ هذا يؤثر مباشرة على ما سنخزّنه، لأن المتوفر اليوم هو الرسم العثماني فقط.
السؤال الثالث: ما أفضل طريقة لتقديم الميزة؟
عندنا أكثر من مسار ممكن، ولكلٍّ ثمن:
| الطريقة | الميزة | العيب |
|---|
?include= على نقطة الآية | بسيطة ومألوفة، سهلة التوثيق | قد تتضخّم مع كثرة الخيارات |
| نقطة «مجمّعة» منفصلة للآية الكاملة | واضحة الغرض، سهلة التخزين المؤقت | أقل مرونة |
| GraphQL | مرونة كاملة، المطوّر يطلب ما يريد بدقة | تعقيد أكبر علينا وعليكم، وتخزين مؤقت أصعب |
| تنزيل مجمّع/حزم جاهزة | الأنسب لمن يعمل offline | لا يخدم الاستعلام اللحظي |
وسؤال مهم: هل تفضّلون نطاقاً من الآيات (2:255-260) أو سورة كاملة بكل بياناتها؟ في تجربتنا هذا أقرب للاستخدام الواقعي من طلب آية واحدة، لأن التطبيق غالباً يعرض صفحة أو سورة لا آية معزولة.
اقتراحات إضافية نطرحها للنقاش
هذه أفكار مرتبطة، نودّ معرفة أيّها يستحق الأولوية عندكم:
- المقارنة: نقطة تُرجع آية واحدة بعدة ترجمات/تفاسير جنباً إلى جنب، لتطبيقات المقارنة.
- الحقول المختارة (sparse fields): أن يطلب المطوّر حقولاً بعينها فقط لتقليل حجم الاستجابة.
- إصدارات المحتوى: التفاسير والترجمات تُصحَّح وتُحدَّث. هل تريدون تثبيت إصدار معيّن (version pinning) حتى لا يتغيّر النص تحت أقدامكم فجأة؟ أم تفضّلون الأحدث دائماً؟
- بيانات الصرف والنحو (morphology): مذكورة في خارطة الطريق. هل هي أولوية حقيقية لديكم أم متأخرة؟
- الربط مع التلاوة: توقيتات الآية/الكلمة ضمن الاستجابة نفسها، لتطبيقات المتابعة الصوتية.
- حدود الاستجابة: إن سمحنا بسورة كاملة + كل التفاسير، قد نتحدث عن استجابة بحجم عدة ميجابايت. هل نضع سقفاً واضحاً ونُلزم بالتقسيم (pagination)؟
ما الذي نحتاجه منكم تحديداً
لو تكرّمتم بالردّ، هذه أكثر الإجابات نفعاً لنا:
- ماذا تبني؟ (تطبيق مصحف، تطبيق تفسير، أداة بحث، مشروع بحثي…)
- كيف تحصل على البيانات اليوم؟ تنزيل مرة واحدة وتخزين محلي، أم طلبات لحظية؟
- هل ستستخدم هذه الواجهة فعلاً؟ ولو لا، فما الذي يمنعك؟
- ما الشكل الذي يناسبك أكثر من الخيارات أعلاه؟
- ما البيانات التي تحتاجها ولا تجدها اليوم في أي مصدر متاح؟
نقدّر أي رأي، حتى لو كان «لا نحتاج هذه الميزة» — بل هذا تحديداً من أنفع ما يمكن أن تقولوه لنا، لأنه يوفّر جهداً يمكن توجيهه لما ينفعكم أكثر. نحن نسأل قبل أن نبني، لا بعده.
جزاكم الله خيراً، ونفع بكم كتابه.
