أستخدم Xano وReact والكود الكامل. ولا أظن أنك مضطر لاختيار طرف

Xano أداة من أدواتي، وليس كل أدواتي

أنا أحب Xano بصدق.

ليس لأنني أحاول تجنّب كود الـ backend. إنه ببساطة أداة منتجة.

استخدمته لمخططات قواعد البيانات والعلاقات وREST APIs والصلاحيات والمصادقة والـ triggers والمهام في الخلفية والمهام المجدولة والتكاملات والكثير من منطق العمل. (المزيد في صفحة عملي على Xano بالإنجليزية.)

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

في مرحلة ما، كانت بعض واجهات API في نظام إنتاجي عملت عليه تصل إلى 5–40+ ثانية تحت الضغط.

لم يكن هناك زر سحري. كان علينا أن ننظر في الـ backend الحقيقي.

بعض الاستعلامات كانت مكلفة. بعض المسارات كانت تستدعي قاعدة البيانات مرات كثيرة. بعض الـ joins كانت أثقل من اللازم. وبعض الـ triggers كانت تقوم بعمل لا مكان له داخل الطلب.

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

وحلّها تطلّب دائماً فهم قاعدة البيانات وطريقة تصرّف التطبيق.

لم تكن في الحقيقة مشكلة low-code. كانت مشكلة backend.

ويمكنه أن يذهب أبعد مما يظن الناس

المنتج الرئيسي الذي عملت عليه لم يكن MVP صغيراً.

كان نظام ATS وCRM للتوظيف يضم نحو 150K سجل أشخاص، وقرابة 35K مرشح، وآلاف الوظائف والمشاريع، وعشرات المستخدمين الداخليين.

كانت فيه طلبات توظيف وأنشطة وشركات وفرص وصلاحيات وتقارير وعمليات ترحيل بيانات ومسارات ذكاء اصطناعي ومطابقة للمرشحين ومعالجة في الخلفية. كان يحدث الكثير داخل هذا النظام. (القصة الكاملة في دراسة حالة Talent Match.)

وبقي Xano مفيداً.

هذا لا يعني أنني سأستخدمه لكل شيء حرفياً. لن أفعل.

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

على الواجهة الأمامية اتخذنا قراراً مختلفاً

المنتج نفسه كانت واجهته الأمامية في الأصل على WeWeb. وWeWeb أيضاً ساعدنا على التحرك بسرعة.

لكن مع الوقت أصبح التطبيق أكثر تعقيداً بكثير: الكثير من النماذج والفلاتر ولوحات التحكم ولوحات Kanban والصلاحيات ومسارات العمل المترابطة والحالة التي يجب إدارتها.

في النهاية أعدنا بناء الواجهة الأمامية الإنتاجية كاملة بـ React 19 + TypeScript. تدريجياً، لا دفعة واحدة:

في تلك المرحلة من المنتج، أظن أنه كان القرار الصحيح.

حصلنا على تحكم أكثر مباشرة في الكود. واستطعنا توحيد الأمور بشكل سليم حول TanStack Query وReact Hook Form وZod وReact Router والمكوّنات القابلة لإعادة الاستخدام وTypeScript. أصبحت الواجهة قاعدة كود يستطيع المطورون فهمها مباشرة. (المزيد عن عملي على React.)

شخصياً، لواجهة أمامية كبيرة أتوقع أن تستمر في النمو، هذا هو الاتجاه الذي أميل إليه الآن.

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

وهذا طبيعي.

الذكاء الاصطناعي يجعل التحوّل أسهل بكثير الآن

هذا هو الجزء الذي أجده الأكثر إثارة.

الانتقال من الـ low-code إلى الـ full-code أسهل اليوم بكثير مما كان عليه قبل بضع سنوات.

أثناء الانتقال إلى React استخدمت Claude Code كثيراً. ساعد في التنفيذ المتكرر وإعادة الهيكلة واكتشاف الأنماط في الكود وتحويل السلوك الموجود إلى مكوّنات React بشكل أسرع. وقد قلّل فعلاً الكثير من العمل الآلي.

وأظن أن الأمر نفسه ينطبق على الـ backend الآن. إذا احتجت يوماً إلى نقل جزء من نظام إلى Node.js، يمكن للذكاء الاصطناعي المساعدة في الهياكل الأولية والأنواع والـ endpoints المتكررة والاختبارات وإعادة الهيكلة والكثير من الأجزاء المملة.

لكن هناك فرقاً كبيراً بين كتابة الكود بسرعة وفهم النظام.

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

هذا يأتي دائماً من فهم المنتج. (أكتب عن جانب الذكاء الاصطناعي من عملي في صفحة تكامل الذكاء الاصطناعي.)

الذكاء الاصطناعي يجعل الانتقال أرخص. لكنه لا يجعل القرار تلقائياً.

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

ربما هذا أكبر درس تعلّمته من العمل بالاثنين.

من السهل جداً اليوم أن تنظر إلى نظام قائم وتقول: «يمكننا إعادة بناء هذا.»

ونعم، ربما تستطيع. لكن هل يجب أن تفعل؟

$ ./should-we-rewrite
  users happy?          yes
  performance fine?     yes
  team can maintain it? yes
  real reason?          "feels cleaner"
→ verdict: don’t rewrite (yet)

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

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

أفضّل أن أنتقل لسبب حقيقي. لا لأنني أريد أن تبدو الأدوات أروع.

وسأستخدم Node.js أكثر على الأرجح

لا أرى مستقبلي على أنه «Xano إلى الأبد».

هناك بالتأكيد مشاريع أفضّل فيها امتلاك الـ backend مباشرة: خدمات مخصصة، مكتبات محددة، اختبارات أعمق، تحكم أكبر في النشر أو في سلوك التشغيل، أو بنية تناسب الـ backend التقليدي ببساطة. حينها يكون شيء مثل Node.js منطقياً.

وأريد أن أعمل أكثر بهذا النوع من الأدوات. React + Node.js + PostgreSQL مجموعة أرى نفسي أبني بها بكل تأكيد.

لكن هذا لا يعني أن عليّ التوقف عن استخدام Xano. إذا استطعت تسليم backend أسرع بـ Xano وكان المشروع يناسبه، سأفكر فيه بجدية.

يمكن أن يكون الأمران صحيحين معاً.

Xano أداة من أدواتي، وليس كل أدواتي.

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

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

يبدو لي هذا طبيعياً تماماً.

استخدم الأداة الأعلى مستوى حيث توفّر وقتك. واستخدم الكود الكامل حيث تحتاج التحكم. ولا تُعِد كتابة أجزاء تعمل أصلاً لمجرد أنك تستطيع. (على مستوى قاعدة البيانات، هذا هو العمل الذي أصفه في صفحة أداء PostgreSQL.)

إذن، متى سأترك الـ low-code فعلاً؟

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

حينها نعم، سأنتقل. لكنني أريد أن يأتي القرار من المنتج، لا من الأنا.

أين أقف الآن

أنا مطور Full-Stack. أحب React وTypeScript. أحب العمل مباشرة مع PostgreSQL وواجهات API. وسأستخدم على الأرجح Node.js وتقنيات backend أخرى بالكود الكامل أكثر.

وما زلت أحب Xano. ولا أظن أن أياً من هذا متعارض.

Xano أداة من أدواتي. والكود الكامل يعطيني مستوى آخر من التحكم عندما أحتاجه. والذكاء الاصطناعي يجعل التنقل بين المستويين أسهل من أي وقت مضى.

لذلك لا أسأل حقاً: «هل الـ low-code أفضل من الـ full-code؟» بل أفضّل أن أسأل: «ما الذي يجب أن أستخدمه فعلاً لهذا الجزء من المنتج؟»

أحياناً سيكون الجواب Xano. أحياناً Node.js. أحياناً React. أحياناً WeWeb. وأحياناً مزيجاً منها كلها.

ما دمت أفهم ما أبنيه ولماذا أختار الأداة، فهذا أهم عندي بكثير من اختيار طرف.