تطبيقات ويب بـ Bubble وتطبيقات جوال بـ FlutterFlow، مبنية لتدوم بعد النسخة الأولى

أي أداة تناسب أي منتج

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

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

كيف نبدأ بنمذجة البيانات

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

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

في Bubble تصبح هذه أنواع بيانات وحقولًا. وفي FlutterFlow تصبح مجموعات أو جداول في خلفيتك. وفي الحالتين ينبغي أن يكون النموذج مفهومًا لمن يقرؤه دون فتح الأداة.

التكاملات: Airtable وZapier والواجهات البرمجية

تتصل معظم منتجات بدون كود بشيء آخر. والسؤال هو: من يصون كل اتصال حين ينكسر؟

Airtable

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

Zapier

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

الواجهات البرمجية وwebhooks

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

مزالق الأمان في بدون كود

تسهّل المنشئات المرئية الإطلاق، وتسهّل بالقدر نفسه إطلاق شيء مفتوح. هذه الإخفاقات التي نبحث عنها أولًا. وكسر التحكم في الوصول هو البند الأول في إصدار 2021 من OWASP Top 10، وتصادفه تطبيقات بدون كود كثيرًا.

بيانات مفتوحة افتراضيًا

في Bubble افحص قواعد الخصوصية (Privacy rules) على كل نوع بيانات. فإخفاء زر في صفحة ليس تحكمًا في الوصول: إن كان نوع البيانات مقروءًا لأي مستخدم مسجل فمن يعرف كيف يطلبه يقرؤه. اختبر بتسجيل الدخول بمستخدم ثانٍ ومحاولة الوصول إلى سجلات الأول، وباستدعاء واجهة البيانات دون بيانات اعتماد. وفي FlutterFlow يتحدث الهاتف مع الخلفية مباشرة، فتكون القواعد في الخلفية: قواعد أمان Firebase أو أمان مستوى الصف في Postgres.

مفاتيح API مكشوفة

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

قواعد أدوار ضعيفة

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

الإضافات والملفات المرفوعة

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

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

الاعتماد على المنصة وخطة خروج مكتوبة

الاعتماد على المنصة ثمن السرعة، وهو مقبول حين تراه بوضوح. في Bubble لا تملك أن تشغّل شيفرة التطبيق المصدرية في مكان آخر، فالانتقال يعني إعادة البناء انطلاقًا من البيانات والمنطق المكتوب. ويستطيع FlutterFlow تصدير شيفرة Flutter، لكن عامل التصدير كباب باتجاه واحد: فبعد أن يعدّل المطورون المشروع المصدَّر يدويًا لا تستطيع عادة إعادته إلى المنشئ المرئي.

لذلك نكتب خطة الخروج في اليوم الأول ونحدّثها كلما تغير المنتج. وهي تغطي ستة أمور.

1. البيانات. كيف تُصدَّر كل أنواع البيانات أو المجموعات، وكم مرة، وأين تُحفظ النسخة. اختبر الاستعادة لا التصدير فقط.
2. المنطق. كل سير عمل موصوف بلغة واضحة: المشغّل والشروط والأثر.
3. التصميم. تبقى الواجهة في Figma ليمكن إعادة بنائها على أي تقنية. انظر تصميم تجربة وواجهة المستخدم.
4. الحسابات والمفاتيح. من يملك كل حساب ومفتاح وwebhook ونطاق.
5. المحفزات. الإشارات التي تبدأ الانتقال، كالتكلفة أو السرعة أو ميزة لا تستطيع الأداة بناءها.
6. الوجهة. البديل المرجح، مثل تطبيق Next.js مع PostgreSQL أو قاعدة شيفرة Flutter، وترتيب نقل الأجزاء.

حدود الأداء التي يجب التخطيط لها

تؤدي صفحات Bubble عملًا حقيقيًا في المتصفح، فتبطؤ الصفحات التي تبحث وتصفّي قوائم كبيرة عند العميل، أو تضع عمليات بحث داخل عمليات بحث، أو تحمّل قائمة كاملة لتعرض عشرة صفوف. قيّد عمليات البحث في قاعدة البيانات، وقسّم النتائج على صفحات، وأبقِ الصفحات خفيفة. وتطبيقات FlutterFlow هي تطبيقات Flutter، مما يبقي الواجهة سريعة الاستجابة، لكن الاستعلامات الثقيلة والصور الكبيرة وكثرة المستمعين الحيّين تضر أيضًا. اختبر على هواتف أندرويد متوسطة المواصفات وعلى اتصالات بطيئة.

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

متى تنتقل إلى الشيفرة المخصصة

انتقل حين تصبح الأداة هي العنق لا حين تبدو غير عصرية. هذه إشارات شائعة.

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

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