بناء تطبيقات الجوال باستخدام دروبال: نهج الأولوية للواجهة البرمجية

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

يشرح هذا المقال كيفية بناء تطبيق جوال فوق دروبال باستخدام معمارية API-first. سنوضح الفرق بين "API-first" و"headless"، ونستعرض سبب ملاءمة هذا النموذج للجوال بشكل كبير، ونمر عبر طبقتي واجهة البرمجة والمصادقة، ونتناول الاعتبارات الخاصة بالجوال التي تتجاهلها معظم الأدلة، ونضع إطارًا واضحًا لتحديد إلى أي مدى ينبغي الفصل (decoupling).

API-First مقابل Headless: توضيح الالتباس

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

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

أما API-first فيصف فلسفة تصميم: يتم تصميم المحتوى وعرضه كواجهات برمجية منذ البداية، بحيث يكون جاهزًا لتغذية أي عدد من القنوات في آن واحد — موقع إلكتروني، تطبيق iOS، تطبيق أندرويد، ساعة ذكية، كشك تفاعلي، مساعد صوتي. الـ headless يتعلق بفصل واجهة أمامية واحدة؛ أما API-first فيتعلق بالاستعداد لها جميعًا. غالبًا ما يكون تطبيق الجوال هو الدافع للتحول إلى API-first، لكن الفائدة الحقيقية هي أن نفس الخلفية يمكنها خدمة كل قناة تضيفها المؤسسة لاحقًا، دون إعادة بناء طبقة المحتوى في كل مرة.

دروبال مناسب جيدًا لكلا النهجين لأن قدراته في مجال واجهات البرمجة جزء من النواة الأساسية وليست إضافة خارجية. منذ دروبال 8، وتطورت عبر دروبال 9 و10 و11، تأتي المنصة مزودة بطبقة خدمات ويب تحوّل المحتوى المنظّم إلى استجابات واجهة برمجية دون الحاجة إلى كتابة كود مخصص. هذا هو الأساس الذي يُبنى عليه كل ما تبقى في هذا المقال.

لماذا يُعد API-First الأساس الصحيح لتطبيق الجوال

اختيار خلفية دروبال قائمة على API-first لتطبيق جوال يجلب مزايا تظهر طوال دورة حياة المشروع، وليس فقط عند الإطلاق.

• مصدر محتوى واحد، قنوات متعددة: يُدخل نفس الإعلان أو المقرر أو الملف الشخصي مرة واحدة في دروبال، ثم يُسلَّم إلى الموقع الإلكتروني وتطبيق الجوال وأي قناة أخرى في الوقت نفسه. لا يضطر المحررون لصيانة المحتوى مرتين، ولا يفقد التطبيق أبدًا التزامن مع الموقع.
• محتوى منظّم، جاهز لأي واجهة: لأن دروبال يخزّن المحتوى كبيانات منظّمة بدلاً من صفحات معروضة، فإن هذا المحتوى يتوافق بسلاسة مع واجهة الجوال. المقرر ليس كتلة من HTML — بل مجموعة من الحقول (العنوان، الساعات المعتمدة، المُحاضر، الجدول الزمني) يمكن للتطبيق ترتيبها كما يحتاج.
• تطور مستقل للواجهة الأمامية والخلفية: يمكن لفريق التطبيق إصدار نسخة جديدة دون المساس بالخلفية، ويمكن لفريق المحتوى إعادة هيكلة الخلفية دون كسر التطبيق، طالما بقي عقد واجهة البرمجة قائمًا. الترقيات في جانب لا تفرض إعادة بناء في الجانب الآخر.
• استثمار مستقبلي: عندما تظهر القناة التالية — تطبيق جديد، نظام عرض في الحرم الجامعي، تكامل مع منصة أخرى — يكون المحتوى مكشوفًا بالفعل وجاهزًا. تبني المؤسسة واجهة أمامية جديدة، لا خلفية جديدة.
• إدارة محتوى بمستوى المؤسسات وراء التطبيق: يرث التطبيق سير العمل التحريري في دروبال، والصلاحيات الدقيقة، ودعم تعدد اللغات، ومعالجة الوسائط — قدرات كان على خلفية جوال مصممة خصيصًا أن تعيد اختراعها من الصفر.

طبقة واجهة البرمجة: JSON:API وREST وGraphQL

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

بالنسبة لمعظم مشاريع الجوال، يُعد JSON:API نقطة الانطلاق الطبيعية. فهو جزء من النواة، ولا يتطلب أي إعداد لتفعيله، ويتبع مواصفة صارمة، مما يعني أن مطور الجوال يعرف بالضبط كيف ستبدو الاستجابات. كما تتعامل بنيته مع العلاقات بين المحتويات — مقرر ومُحاضره، فعالية ومكانها — بطريقة يمكن التنبؤ بها، وهي حاجة متكررة في تطبيقات المؤسسات. يصبح GraphQL جذابًا عندما تحتاج شاشة تطبيق إلى سحب أجزاء بيانات متعددة مختلفة دفعة واحدة وتريد تجنب الرحلات المتعددة ذهابًا وإيابًا؛ والمقابل هو إعداد وتعقيد إضافيان. كقاعدة عامة، ابدأ بـ JSON:API وانتقل إلى GraphQL فقط عندما تبرر حاجة أداء ملموسة ذلك.

المصادقة: لماذا لا يمكن لتطبيقات الجوال الاعتماد على ملفات تعريف الارتباط

المصادقة هي أول عقبة تقنية حقيقية في بناء جوال منفصل (decoupled)، وهي تفاجئ العديد من الفرق. يقوم موقع دروبال التقليدي بمصادقة المستخدمين باستخدام ملفات تعريف ارتباط الجلسة (session cookies) التي يديرها المتصفح. لا يملك تطبيق الجوال الأصلي (native) متصفحًا ولا مخزن ملفات تعريف ارتباط، لذا لا تنطبق هذه الآلية ببساطة. يجب على التطبيق أن يصادق بطريقة مختلفة.

الحل القياسي هو المصادقة القائمة على الرموز (tokens). يُدخل المستخدم بيانات اعتماده مرة واحدة؛ يرسلها التطبيق إلى دروبال؛ يتحقق منها دروبال ويعيد رمزًا؛ ويخزّن التطبيق هذا الرمز ويرفقه بكل طلب لاحق. يهيمن نهجان:

• OAuth 2.0 (وحدة Simple OAuth): النهج الموصى به لمعظم التطبيقات المنفصلة. يصدر رموز وصول وتحديث، ويدعم التدفقات الحديثة بما في ذلك PKCE للعملاء العامّين مثل تطبيقات الجوال، ويتكامل بسلاسة مع أنظمة الهوية المركزية. هذا هو المسار الذي تسلكه معظم مشاريع المؤسسات.
• JWT (رمز ويب JSON): بديل خفيف حيث يحمل الرمز نفسه هوية المستخدم. بسيط وعديم الحالة (stateless)، ومناسب للتطبيقات المباشرة التي لا تحتاج إلى احتياجات تفويض معقدة.

بالنسبة للمؤسسات التي تدير بالفعل تسجيل دخول موحد (SSO)، يمكن لطبقة OAuth ربط التطبيق بنفس مزوّد الهوية المركزي المستخدم في كل مكان آخر، بحيث يسجّل الطلاب والموظفون الدخول إلى التطبيق ببيانات الاعتماد التي يملكونها بالفعل. من المهم إعداد المصادقة بشكل صحيح مبكرًا — فمن الأصعب بكثير تعديل تدفق رموز آمن لاحقًا على تطبيق مبني حول افتراض أبسط، مقارنة بتصميمه لذلك منذ البداية.

الطبقة الخاصة بالجوال: العمل دون اتصال، الإشعارات الفورية، والوسائط

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

• الوصول دون اتصال والتخزين المؤقت: يتوقع مستخدم الجوال أن يعمل التطبيق في قطار أو قاعة محاضرات ذات إشارة ضعيفة. ينبغي للتطبيق تخزين المحتوى محليًا والمزامنة مع دروبال عند عودة الاتصال. تدعم طبقة واجهة البرمجة ذلك من خلال تقديم استجابات منظّمة قابلة للتخزين المؤقت يمكن للتطبيق حفظها وتحديثها — لكن منطق التخزين المؤقت والمزامنة يعيش في جانب التطبيق ويجب تصميمه بعناية.
• الإشعارات الفورية (Push): تُعد الإشعارات أحد الأسباب الرئيسية التي تجعل المؤسسات ترغب في تطبيق أصلي في المقام الأول — درجة جديدة، تغيير في الجدول، تنبيه طارئ. يعمل دروبال كمصدر للمُحفّز: عندما يُنشر محتوى أو يقع حدث، يستدعي دروبال خدمة دفع (مثل Firebase Cloud Messaging) تُسلّم الإشعار إلى الأجهزة. يعيش المحتوى والمُحفّز في دروبال؛ ويتم التسليم عبر بنية الإشعارات التحتية للمنصة.
• الوسائط وتحسين الصور: تجعل شاشات الجوال وباقات بيانات الجوال معالجة الصور أمرًا بالغ الأهمية. يمكن لنظام الوسائط وأنماط الصور في دروبال توليد نسخ من كل صورة بأحجام مناسبة، بحيث يطلب التطبيق نسخة مُحسّنة للجوال بدلاً من تنزيل ملف بدقة كاملة مخصص لسطح المكتب. يؤثر هذا مباشرة على أوقات التحميل واستهلاك البيانات.
• تطبيقات الويب التقدمية كحل وسط: ليست كل مؤسسة بحاجة إلى تطبيق أصلي كامل. يوفّر تطبيق الويب التقدمي (PWA) الكثير من التجربة الأصلية — التثبيت على الشاشة الرئيسية، الدعم دون اتصال، الإشعارات الفورية — من قاعدة كود ويب واحدة، ويدعم دروبال ذلك عبر وحدة PWA مخصصة. بالنسبة للعديد من الحرم الجامعية، يُعد PWA طريقًا أقل تكلفة نحو تجربة شبيهة بالتطبيق قبل الالتزام بالتطوير الأصلي.

منفصل، منفصل تدريجيًا، أم متصل؟

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

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

العامل الحاسم هو عدد الواجهات الأمامية التي يحتاج المحتوى إلى خدمتها. يُفضَّل إبقاء موقع إلكتروني واحد متصلاً. أما موقع إلكتروني إضافة إلى تطبيق جوال أصلي فيشير إلى معمارية منفصلة أو هجينة. الخطأ هو الفصل من أجل الفصل نفسه — فبناء منفصل بالكامل لمشروع لم يحتج يومًا سوى موقع إلكتروني واحد يضيف تعقيدًا وتكلفة ستضطر المؤسسة إلى صيانتهما لسنوات. لقد استعرضنا المفاضلات الأوسع بين المنصات في مقارنتنا بين دروبال، ووردبريس، وجوملا.

خيارات الواجهة الأمامية: React Native وFlutter والتطوير الأصلي

نظرًا لأن خلفية دروبال القائمة على API-first محايدة تجاه الواجهة الأمامية، فهي تعمل مع أي تقنية جوال يفضّلها الفريق. لا تهتم واجهة البرمجة بمن يستهلكها، مما يحرر القرار ليعتمد على متطلبات التطبيق ومهارات الفريق.

• React Native: خيار شائع عابر للمنصات يبني تطبيقات iOS وأندرويد من قاعدة كود جافاسكريبت واحدة. يتناسب بشكل طبيعي مع JSON:API الخاص بدروبال، وله نظام بيئي كبير ومجموعة واسعة من المواهب.
• Flutter: إطار عمل جوجل العابر للمنصات، الذي يستخدم لغة Dart، ومعروف بأدائه السلس ومظهره المتسق عبر المنصات. يستهلك واجهات برمجة دروبال بسهولة مثل أي عميل آخر.
• التطوير الأصلي (Swift / Kotlin): بناء تطبيقين منفصلين لنظام iOS (بلغة Swift) ولأندرويد (بلغة Kotlin) يمنح أعمق تكامل مع المنصة وأفضل أداء، بتكلفة تطوير أعلى. تخدم خلفية دروبال كلا التطبيقين بنفس الطريقة.

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

الأخطاء الشائعة في بناء جوال قائم على API-First

• الفصل دون الحاجة إليه: الخطأ الأكثر شيوعًا. إذا لم توجد قناة ثانية، فإن موقع دروبال المتصل أبسط وأرخص وأسهل في الصيانة. افصل لأن لديك تطبيق جوال، لا لأن ذلك يبدو حديثًا.
• تأجيل المصادقة إلى وقت متأخر: تشكّل المصادقة القائمة على الرموز معمارية التطبيق بأكملها. صمّم تدفق OAuth أو JWT في البداية، وليس بعد أن يكون التطبيق قد بُني بالفعل حول افتراضات الجلسة.
• نسيان ما تملكه الواجهة الأمامية الآن: في بناء منفصل، يرث فريق الواجهة الأمامية التوجيه (routing)، وتحسين محركات البحث، وإمكانية الوصول، والبيانات الوصفية — أمور كان دروبال يتعامل معها تلقائيًا من قبل. يجب التخطيط لهذه الأمور صراحة، وإلا فلن تحدث ببساطة.
• تجاهل الطبقة الخاصة بالجوال: السلوك دون اتصال، والإشعارات الفورية، وتحسين الصور ليست أمورًا ثانوية. سيبدو التطبيق الذي لا يتعامل مع الاتصال الضعيف أو يقدّم صورًا بحجم سطح المكتب معطلاً بغض النظر عن مدى نظافة واجهة البرمجة.
• جلب بيانات زائدة عن الحاجة: طلب أكثر مما تحتاجه الشاشة يهدر عرض النطاق الترددي وعمر البطارية. استخدم تصفية الحقول في JSON:API، أو GraphQL عندما يناسب ذلك، لجلب ما هو مطلوب فقط.
• التعامل مع واجهة البرمجة كفكرة لاحقة: جوهر API-first هو تصميم نموذج المحتوى وواجهة برمجته عمدًا ومسبقًا. إن إلحاق واجهة برمجية ببنية محتوى لم تكن مصممة أصلاً للاستهلاك الخارجي يؤدي إلى نقاط نهاية غير عملية وغير فعالة.

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

أسئلة شائعة حول دروبال وتطبيقات الجوال

آخر تحديث: 17.08.2026 15:06