بمناسبة اليوم الوطني راح أهديكم سلسلة تغريدات ألخص فيها تجربتي مع منصة #فايربيس @Firebase
فايربيس هي منصة للمبرمجين وخصوصا مطوري التطبيقات تملكها قوقل @Google وهذا رابط المنصة firebase.google.com
فايربيس هي منصة للمبرمجين وخصوصا مطوري التطبيقات تملكها قوقل @Google وهذا رابط المنصة firebase.google.com
لماذا فايربيس؟ فايربيس عبارة عن منصة باكاند backend متكاملة توفر لمطوري التطبيقات عدة خدمات على رأسها ١) ادارة المستخدمين firebase authentication و ٢) قاعدة بيانات #فايرستور #Firestore و ٣) تحليلات فايربيس اناليتكس firebase analytics لتحليل سلوك مستخدمي التطبيق
ايش يفرق فايربيس عن خدمات أخرى مثل قوقل كلاود او أمازون كلاود او غيرها؟
الفرق الرئيسي والأساسي هو انك تحصل على الباكاند من فايربيس كخدمة backend as a service او #BaaS بدون ما تكتب ولا سطر كود خارج تطبيقك. هذا لا يعني انك راح تستغني بشكل كامل عن كتابة كود باكاند زي ما راح نشوف
الفرق الرئيسي والأساسي هو انك تحصل على الباكاند من فايربيس كخدمة backend as a service او #BaaS بدون ما تكتب ولا سطر كود خارج تطبيقك. هذا لا يعني انك راح تستغني بشكل كامل عن كتابة كود باكاند زي ما راح نشوف
بعبارة أخرى: بالطريقة التقليدية وبدون استخدام فايربيس، راح تحتاج تستأجر سيرفر أو أكثر في الكلاود عشان تركب فيه الداتابيز وكذلك الباكاند سيرفس اللي تحتاجها وراح تكتب كود باكاند سواء باستخدام Java او PHP او Python او NodeJS او .NET او غيرها
طبعا كمطور تطبيق وكون معظم خبرتك هي في تطوير التطبيقات سواء باستخدام Swift للايفون او Java للاندرويد، الطريقة التقليدية راح تكون متعبة لك لانك ستضطر اما لتعلم كيفية برمجة سيرفس في الباكاند او تطلب من غيرك يساعدك في هالشي.
بالمقابل في فايربيس النموذج فريد من نوعه ومختلف حيث توفر لك خدمات الباكاند الرئيسية بشكل جاهز وتوفر لك مكتبة جاهزة client SDK (للاندرويد والايفون) تمكنك من الاستفادة من هذه الخدمات مباشرة. ليس فقط هذا ولكن توفر لك ميزات عديدة في هذه الخدمات والتي سأتحدث عنها في بقية التغريدات
في الصور المرفقة مقارنة تقريبية بين خدمات فايربيس وبين الطريقة التقليدية. هذه المقارنة لا تعني ان كل خدمة وضعتها في الطريقة التقليدية مطابقة لما هو موجود في الفايربيس ولكن المقصود انها تؤدي غرض مشابه إلى حد كبير مع ملاحظة انه في الطريقة التقليدية يجب عليك ادارة السيرفرات بنفسك
زي ما تلاحظون فايربيس مليئة بمكونات عديدة تتكامل مع بعضها البعض و تغطيتها في يوم واحد راح يكون صعب جدا 😅 فاستأذنكم في اكمال السلسلة في الأيام القادمة. بعيدا عن الطرح السطحي، راح استعرض عدة مفاهيم في هندسة البرمجيات وقواعد البيانات والأمن السيبراني وغيرها عمليا عبر هذه التغريدات
خلونا نبدأ ب firebase authentication firebase.google.com أو خدمة توثيق المستخدمين. تساعدك هذه الخدمة على بناء جزئية ادارة المستخدمين في موقعك أو تطبيقك وتختصر عليك الكثير في هذا الجانب حيث يمكنك أن توفر لمستخدمي التطبيق امكانية التسجيل و تسجيل الدخول بعدة طرق.
من هذه الطرق ١) تسجيل الدخول بالإيميل والباسوورد ٢) تسجيل الدخول الموحد single sign on باستخدام ما يسمى بالهوية الفيدرالية federated identity من قوقل أو فيسبوك أو تويتر بحيث يسجل المستخدم في تطبيقك باستخدام حسابه في قوقل مثلا
٣) باستخدام رقم التلفون مع pin code في رسالة نصية حيث توفر لك فايربيس ١٠ آلاف رسالة SMS شهريا مجانا.
طريقة البرمجة: تقوم بكتابة الكود الخاص فيك في التطبيق باستخدام ال client SDK من فايربيس والتي بدورها تتواصل اوتوماتيكيا مع فايربيس لعمل ال authentication.
طريقة البرمجة: تقوم بكتابة الكود الخاص فيك في التطبيق باستخدام ال client SDK من فايربيس والتي بدورها تتواصل اوتوماتيكيا مع فايربيس لعمل ال authentication.
يمكنك اختصار الموضوع أكثر باستخدام ال client UI الجاهزة من فايربيس والتي توفر لك كود جاهز لواجهات تسجيل المستخدم الجديد وتسجيل الدخول في تطبيقك أو موقعك.
عند تسجيل الدخول توفر لك فايربيس اوتوماتيكيا من خلال ال SDK اوبجيكت يمثل المستخدم بكل خصائصه.
عند تسجيل الدخول توفر لك فايربيس اوتوماتيكيا من خلال ال SDK اوبجيكت يمثل المستخدم بكل خصائصه.
يمكنك اضافة خصائص جديدة للأوبجيكت تخص المستخدم مثل رابط لصورة البروفايل.
لتسهيل ادارة صلاحيات المستخدمين access control يمكنك استخدام ما يسمى بال claims. مثلا يمكن اضافة خاصية admin يحث اذا كان المستخدم أدمن تكون هذه الخاصية true ويمكنك وضع levels of access لصلاحيات الأدمن.
لتسهيل ادارة صلاحيات المستخدمين access control يمكنك استخدام ما يسمى بال claims. مثلا يمكن اضافة خاصية admin يحث اذا كان المستخدم أدمن تكون هذه الخاصية true ويمكنك وضع levels of access لصلاحيات الأدمن.
ماذا يميز فايربيس عن الطريقة التقليدية في هذه الناحية؟
١) جزئية الباكند مبرمجة لك بالكامل بحيث لا تقلق في قضية ادارة ال session وال tokens أو التواصل باستخدام بروتوكول OAuth.
١) جزئية الباكند مبرمجة لك بالكامل بحيث لا تقلق في قضية ادارة ال session وال tokens أو التواصل باستخدام بروتوكول OAuth.
٢) الباكند مبرمجة لك بمعايير أمن سيبراني عالية جدا دون التأثير على سهولة التكامل معها. فمثلا يتم آليا عمل hash لكلمات السر كما يتم استخدام معايير عالية في ادارة ال tokens باستخدام JWT. هذا يتم بدون تدخلك وذلك من خلال التواصل بين ال Client SDK وبين الباكند في فايربيس اوتوماتيكيا.
صدقوني، الكثير في الطريقة التقليدية يخفق في برمجة هذه الجزئيات في الباكند بطريقة آمنة علاوة على صعوبة متابعة التحديثات وصعوبة التشغيل.
٣) إضافة إلى كود الباكاند يوجد أيضا كود متكامل لواجهات تسجيل الدخول UI بإمكانك استخدامه في البداية على الأقل لتسريع عملية التطوير لديك.
٣) إضافة إلى كود الباكاند يوجد أيضا كود متكامل لواجهات تسجيل الدخول UI بإمكانك استخدامه في البداية على الأقل لتسريع عملية التطوير لديك.
٤) توفر لك فايربيس خدمة التأكد من إمتلاك المستخدم للإيميل الذي سجل باستخدامه من خلال ارسال ايميل تحقق كما توفر لك امكانية ارسال إيميل لعمل reset للحساب عند نسيان المستخدم الباسوورد.
٥) يمكنك عمل تسجيل مؤقت للمستخدم anonymous login بحيث لا تفقد بيانات المستخدم بين زيارة وأخرى
٥) يمكنك عمل تسجيل مؤقت للمستخدم anonymous login بحيث لا تفقد بيانات المستخدم بين زيارة وأخرى
الآن نأتي للجزء الأهم والأكثر متعة وإبداعا وإبهارا بالنسبة لي في فايربيس ولا أعلم إذا كان هناك من سبقهم إلى هذه الفكرة.
أي شخص برمج تطبيقات أو مواقع سابقا سيسأل السؤال التالي: كيف يمكن تأمين الوصول للموارد في الباكاند وخصوصا تأمين الوصول لقاعدة البيانات من الكلاينت مباشرة؟
أي شخص برمج تطبيقات أو مواقع سابقا سيسأل السؤال التالي: كيف يمكن تأمين الوصول للموارد في الباكاند وخصوصا تأمين الوصول لقاعدة البيانات من الكلاينت مباشرة؟
دعوني أولا أشرح كيف يتم ذلك في الطريقة التقليدية كالتالي: عادة يكون هناك اتصال بين كود الباكاند، ولنفرض ان الكود مكتوب باستخدام PHP، وبين قاعدة البيانات ويكون الاتصال مؤمن باستخدام كلمة سر. مثلا عند اتصال كود PHP بقاعدة بيانات MySQL فإن ذلك يتم باستخدام كلمة سر مخزنة في مكان ما.
يقوم كود التطبيق أو الموقع بالتواصل مع خدمات الباكند والتي بدورها تقوم بتأمين عملية الوصول لقاعدة البيانات بحيث تتأكد من هوية المستخدم أولا ومن ثم تقرر السماح له من عدمه بالقيام بعملية القراءة من أو الكتابة في قاعدة البيانات. قس على هذا بقية الموارد مثل الملفات وغيرها.
في فايربيس لا يوجد كود باكاند (في الحقيقة توجد تقنية الكلاود فنكشن والتي سنستعرضها لاحقا ولكن لن نتطرق لها الآن) فكيف يمكن حماية الوصول لقاعدتي البيانات في منصة فايربيس وهما Firestore و/أو Realtime Database أو الملفات والصور في Cloud storage. هذا يتم من خلال ال security rules.
قامت قوقل بعمل لغة متكاملة بسيطة لكتابة قواعد أمنية security rules firebase.google.com لحماية قاعدة البيانات وهذه القواعد يقوم المبرمج بكتابتها. أكبر خطر أمني أحذر منه وأعتقد بانتشاره، خصوصا أني قرأت بحث مؤخرا بهذا الصدد، هو إهمالك وعدم فهمك وكتابتك لهذه القواعد الأمنية
من عبقرية وجمال تصميم فايربيس أن سمحت لكود التطبيق بعمل استعلام query مباشرة على الداتابيس. ولكن حتى تحمي الوصول الغير الآمن للبيانات طلبت من المبرمج كتابة قواعد أمنية تحدد متى يتم السماح بتنفيذ الاستعلام ومتى يتم الرفض.
على الرغم من أني لم أشرح حتى الآن طريقة عمل قاعدة بيانات فايرستور دعوني أشرح لكم باختصار كيف يمكن تأمين الاستعلام التالي: profile.userId.get(); هذا الاستعلام يقوم بقراءة بيانات بروفايل أحد المستخدمين. لنفترض أنه يسمح للمستخدم فقط بقراءة بيانات البروفايل الخاص به.
في هذه الحالية يجب عليك وضع قاعدة أمنية تمنع القراءة إلا في حالة واحدة فقط وهي مطابقة ال userId الموجود في ال firebase authentication token مع ال userId في قاعدة البيانات. هنا نلاحظ الرابط بين خدمة firebase authentication وبين تأمين القراءة المباشرة من التطبيق لقاعدة البيانات
الكثير على ما يبدو يقع في خطأ أمني خطير جدا 😣حيث يظن أن استخدام ال API key من فايربيس، الموجود في ملف ال google-config.plist في تطبيقات الايفون مثلا، كافي لتأمين الوصول لقاعدة البيانات ولكن في الحقيقة هذا المفتاح هو مفتاح للتعريف فقط وليس للتأمين.
يمكن الحصول على هذا المفتاح بسهولة عبر عمل هندسة عكسية للتطبيق. الحل الصحيح والوحيد الآمن هو بكتابة القواعد الأمنية كما ذكرت. كما أود التنبيه إلى أن القواعد الأمنية تقوم بتأمين الوصول حتى مستوى معين في قاعدة البيانات وهو ال document حيث أنها أصغر وحدة يمكن التحكم بالوصول لها
هذه الجزئية أقل حدوثا من سابقتها ولكنها أكثر صعوبة في الفهم والانتباه لها. مثلا: لو كنت تبرمج شبكة اجتماعية وأعطيت أي مستخدم امكانية قراءة البروفايل لأي مستخدم آخر وفي نفس الوقت قمت بتخزين معلومة سرية مثل رقم الهاتف في هذا البروفايل فيجب عليك فصل معلومات البروفايل عند التخزين.
يتم الفصل بحيث تكون المعلومات العامة في document والمعلومات الخاصة في document أخرى مرتبطة بالأولى بطريقة ما حسب تصميم السكيما الذي يختاره المبرمج لقاعدة البيانات. هنا نجد تأثير الجانب الأمني في كيفية تصميم قاعدة البيانات وهو موضوع قد يصعب فهمه لمن اعتاد على الطريقة التقليدية.
أخيرا، كيف تعمل القواعد الأمنية security rules 🧐؟ خلف الكواليس تقوم فايربيس في جزئية الباكاند أوتوماتيكيا بمراجعة كل عملية استعلام تتم من قبل التطبيق ومقارنتها بكافة القواعد الأمنية المكتوبة وفي حال نجحت المطابقة ترد فايربيس بنتيجة الاستعلام أما في حال الفشل فترد برسالة خطأ أمني
هذا لا يعني أنه لا يمكن استخدام firebase authentication مع خدمات أخرى خارج منصة فايربيس ولكن قد تكون أصعب. بالمقابل فهناك عيوب ل auth0 أهمها ١- غلاء السعر مقارنة بفايربيس ٢- كونه خدمة تغطي جانب معين فقط مقابل منصة فايربيس المتكاملة. نكتفي بهذا القدر اليوم ونكمل لاحقا بمشيئة الله
اليوم نستكمل حديثنا عن فايربيس حيث نستعرض قواعد البيانات التي توفرها فايربيس وهي فايرستور #firestore firebase.google.com وهي الأحدث و ريل تايم داتابيز #realtimeDB firebase.google.com وهي الأقدم
كلا الخدمتين تصنفان ك #NoSQL Database وتختلفان كثيرا عن قواعد البيانات العلائقية من أمثال Microsoft SQL Server و MySQL وغيرها. أيضا كلا الخدمتين تعتبران Realtime databases وهذا يميزهما عن قواعد بيانات أخرى مثل mongoDB. دعونا نستعرض علميا مالمقصود بهذه المفاهيم؟
أعرف أن البعض مطلع على هذه المفاهيم 😅 ولكن يهمني لمن لم يطلع عليها (وهذا عادة ما رأيته في مبرمجي التطبيقات خصوصا أنهم لا يحتكون كثيرا بقواعد البيانات) أن يكون لديه تصور واضح. عادة ما يغيب التعامل مع قواعد البيانات عن مبرمج التطبيق لوجود مبرمج باكاند وسيط وهذا لا يوجد في فايربيس
منذ ظهور الكمبيوتر كانت هناك مشكلة مؤرقة وهي كيفية حفظ البيانات واسترجاعها بطريقة فعالة وسريعة وسهلة على المبرمجين بدلا من استخدام الملفات files. وفي سبعينيات القرن الماضي ظهرت قواعد البيانات العلائقية Relational Databases ونجحت نجاحا باهرا وسيطرت لفترة طويلة
تعتمد هذه النوعية من قواعد البيانات على العلاقات أو Relations (وهي مأخوذه في الأصل من مفهوم هام في الرياضيات وهو مفهوم العلاقة) حيث تخزن كل مجموعة من البيانات في علاقة أو جدول table. كما تم تصميم لغة متكاملة تسمى SQL تسهل كثيرا على المبرمج الاستعلام عن بيانات معينة بشروط معينة
أصبح الموضوع بسيط جدا: تقوم بعمل استعلام لتخزين البيانات write واستعلام لقراءة هذه البيانات المخزنة read وكل ذلك باستخدام لغة سهلة وسلسة وهي SQL. كذلك توفر لك قواعد البيانات هذه ضمانات قوية من خلال ما يسمى ACID Transactions تضمن لك أن البيانات ستخزن بطريقة سليمة. ما معنى ذلك؟
باختصار، لو فرضنا أن بنكا ما لم يستخدم ACID Transactions فإن ذلك قد يؤدي إلى حالة يقوم فيها عميل بسحب مبلغ من المال دون أن يكون هناك مال في حسابه. كيف تضمن ال ACID Transactions عدم حدوث ذلك؟ موضوع يطول شرحه وتجده هنا en.wikipedia.org
اذا كانت قواعد البيانات العلائقية توفر كل هذا (لغة استعلام سهلة الاستخدام وضمانات قوية لتخزين البيانات) فلماذا نتخلى عنها ونبحث عن غيرها؟ ولماذا لا توفر فايربيس قاعدة بيانات علائقية؟ وهل يعني هذا أنه لا يمكنني بناء نظام بنكي باستخدام قاعدة بيانات فايربيس المسماة Firestore؟ 😰
١) سرعة التوسع. تعاني قواعد البيانات العلائقية من مشاكل كبيرة جدا عند توسع التطبيق وازدياد عدد المستخدمين (وبالتالي حجم البيانات) لملايين أو عشرات الملايين. هنا ستضطر إلى شراء أجهزة ضخمة غالية الثمن واستخدام تقنيات ال caching وهذه مشكلتها أنها لا تنمو بسهولة
بعبارة أخرى، عند استخدام SQL DB فإنه يصعب عليك التوسع الأفقي horizontal scaling بحيث لا يمكنك شراء المزيد والمزيد من أجهزة الكمبيوتر العادية لدعم توسعك، بل تحتاج زيادة قوة الأجهزة نفسها. لتتوسع بسرعة فإن هذه الطريقة التقليدية لحفظ البيانات لا تنفع ولا بد من طريقة مختلفة.
لئن كانت السرعة هي المشكلة الرئيسية فهي ليست المشكلة الوحيدة. هناك مشكلة أخرى وهي ٢) الحاجة لعمليات تتم في الزمن الحقيقي أو realtime read and write. كمثال على ذلك: لو كان هناك محادثة فلا بد أن يتم تخزين الرسائل من قبل الطرف الأول وقراءتها من قبل الطرف الثاني مباشرة دون أي تأخير.
لحل هذه المشاكل، هناك في الحقيقة عدة طرق وليست طريقة واحدة وبالتالي عدة أنواع جديدة وليس نوع واحد لقواعد البيانات والتي تصنف كلها تحت تصنيف #NoSQL en.wikipedia.org وهو تصنيف جامع لكافة أنواع قواعد البيانات التي تشترك فيما بينها أنها ليست SQL DB أو قاعدة بيانات علائقية
تقوم كثير من قواعد البيانات هذه بتسريع العمل من خلال مسارات عدة على رأسها: ١) تشجيع تكرار عمليات الكتابة وبالتالي عمليات تحديث البيانات (بحيث في كل مرة تضطر أن تكتب في عدة أماكن) ، مقابل تسهيل وتسريع عمليات القراءة وهو ما يسمى بال denormalization للبيانات.
٢) التنازل عن ال ACID من خلال مثلا التنازل عن ما يسمى باتساق وانتظام البيانات الآني immediate consistency والسماح بما أقل وهو ال eventual consistency. هذا الموضوع بالذات يطول ويصعب شرحه وهو غير موجود في فايرستور (قاعدة البيانات المستخدمة في فايربيس) لذلك لن أتطرق له هنا.
خلونا ناخذ تويتر كمثال لتقريب المفهومين. بدلا من كتابة التغريدة في مكان واحد لكافة التغريدات بحيث يقوم كل شخص بالقراءة من هذا المكان مما يتسبب بضغط كبير على سيرفر معين، (يتبع)
يتم كتابة التغريدة في التايملاين لكل واحد من الذين يتبعون كاتب التغريدة وبالتالي كل شخص من هؤلاء يقرأ التغريدة من مكان مختلف (سيرفر مختلف مثلا) مما يخفف الضغط على الأجهزة وعلى الشبكة. هذا المثال حسب ما سمعت هو قصة حقيقية توضح كيف عمل تويتر denormalization لتسريع قراءة التغريدات
لاحظ أنه ١) تم تكرار الكتابة لتسريع عملية القراءة ولكن ألن يصعب هذا عملية تحديث التغريدة 🤔؟ ٢) قد تظهر التغريدة في التايملاين لدى البعض قبل ظهورها لدى الآخرين فيكون هناك مرحلة عدم اتساق البيانات inconsistency ولكن في النهاية سيكون هناك اتساق كامل للبيانات eventual consistency
لهذه الأسباب (سرعة التوسع الأفقي ودعم قراءة وكتابة البيانات في الزمن الحقيقي) اختارت فايربيس قاعدتي بيانات غير علائقيتان الأولى منهما تصنف ك key-value store وهي realtime database والأحدث وهي Firestore تصنف ك document store وكلاهما تدعمان Realtime operations.
هذا الموضوع شيق وممتع جدا وغدا إن شاء الله نستكمل الحديث عن قاعدتي البيانات هاتين. قد أكون أسهبت في الشرح ولكن، أقولها مرة أخرى، الكثير من مطوري التطبيقات دائما ما يكون بينهم وبين قواعد البيانات حاجز يتمثل في مطوري الباكاند وفايربيس أزالت هذا الحاجز وفتحت الموضوع على مصراعيه 😅
حقيقة لا يقتصر ذلك على مطوري تطبيقات الجوال وإنما يمتد لمطوري تطبيقات الويب Single Page Web App باستخدام React JS أو Angular أو غيرها حيث سيجد هؤلاء كلهم أنفسهم أقرب إلى full stack developers منهم إلى front end developers ويجب عليهم تهيئة أنفسهم لذلك جيدا باستيعاب هذه المفاهيم
نستكمل حديثنا حول قواعد البيانات في فايربيس. ملخص ما كتبته حتى الآن هو: ١) توضيح نوع قواعد البيانات المعتمدة في فايربيس مقارنة بالانواع الموجودة حاليا و ٢) توضيح الأسباب التقنية في اعتماد ال #nosql في فايربيس واللي مهم تعرفها حتى تعرف الطريقة الأمثل لتصميم قاعدة بيانات تطبيقك
الآن نشرح كيف تعمل قواعد البيانات في فايربيس وكيف تصمم قاعدة بياناتك مع ذكر المزايا والعيوب لقاعدتي بيانات Firestore و Realtime Database اللي تقدمهم فايربيس. راح يكون فيه بعض التكرار لبعض ما تم ذكره سابقا ولكن هنا سيكون الشرح عملي أكثر ومفصل أكثر.
نظرا لكون فريق فايربيس ينصح باستخدام قاعدة بيانات فايرستور firestore قدر الامكان وعدم استخدام realtimeDB إلا عند الحاجة فسأبدأ بشرح فايرستور أولا ثم أوضح متى تستخدم الأخرى.
تعتبر قاعدة بيانات فايرستور document store بمعنى أنها تخزن أي شي على شكل دوكيومنت document وتتجمع الدوكيومنت مع بعضها داخل كولليكشن collection. مثلا لو عندي مطاعم وأبغى أخزن بياناتهم راح يكون عندي كوليكشن اسمه restaurants وداخله بيانات المطاعم كل مطعم في دوكيومنت.
الدوكيومنت تقريبا هي عبارة عن JSON object تقدر تضع داخلها أي بيانات تحتاجها على شكل حقول بحيث كل حقل له اسمه ونوع وقيمة (البيانات). مثلا حقل ١ اسم المطعم وحقل ٢ عنوان المطعم وهكذا. تقدر أيضا تخلي قيمة الحقل مصفوفة array أو أوبجيكت كامل map. مثلا تخزن التعليقات فيه map زي الصورة
أيضا تقدر تضع كوليكشن كامل داخل دوكيومنت. مثلا بدل ما تضع التعليقات كلها في الدوكيومنت الخاصة بالمطعم تقوم بوضع كل تعليق في دوكيومنت لوحده وتضع الدوكيومنت هذي كلها في سبكوليكشن subcollection داخل دوكيومنت المطعم. (الصور من فيديو الشرح الرائع من قوقل youtube.com)
لاحظوا من البداية كيف ظهر لنا أكثر من طريقة لترتيب هيكلة البيانات data structure داخل قاعدة بيانات فايرستور. هذا على العكس من لو كنت تستخدم SQL DB واللي غالبا تصل فيها لستركتشر معين بعد ما تسوي normalization للبيانات.
فهم كيفية هيكلة البيانات داخل فايرستور (وكثير من قواعد البيانات ال #NoSQL ) والتعمق فيه والتدرب عليه أمر جوهري وأساسي. ليش؟ 🤔
السبب هو انك بعد ما تخزن البيانات تحتاج تقرأها فيما بعد وتعرضها للمستخدم، وعشان تقرأ البيانات لابد تستخدم استعلامات queries. في فايرستور لا تستطيع استخدام لغة الاستعلام SQL (أكيد طبعا) ولكن هناك لغة خاصة query language تأتي مع ال firestore SDK firebase.google.com.
للأسف لغة الاستعلام هذي محدودة الامكانيات بشكل كبير جدا ولا أعلم حقيقة لماذا قوقل لم تعالج هذا الموضوع حتى الآن. في نظري جميع خدمات فايربيس التي تحدثت وسأتحدث مستقبلا عنها رائعة جدا عدا هذه الجزئية فهي بالنسبة لي اصنفها بين سيئة وسيئة جدا.
لماذا هي كذلك؟ لا أعلم حقيقة وهو لغز بالنسبة لي (لعل أحد من قوقل أو من خبراء قواعد البيانات يشرح لنا) ولكني سأتكلم عن ١) متى تكون هذه المشكلة كافية لترك فايرستور (وليس فايربيس) و ٢) متى تكون غير كافية وما هي الخيارات الموجودة في هذه الحالة لتجاوز هذه المشكلة وكيفية التعامل معها.
مشكلة الاستعلام في فايرستور (على الأقل ما رأيته في تجربتي حتى الآن) هي في ١) عدم وجود or وعدم وجود نفي في لغة الاستعلام في حال استعلمت على حقلين أو أكثر داخل الدوكيومنت و ٢) عدم وجود like (للبحث المبسط في النصوص) ٣) ضعف التجميعات أو aggregations .
مثلا في رقم واحد لا تستطيع تستعلم عن كافة المطاعم التي صنفها ليس "إيطالي". في رقم ثلاثة لا تستطيع معرفة عدد المطاعم التي صفنها "إيطالي".
ما هو الحل؟ ١) اختيار هيكل بيانات مناسب. مثلا أن يكون لديك إلى جوار الكوليكشن الرئيسي مجموعة من الكوليكشنز الأخرى بحيث لكل صنف كوليكشن.
ما هو الحل؟ ١) اختيار هيكل بيانات مناسب. مثلا أن يكون لديك إلى جوار الكوليكشن الرئيسي مجموعة من الكوليكشنز الأخرى بحيث لكل صنف كوليكشن.
كذلك أن يكون لديك عداد في مكان ما يكون فيه عدد المطاعم من كل صنف. ماذا لو احتجت عد المطاعم بناء على معيار آخر؟ تبني عداد آخر 😅.
فايرستور انتبهت لهذا الشيء ولذلك أ- صممت قاعدة البيانات بحيث لا تحتاج إلى مخطط او schema على عكس الوضع في SQL DB.
فايرستور انتبهت لهذا الشيء ولذلك أ- صممت قاعدة البيانات بحيث لا تحتاج إلى مخطط او schema على عكس الوضع في SQL DB.
ليس هذا فقط وإنما ب- أضافت فايرستور call back cloud functions وهي عبارة عن أكواد جافاسكربت و nodejs يتم تشغيلها عند كل عملية على كوليكشكن معين. عارف ان الموضوع بدأ يتشعب ولكن ضروري نستعرض الشيئين هذولي
أ- كون قاعدة البيانات schemaless يساعدك كثيرا على تعديل البيانات تبعا لحاجة البزنس في التطبيق. لا يوجد أي مشكلة في فايربيس من أن تكون الحقول متفاوتة بين الدوكيومنتس في نفس الكوليكشن. مثلا بعد فترة أدركت الحاجة لوجود الموقع للمطعم GPS location.
في هذه الحالة بكل بساطة تضيف حقل جديد على الدوكيومنتس الجديدة دون التأثير على الموجودة حاليا بشرط أن يكون الكود لديك متوافق مع النوعين. يمكن أيضا الاستعلام على هذا الحقل بدون مشاكل. هذا الشيء لا يعالج مشكلة ضعف الاستعلام (جزئيا) فقط بل يسمح لك بالتغيير السريع في الكود.
كثيرا ما نسمع عن أهمية سرعة اختبار البزنس والتغيير حسب الحاجة في الشركات الناشئة وهنا راح تستفيد كثير من هذه المرونة في فايرستور.
ب- كون وجود كلاود فنكشن أو كود يعمل اوتوماتيكيا في الفايربيس عند كل عملية تتم على دوكيومنت معينة أم عظيم.
ب- كون وجود كلاود فنكشن أو كود يعمل اوتوماتيكيا في الفايربيس عند كل عملية تتم على دوكيومنت معينة أم عظيم.
بكل بساطة خل عندك كوليكشن رئيسي لكل المطاعم ومجوعة كوليكشنز بحيث لكل صنف كوليكشن واكتب كلاود فنكشن تقوم بتحديث أي مطعم في أي واحد من الكوليكشنز هذي عندما يتم تحديث المطعم في الكوليكشن الرئيسي (أو اضافة أو حذف). لفة طويلة ولكن ناجحة 🤣
هذا الأسلوب هو بالضبط ما تكلمت عنه سابقا وهو ال denormalization للبيانات. ليس هذا فقط ولكن تم دمجه مع مايكرو سيرفس microservice. لإن كان استخدام التقنيتين هنا حاجة غريبة (للتغلب على ضعف الاستعلام) فإنك راح تضطر إليه رغما عنك لما توصل عدد كبير من المستخدمين.
بالنسبة لي فكون فايربيس schemaless إلى جوار امكانية التخاطب والاستعلام مباشر من التطبيق بدون وجود باكاند هما الشيئان الأساسيان والرئيسيان الذان يشفعان لها في مواجهة مشكلة ضعف الاستعلام بحيث يمكنك في البدايات تجاوز المشكلة ومن ثم الانتقال للحل رقم ٢ لاحقا.
قبل نروح لرقم ٢ أشير أن كثير من قواعد البيانات ال #nosql ترمي جزء لا بأس به من موضوع ادارة البيانات وهيكلتها على المبرمج لتقدم لك بعض الضمانات وعلى رأسها عادة السرعة في العمل والتوسع الأفقي.
ولكن مازلت أعتقد أنه من الممكن أن تكون خيارات الاستعلام أفضل في فايرستور. لماذا؟
ولكن مازلت أعتقد أنه من الممكن أن تكون خيارات الاستعلام أفضل في فايرستور. لماذا؟
لأن المنافس الرئيسي في نظري لفايرستور هو #mongoDB فهي تعمل بطريقة مشابهة إلى حد ما ولكن توفر لغة استعلام أغنى بكثير. صحيح أن فايرستور تضمن لك توسع أفقي لا محدود دون الاخلال بالسرعة ولكن ما فائدة السرعة عند التوسع لتطبيقك اذا كنت غير قادر على توفير الخدمات للزبون في البداية؟
ليس هذا فقط، بل إن mongoDB توفر حاليا منصة اسمها stitch mongodb.com وهي حسب فهمي تنافس فايربيس كمنصة وليس فايرستور فقط وتضمن التوسع الافقي اللامحدود (وإن كنت لم أستخدمها حتى أقيمها).
لا أعتقد ان stitch تصل لنفس مستوى جودة فايربيس أبدا ولكن في جزئية قاعدة البيانات بالذات فبالتأكيد أفضل وأفضل بكثير على الأقل للتطبيقات في البداية. هذا علاوة على كون mongoDB مفتوحة المصدر ودعمها بين المبرمجين أكثر بكثير من فايرستور.
نرجع للاستعلام في فايرستور. ما هو الحل الثاني فيما يخص فايرستور والذي تتجنب فيه التعديل الكبير على قاعدة البيانات بشكل مستمر؟
راح نستعرض الحل هذا في وقت لاحق ان شاء الله
راح نستعرض الحل هذا في وقت لاحق ان شاء الله
نكمل حديثنا اليوم حول فايرستور وكيفية التعامل مع النقص الموجود في لغة الاستعلام. ذكرنا في الحل الأول فكرة تكرار الكتابة denormalization وهي فكرة ممتازة جدا في كثير من الأحيان خصوصا في ظل امكانية ربط الكلاود فنكشنز cloud functions (راح نشرحها لاحقا باذن الله) بفايرستور.
وعموما فإنه عند نمو عدد مستخدمي التطبيق إلى مستويات معينة فإنك ستضطر إلى تبني هذه الفكرة سواء استخدمت فايرستور أو غيرها كما أوضحت في مثال تويتر. الحل الثاني مبني على مبدأ مهم جدا وهو ضرورة دراستك للمشروع أو التطبيق الذي ستقدم على تطويره من الناحية التقنية قبل البدء.
ماذا أقصد بذلك؟ لنفرض أنك تود عمل تطبيق في مجال التجارة الالكترونية أو مجال توصيل الطعام أو تبغى تعمل موقع وتطبيق لمساعدة الشركات في ادارة مواردها. مثل هذه المجالات يوجد لها منصات جاهزة سواء مجانية أو باشتراك وفيها خصائص عديدة جدا.
بعض الأمثلة لذلك woocommerce في التجارة الالكترونية woocommerce.com و odoo او erpnext في مجال ادارة موارد الشركات erpnext.com odoo.com وغيرها. هذه توفر لك واجهة برمجية API لتربط معها تطبيقك مع باكاند متكاملة مخصصة للخدمة نفسها.
هنا يتعدى الموضوع قاعدة بيانات فايرستور حيث أنك قد لا تحتاج لفايربيس نهائيا أو قد تحتاج خدمة أو خدمتين من فايربيس مثل cloud messaging و analytics (راح نتكلم عنهم لاحقا).
ماذا لو كان تطبيقك فريد من نوعه ويقدم خدمة جديدة أو يقدم نفس الخدمات السابقة ولكن بطريقة جديدة ومختلفة كليا؟
ماذا لو كان تطبيقك فريد من نوعه ويقدم خدمة جديدة أو يقدم نفس الخدمات السابقة ولكن بطريقة جديدة ومختلفة كليا؟
هنا نأتي لمرحلة التقييم الثانية وهي مدى حاجتك للاستعلام والفلترة المعقدة؟ هل تحتاجها داخل التطبيق وضمن وظائفه أو تحتاجها لعمل تحليل للبيانات analytics؟
اذا كنت تحتاجها ضمن وظائف التطبيق وكانت الطريقة الأولى denormalization غير مقبولة نهائيا أو غير مفهومة فهنا أمامك خيارين.
اذا كنت تحتاجها ضمن وظائف التطبيق وكانت الطريقة الأولى denormalization غير مقبولة نهائيا أو غير مفهومة فهنا أمامك خيارين.
أ) استخدام قاعدة بيانات بديلة غير فايرستور مثل مونقو دي بي أو ماي سيكول وستكون هذه خارج نطاق منصة فايربيس مع الاستفادة من خدمات فايربيس الأخرى (وهي في نظري متعددة ورائعة ومغرية).
ب) استخدام قاعدة بيانات مساندة لفايرستور واستخدام الكلاود فنكشن لعمل ال replication أو النسخ.
ب) استخدام قاعدة بيانات مساندة لفايرستور واستخدام الكلاود فنكشن لعمل ال replication أو النسخ.
هناك خدمتين أو قاعدتي بيانات تعتبران الأفضل في الفلترة والبحث والاستعلام السريع والسهل وهما خدمة ألقوليا algolia algolia.com و منتج ايلاستيك سيرش elasticsearch elastic.co. أنا أنصح بالخيار (ب) وهو استخدام قاعدة بيانات مساندة وليس الخيار الأول (أ).
لماذا؟ لأنه من المعلوم أن لكل قاعدة بيانات تخصصها الذي صنعت لأجله وحقيقة لا يوجد أبدا ما يضاهي قاعدتي البيانات المذكورتين في البحث والفلترة. مهم التنبيه إلى أنه لا يمكن استخدامهما كقاعدة بيانات رئيسية للتطبيق أو الموقع ولكن كمساندة. فايربيس تنصح باستخدام algolia وأنا متردد 😅
بالنسبة لي فأنا محب جدا للخدمات او managed services ولا أحب أبدا الدخول في إدارة باكاند وسيرفرات لذلك لن أتطرق ل elasticsearch كمنتج تقوم أنت بتركيبه وتشغيله بل سأذكر كيف يمكنك استخدامه كخدمة مدارة لك بالكامل وأوضح لماذا أفضله على algolia.
من أفضل المواقع التي تقدم elasticsearch ك managed service هو appbase.io (لم أقم بتجربته في البرودكشن) وهو سبب ميلي أكثر ل elasticsearch والسبب هو أنه ربع تكلفة algolia أو أقل (٣٠ دولار شهريا مقابل مليون عملية بينما في algolia ٣٠ دولار شهريا مقابل ٢٥٠ الف)
كذلك وبما أن appbase يعتمد على elasticsearch بإمكانك الانتقال لبيئة وسيرفرات خاصة فيك لو أردت أو الانتقال لسيرفرات مدارة من قبل شركة elastic نفسها. بالمقابل يبدو لي algolia أكثر نضجا مقارنة ب appbase وأقدم وأشهر ولكن أغلى ويزداد غلاء مع ازدياد حجم العمليات.
هنا استخدمنا قاعدة بيانات مساندة لفايرستور لعمل البحث والفلترة. ماذا عن التجميعات أو ال aggregations وبشكل عام تحليل البيانات وعمل داشبورد؟ هنا الحل الأمثل هو استخدام عملاق تحليل البيانات #bigquery cloud.google.com من شركة قوقل مع google data studio datastudio.google.com
تعتبر #bigquery قاعدة بيانات خاصة بالتحليلات data warehouse ويتم ادارتها بالكامل من قبل قوقل fully managed تماما مثل فايرستور ولكنها خارج منظومة فايرستور. تستخدم bigquery لغة استعلام مشابهة إلى حد كبير ل sql كما تخزن البيانات بطريقة مشابهة لقواعد بيانات SQL.
للتوضيح أكثر فما أقصده هنا أنه عند استخدامك ل bigquery ستجد البيانات أمامك مخزنة في جداول وصفوف مشابهة لطريقة SQL ولكنها تختلف من الداخل. أيضا يمكن ل bigquery في الصف الواحد تخزين شجرة JSON كاملة وهذا الأمر غير متوفر نهائيا في sql.
هذه الخاصية تحديدا هي ما تسمح لك بسحب بيانات فايرستور وتخزين الدوكيومنت كاملة في صف واحد في bigquery. طبعا هذا سيجعل هناك صعوبة بسيطة في عمل الاستعلامات مقارنة بقواعد بيانات sql التي اعتدنا عليها حيث أنه قد يحتوي الصف الواحد في أحد الأعمدة على مصفوفة بيانات مثلا.
لنسخ البيانات من فايرستور إلى bigquery كنت أقوم بكتابة كلاود فنكشن تماما مثل ما ذكرنا في elasticsearch (ممكن تستخدم نفس الفنكشن). ولكن أعلن فريق فايربيس هذا الأسبوع عن خاصية جديدة اسمها extensions تسمح لك بعمل أشياء عديدة دون الحاجة لكتابة كلاود فنكشن ومن ضمنها النسخ ل bigquery
تجربتي مع bigquery و data studio كانت أكثر من رائعة وحلت لي كافة مشاكل تحليل البيانات الموجودة في فايرستور. ليس هذا فقط بل استطعت دمج تحليل البيانات الموجودة في فايرستور مع البيانات التي يتم جمعها عبر google analytics للموقع و firebase analytics للتطبيق.
هذا الشيء ساعدني على بناء داشبورد متميزة جدا وبسهولة (على فرض طبعا أنك تعرف تكتب sql queries في bigquery وتعرف تتعامل مع ال arrays خصوصا وهو كما ذكرت غير موجود في ال sql العادي😅).
خلوني ألخص الحل الثاني لضعف الاستعلام في فايرستور:
١) لا تستخدم منصة فايربيس (عدا خدمات معينة مفيدة في كافة الأحوال مثل ال analytics) اذا عندك تطبيق معتاد ومعمول مثله الكثير من قبل مثل المتجر الالكتروني.
١) لا تستخدم منصة فايربيس (عدا خدمات معينة مفيدة في كافة الأحوال مثل ال analytics) اذا عندك تطبيق معتاد ومعمول مثله الكثير من قبل مثل المتجر الالكتروني.
٢) استمر في استخدام فايربيس وخدماتها المتعددة ولكن استخدم قاعدة بيانات بديلة لفايرستور
٣) استخدم قاعدة بيانات مساندة لفايرستور وانا أرشح elasticsearch للبحث والفلترة باستخدام خدمة appbase.io و bigqyery مع قوقل ستوديو للتحليلات analytics>
٣) استخدم قاعدة بيانات مساندة لفايرستور وانا أرشح elasticsearch للبحث والفلترة باستخدام خدمة appbase.io و bigqyery مع قوقل ستوديو للتحليلات analytics>
بين الحلول السابقة كلها فاختياري هو Firestore + Elasticsearc + bigquery في حالة كان لديك تطبيق فريد من نوعه أما في حال تريد عمل شي معروف مسبقا فلا تعد اختراع العجلة أصلا.
ملاحظات أخيرة بخصوص فايرستور:
١- فايرستور تحاسبك 💸 ب (١) حجم البيانات المخزنة + (٢) عدد مرات القراءة والكتابة وهي عادة التكلفة الأكبر + (٣) حجم الباندويدث (البيانات) الخارج للزوار أو مستخدمي التطبيق. #blaze-calculator" target="_blank" rel="noopener" onclick="event.stopPropagation()">firebase.google.com يمكنك البدء مجانا حتى حد معين (سخي) حسب الشرح في الرابط
١- فايرستور تحاسبك 💸 ب (١) حجم البيانات المخزنة + (٢) عدد مرات القراءة والكتابة وهي عادة التكلفة الأكبر + (٣) حجم الباندويدث (البيانات) الخارج للزوار أو مستخدمي التطبيق. #blaze-calculator" target="_blank" rel="noopener" onclick="event.stopPropagation()">firebase.google.com يمكنك البدء مجانا حتى حد معين (سخي) حسب الشرح في الرابط
يمكنك أيضا وضع حد معين للفاتورة (بحيث يتوقف عمل فايرستور عند هذا الحد وهو طبعا أفضل من فاتورة فلكية 😰) cloud.google.com وأعتقد أن هذا شيء مهم جدا حتى ما تجيب العيد. غالبا التكلفة اذا ارتفعت فستكون من كثرة عمليات القراءة أو الكتابة في الكود فيجب الانتباه لذلك.
٢- يمكنك عمل نسخ احتياطي لفايرستور ويوجد شرح كامل لذلك من قبل قوقل #export_all_documents" target="_blank" rel="noopener" onclick="event.stopPropagation()">firebase.google.com الحل ليس بالسهولة المطلوبة ولا أعلم لماذا ولكنه على الأقل موجود.
٣- يمكنك تصفح البيانات في فايرستور من خلال ال console الخاص بفايربيس ولكن للأسف لا يمكنك عمل export و import من خلاله (مثلا عند رغبتك في نقل بيانات من قاعدة بيانات لأخرى). عموما ادارة قاعدة بيانات في فايرستور عن طريق ال console ينقصها تحسينات عدة أتمنى تعملها قوقل.
٤- فايرستور توفر خدمة realtime synchronization ضمن كافة استعلاماتها (بمعنى الاستعلام لا يقرأ البيانات مرة واحدة فقط بل بشكل مستمر أوتوماتيكيا عند كل تغيير) وهذه خدمة مهمة لبعض التطبيقات خصوصا الألعاب بالدرجة الأولى (وان كانت ال realtime DB أفضل في هذا المجال) وكذلك السوشال ميديا
الملخص أن فايرستور لها مستقبل كبير لو استمرت قوقل بالاهتمام بها وحل المشاكل التي ذكرتها. نكمل لاحقا ان شاء الله عن realtime DB ومن ثم بقية الخدمات في منصة فايربيس.
نكمل اليوم حديثنا عن منصة فايربيس وراح يكون الموضوع عن الكلاود فنكشنز (راح نؤجل الحديث عن reatime DB لوقت لاحق). مثل ما كان حديثنا عن فايرستور عني بكثير من التفاصيل الممتعة، نفس الشي حديثنا عن الكلاود فنكشنز راح يكون غني بالكثير من التفاصيل الممتعة.
خلونا نبدأ أولا بإجابة السؤال التالي: بما أن الكلاود فنكشنز cloud functions هي باكاند هل كمطور تطبيقات أصلا أحتاجها؟
غالبا لن تكون بحاجة إلى الكلاود الفنكشنز خصوصا في بداية تطوير التطبيق. ولكن سيأتي عليك وقت ستضطر فيه إلى كتابة كلاود فنكشنز وذلك لسببين رئيسيين.
غالبا لن تكون بحاجة إلى الكلاود الفنكشنز خصوصا في بداية تطوير التطبيق. ولكن سيأتي عليك وقت ستضطر فيه إلى كتابة كلاود فنكشنز وذلك لسببين رئيسيين.
١- ستحتاج إلى كتابة كلاود فنكشنز لتساعدك في عمل ال denormalization للبيانات في قاعدة بيانات فايرستور كما شرحنا سابقا خصوصا عندما تكبر قاعدة البيانات وتتشعب.
٢- ستحتاج إلى كتابة كلاود فنكشنز كباكاند لتقديم بعض الخدمات التي يصعب جدا (وقد يستحيل) تقديمها من خلال كود التطبيق فقط دون الاخلال بأمن تطبيقك 😅 أو كنت تحتاج التواصل مع خدمات أخرى 3rd party خارج منصة فايربيس (دفع الكتروني مثلا).
بغض النظر أنت مطور تطبيق أو لا، خلونا نشرح التقنية وكيفية استخدامها سواء كنت مطور تطبيق أو شغوف بالتقنيات الجديدة في تطوير الباكاند والمعتمدة على مبادئ microservices و serverless خصوصا وأن الكلاود فنكشنز يمكن استخدامها مستقلة من خلال منصة google cloud الأخ الأكبر لمنصة فايربيس.
عشان أقرب لك فكرة الكلاود فنكشنز firebase.google.com تخيل ان عندك صديق فاهم مرة في السيرفرات وادارة السيرفرات على الكلاود وكيف يركب nodejs وكيف يركب ويب سيرفر زي nginx أو apache مثلا ويشغلها ويسوي لها تحديث كل ما نزل تحديث.
خويك هذا جالس جنبك يقول اكتب أي كود باكند تحتاجه وحدد لي وش المكتبات اللي تحتاجها وخل الباقي علي. مو بس كذا، كل جزئية في الكود تكتبها لوحدها على شكل فنكشن بحيث مهمتها تكون واضحة لك تماما.
مثلا تبغى تكتب كود مهمته ياخذ أي صورة يرفعها المستخدم ويسوي منها نسخة مصغرة thumbnail. بغض النظر عن باقي الكود في الباكاند، تكتب فنكشن وحدة تسميها مثلا generateThumbnail بحيث تقرأ الصورة من مكان محدد (مثلا google storage) وتصغرها وترجع تخزنها. بس هذا الشي الوحيد اللي تسويه.
بعد ما تخلص تعطي خويك الكود وهو يتولى الباقي 😀. لاحظ معي انك راح تستفيد حاجتين:
١- بعد فترة راح تلاحظ ان مشروعك عبارة عن مجوعة من الفنكشنز (أو الخدمات الصغيرة microservices) كل وحدة تؤدي غرض معين بشكل مستقل عن بقية الفنكشنز مما يسهل الكتابة والصيانة.
١- بعد فترة راح تلاحظ ان مشروعك عبارة عن مجوعة من الفنكشنز (أو الخدمات الصغيرة microservices) كل وحدة تؤدي غرض معين بشكل مستقل عن بقية الفنكشنز مما يسهل الكتابة والصيانة.
٢- باستخدام هذه الطريقة في التطوير بامكانك تشغيل فنكشن معينة بشكل منفصل عن الآخرى بحيث لو الفنكشن هذي صار عليها ضغط فإنك تسوي scale لها وحدها بدون ما تتأثر بقية الفنكشنز. هذا يساعد في سهولة وقلة تكلفة ال scalability أو التوسع السريع في تنفيذ الكود.
صراحة الطريقة سهلة جدا (ومجانية لحد معين) لدرجة انه يمديك الآن (بشرط تعرف شوي جافاسكربت) انك خلال نصف ساعة تكتب كود باكاند متكامل وترفعه وتجربه وتطفيه بدون سيرفرات أو دومين أو تركيب ويب سيرفر أو معرفة بلنكس أو غيرها من الأمور. هنا تجد مثال متكامل firebase.google.com
ايش فرق الطريقة هذي عن الطريقة التقليدية في تطوير الباكاند؟
١- في الطريقة التقليدية تقوم بكتابة برنامج متكامل للباكاند monolithic service بحيث أي تعديل في جزئية معينة غالبا تتطلب منك إعادة رفع البرنامج كاملا. بالمقابل في الكلاود فنكشنز تكتب كل جزئية أو وظيفة بشكل مستقل (يتبع)
١- في الطريقة التقليدية تقوم بكتابة برنامج متكامل للباكاند monolithic service بحيث أي تعديل في جزئية معينة غالبا تتطلب منك إعادة رفع البرنامج كاملا. بالمقابل في الكلاود فنكشنز تكتب كل جزئية أو وظيفة بشكل مستقل (يتبع)
(يتبع ١) لوحدها دون النظر لبقية الأجزاء وترفعها deploy لوحدها أيضا. بشكل عام (وإن كان هذا الشيء لم يحصل لي في فايربيس) من الممكن أن تكون هناك فنكشن مرتبطة بفنكشن أخرى ولكن هذا الشيء يتم من خلال interface أو API واضحة ومستقلة.
٢- أثناء تشغيل البرنامج التقليدي (في الباكاند أو السيرفر) لو صار فيه ضغط مستخدمين على جزئية معينة (مثلا عدد كبير من المستخدمين فجأة قرر يسوي تسجيل دخول) فإن الضغط هذا راح يؤثر على باقي الأجزاء ويبطئها. بالمقابل في الكلاود فنكشن كل فنكشن تعمل لوحدها مستقلة عن بقية الفنكشنز (يتبع)
(يتبع ٢) مثلا، لو أخذنا مثالنا وهو الفنكشن المختصة بتصغير الصور، فإنه في حال قام عدد كبير جدا من المستخدمين برفع صور لن تتأثر سرعة التطبيق حيث ستقوم قوقل مباشرة بعمل scale للفنكشن أوتوماتيكيا لتلبية الطلب العالي دون التأثير على بقية الفنكشنز ودون تدخلك الشخصي.
٣- هذه النقطة مرتبطة نوعا ما بالسابقة وملخصها أنه في الطريقة التقليدية يتم تشغيل البرنامج بشكل مستمر 24/7 وبنفس الموارد (وبالتالي نفس التكلفة المالية) من خلال وجود سيرفر مستقل في الكلاود. في المقابل في الكلاود فنكشن يتم تشغيل الفنكشن لكل طلب يأتي ويكون الحساب (يتبع)
(يتبع ٣) ويكون الحساب على فترة التشغيل فقط. مثلا نرجع لمثالنا السابق وهو الكلاود فنكشن الخاصة بتصغير الصور. يتم تشغيل الفنكشن لكل صورة يتم رفعها ويتم محاسبتك ماليا على فترة عمل الفنكشن فقط. هذا النموذج المالي غريب وجديد على الكثير ممن اعتاد التعامل مع السيرفرات في الباكند (يتبع)
(يتبع ٣) وهو يتناسب بشكل ممتاز مع التطبيقات التي لديها وقت ذروة للعمل ووقت هدوء حيث ستعمل الكلاود فنكشنز وقت الذروة ويتم لها scale لتلبية كافة احتياجات العملاء دون تأخير بينما في وقت الهدوء لن يتم محاسبتك على سيرفر جالس بدون عمل 😰
كما يقول المثل الأمريكي There ain't no such thing as a free lunch. كل ما سبق ذكره رائع ولكن هذا لا يعني أن الكلاود فنكشن خالية من العيوب ويجب فهم هذه العيوب بشكل جيد ودقيق. سوف نوضح هذه العيوب لتفاديها ولكن بعد أن نشرح الأنواع المختلفة للكلاود فنكشن وطريقة عمل كل نوع.
هناك نوعين من الكلاود فنكشنز وهما (١) HTTP functions و (٢) background functions. ال HTTP function هي عبارة عن كود جافاسكربت و nodejs (أو بايثون أو go وهي اللغات التي تدعمها قوقل حاليا) يتم استدعاؤه عبر http request. لاحظ اني سمته كود جافاسكربت وليس جافاسكربت فنكشن.
السبب في ذلك انه ممكن الكلاود فنكشن تحوي داخلها أكثر من جافاسكربت فنكشن (كلمة فنكشن هي كلمة دعائية ترويجية من قوقل ولا تعني مصطلح فنكشن المستخدم في لغات البرمجة). ال http function هي من أسهل الطرق لعمل rest API. شخصيا كانت أول مرة لي استخدم nodejs express من خلال كلاود فنكشن.
أخذت مني حوالي ساعة أكتب الكود وأختبره وأسوي له ديبلوي وأشغله. بالنسبة لي أكتب Rest API endpoint متكاملة واختبرها وأرفعها جاهزة برودكشن في بيئة استخدمها أول مرة وخلال ساعة وعارف انها ممكن تتحمل ملايين المستخدمين كان شي عظيم.
فايربيس توفر لك نسخة اضافية خاصة من ال http function اسمها http callable function تقدر تستدعيها مباشرة من ال firebase client SDK في تطبيقك وليس من خلال http request (فعليا الطلب يتم من خلال http request ولكن مسهلينه عليك) وبشكل سهل جدا أسهل بكثير من استخدام express.
ال background function هي أيضا عبارة عن كود جافاسكربت ولكن لا تستطيع استدعاءها مباشرة وإنما يتم تشغيلها بناء على حدث معين event driven في خدمة معينة في فايربيس (أو قوقل كلاود). مثلا تقدر تكتب فنكشن تشتغل أوتوماتيكيا بعد كل عملية اضافة دوكيومنت إلى كوليكشن في فايرستور.
هذا النوع من الفنكشنز هو اللي تحدثت عنه سابقا لما تحدثت عن كيفية ادارة عملية ال denormalization في فايرستور. مثلا ذكرت سابقا مشكلة ال aggregation وكيف انك تحتاج تستخدم هذا النوع من الكلاود فنكشنز لحلها.
مثلا، لو حبيت تحسب متوسط عدد النجوم في التعليقات reviews بكل بساطة تستخدم background فنكشن "تتسمع" لأي تعليق جديد ينكتب في فايرستور وتقوم بحساب المتوسط وتخزينه.
كل واحد من النوعين من الفنكشنز له مشاكله التي يجب الانتباه لها.
بالنسبة للنوع الأول وهو ال http function فتتمثل مشكلته الرئيسية في بطء التشغيل في المرة الأولى. ليش الشيء هذا؟ ما أعرف بالتفصيل كيف قوقل بنت ال engine الخاص بالكلاود فنكشنز ولكن راح أحاول ابسط الموضوع قدر الامكان.
بالنسبة للنوع الأول وهو ال http function فتتمثل مشكلته الرئيسية في بطء التشغيل في المرة الأولى. ليش الشيء هذا؟ ما أعرف بالتفصيل كيف قوقل بنت ال engine الخاص بالكلاود فنكشنز ولكن راح أحاول ابسط الموضوع قدر الامكان.
لما تقوم باستدعاء كلاود فنكشن عبر http request لأول مرة (أو من خلال الclient SDK في تطبيقك) فإن محرك الكلاود فنكشن في قوقل كلاود يقوم بتجهيز وتشغيل بيئة كاملة (خل نسهلها ونقول سيرفر خاص فيك) حتى يتم تنفيذ الفنكشن هذي.
البيئة هذي تحتوي على التالي (هذا تصوري فقط حسب ما قرأت وليس بالضرورة الكلام هنا دقيق) : نظام تشغيل + ويب سيرفر + nodejs server + كل المكتبات اللي انت مستخدمها في كود الفنكشن. كل هذا عشان فنكشن وحدة واستدعاء واحد فقط للفنكشن هذي.
بالتأكيد لما يتم تشغيل البيئة هذي كلها للمرة الأولى ما راح يكون في ١٠ أو ٢٠ ملي سكند (جزء من الألف من الثانية) ولكن يبي ياخذ ٥ أو ١٠ أو ٢٠ ثانية. هذه تسمى التشغيل البارد cold start (التشغيل لأول مرة). راح تلاحظ انه أول استدعاء للنفكشن يطول وأكيد طبعا العملاء راح يحسون بالتأخير.
بعد التشغيل الأول تنتقل الفنكشن لوضع الاستدعاء العاجل hot start وتظل في هذا الوضع لفترة (لا أعلم كم بالضبط) ومن ثم تعود مرة أخرى في حال لم يتم استدعاؤها إلى وضع التشغيل البارد. لذلك لما يكون استدعاء الفنكشن متكرر بشكل متتابع بسبب كثرة الاستدعاءات الناتج عن كثرة المستخدمين (يتبع)
الفنشكن راح تكون سريعة جدا وتستغرق وقت بسيط جدا في كل استدعاء حتى تبدأ في التنفيذ. اذا في حال وجود عدد قليل من المستخدمين للفنكشن راح يكون فيه بطء بينما في المقابل في حالة ملايين المستخدمين راح تشتغل بشكل سريع جدا.
هذه المشكلة تتضح بشكل أكثر بالنسبة للكلاود فنكشن لما تكون الفنكشن تسوي عمل كثير وتحمل مكتبات كثيرة قبل تشتغل slow initialization. حسب ما سمعت انه قوقل تعمل جاهدة لتسريع الاستدعاء البارد قدر الامكان.
بالمقابل و في الطريقة التقليدية يكون عندك سيرفر خاص فيك وشغال طول الوقت والتأخير يكون محدود جدا أقل من ثانية في حالة عدد المستخدمين محدود (طبعا طبيعي لأنك جالس تدفع مال مهدر 😁). لكن لما ينضغط السيرفر بسبب كثرة المستخدمين راح يكون السيرفر بطيء جدا ولما توصل ملايين راح ينهار.
مهم جدا تنتبه للنقطة هذي وتحاول تتأكد من ان الفنكشن خفيفة وسريعة قدر الامكان. هذا مقال ممتاز يتحدث عن الموضوع بالتفصيل: @duhroach/improving-cloud-function-cold-start-time-2eb6f5700f6" target="_blank" rel="noopener" onclick="event.stopPropagation()">medium.com . فيه طريقة أخرى وان كنت لم أجربها ولا أعلم مدى فعاليتها وهي أن تجعل الفنكشن دائما في وضع تشغيل عاجل hot start.
هذا الشيء يحدث لما تشتغل الفنكشن عمدا بشكل متتابع. بكل بساطة تشوف لك طريقة تستدعي فيها الفنكشن على الأقل مرة واحدة كل خمس دقائق مثلا (ما أعرف كم الوقت بالضبط 😅) حتى تظل دائما hot start. هذا أكيد راح يكلفك فلوس أكثر لأن كل استدعاء فيه فلوس ولكن يعطيك سرعة أكبر.
خاصية أخرى أيضا راح تفقدها لما تستخدم الكلاود فنكشن مقارنة بسيرفرك الخاص وهي أن لا يمكنك الاحتفاظ بال execution state بين استدعاء وآخر. أي بيانات في الفنكشن أثناء تنفيذها لابد تحفظها (في فايرستور مثلا) ولا راح تضيع عليك. ما تقدر تخزنها في الميموري وتشاركها بين أكثر من request
أخيرا لابد تنتبه في ال http function انك لازم دائما تنهي الفنكشن عبر ارجاع http response. لما قوقل تشغل لك الكلاود فنكشن فإنه لازم فيه شي تعرف من خلاله ان الفنكشن خلصت عملها. ليش الشيء هذا مشكلة؟ لأنه ممكن تكتب asynchronous code وبالتالي انتهاء ال main loop لا تعني الانتهاء.
ايش يحدث لما ما تنهي الفنكشن بالطريقة الصحيحة واللي يصير كثير خصوصا عند حدوث خطأ error أثناء تنفيذ الكود؟ راح تستمر الفنكشن في العمل أكثر من اللازم حتى يحصل timeout وبالتالي تكلفة أكثر (أو ممكن يتم انهاؤها قبل انتهاء التنفيذ كما سنرى لاحقا).
هذا فيما يخص ال http functions ولاحقا نكمل حديثنا عن عيوب ال background functions وكيف يمكن تعالجها.
نكمل حديثنا حول الكلاود فنكشن في فايربيس بالحديث اليوم عن ال background functions وكيفية عملها واستخداماتها ومخاطرها
ال background function هي عبارة عن كود يتم استدعاؤه أوتوماتيكيا عند حدوث حدث معين (انت تحدده من قائمة طويلة من الأحداث) في فايربيس. مثلا يمكنك كتابة باكقراوند فنكشن يتم استدعاؤها في كل مرة يتم اضافة دوكيومنت في كوليكشن معين في فايرستور.
كذلك يمكنك كتابة فنكشن اخرى تستعدى مع كل عملية حذف لدوكيمنت وكتابة فنكشن ثالثة تستدعى مع كل عملية تحديث لبيانات دوكيومنت وهكذا مع ملاحظة أنه لابد دائما من تحديد الكوليكشن. سبق أن أعطيت أمثلة في هذه السلسلة حول فائدة مثل هذه الفنكشن واستخدماتها.
مثلا يمكنك استخدام فنكشن لحساب متوسط قيمة التقييم لكل مطعم في تطبيق بحث عن مطاعم. طريقة عمل مثل هذه الفنكشن كالتالي:
١- تقوم بتسجيل الفنكشن ك "مستمع" لحدث اضافة تقييم داخل subcollection يتبع دوكيومنت لمطعم معين.
١- تقوم بتسجيل الفنكشن ك "مستمع" لحدث اضافة تقييم داخل subcollection يتبع دوكيومنت لمطعم معين.
٢- تكتب كود الفنكشن بحيث يقوم بحساب المتوسط الجديد للتقييم بناء على المتوسط الحالي والقيمة الجديدة ثم يقوم بكتابة المتوسط الجديد داخل الدوكيومنت التابعة للمطعم.
٣- تقوم برفع الفنكشن إلى مشروعك في فايربيس وستقوم فايربيس بتشغيل الفنكشن تلقائيا في كل مرة يتم فيها اضافة تقييم جديد.
٣- تقوم برفع الفنكشن إلى مشروعك في فايربيس وستقوم فايربيس بتشغيل الفنكشن تلقائيا في كل مرة يتم فيها اضافة تقييم جديد.
مهما كان عدد المستخدمين الذين يضيفون تعليقات ومهما كان الضغط على التطبيق سيعمل الكود بسلاسة.
واضح تماما مدى السهولة (بشرط أن يكون لديك حد معقول من المعرفة بلغة جافاسكربت) ولكن هناك خطر وحيد ☠️ يجب الانتباه له جيدا ألا وهو ال infinite loops او الاستدعاء المتكرر اللامنتهي.
واضح تماما مدى السهولة (بشرط أن يكون لديك حد معقول من المعرفة بلغة جافاسكربت) ولكن هناك خطر وحيد ☠️ يجب الانتباه له جيدا ألا وهو ال infinite loops او الاستدعاء المتكرر اللامنتهي.
انظر إلى الكلاود فنكشن في الصورة وتأملها جيدا. كود بسيط يقوم بالاستماع لأي تحديث على دوكيومنت داخل كوليكشن اسمه facts ثم يقوم بتحديث حقل updatedAt الذي يسجل فيه وقت آخر تحديث للدوكيومنت. الغرض هو معرفة متى تم آخر تحديث للدوكيومنت وبدلا من عمل ذلك في التطبيق تم من خلال كلاود فنكشن
هذه صورة توضح كيفية استدعاء الكلاود فنكشن. الخط الأحمر يوضح أن الفنكشن تستدعى بناء على أي تحديث لأي دوكيومنت في الكولليكشن facts. بعد ذلك تقوم الفنكشن بتحديث الحقل updatedAt حسب الخط الأسود. هذا بدوره سيؤدي لاستدعاء الفنكشن مرة أخرى وهكذا ... استدعاء غير منتهي 😰😰😰
السؤال: متى سيتوقف الاستدعاء 🙄؟ عند وصول الحد الأعلى اليومي من عدد الاستدعاءات المسموح به من قبل قوقل. في حال استخدمت الخطة المجانية من فايربيس spark أو الخطة التي تكلف ٢٥ دولار شهريا flame لا يوجد مشكلة. ولكن في حال استخدمت خطة فايربيس المدفوعة حسب الاستخدام blaze ... 💨🏃♂️
حقيقة لا يوجد حسب علمي طريقة للحد من عدد الاستدعاءات اليومي للحماية من هذه المشكلة في حال استخدمت خطة blaze ولا أعلم لماذا! (إذا أحد يعرف كيف يعلمنا وأكون له شاكر) لذلك يجب الانتباه والحذر كثيرا عند استخدام ال background function من حدوث مثل هذه المشكلة.
هذه المشكلة معقدة وليست بالسهولة التي تبدو فيها (ولها حل طبعا كما سأوضح لاحقا) كما هو موضح في الرسمة. ليس بالضرورة أن يكون الاستدعاء اللامنتهي بين فنكشن وكوليكشن واحد ولكن من الممكن أن يكون بين ٢ أو ٣ فنكشنز وكوليكشنز. فنكشن ١ تستمع إلى كوليكشن ١ وتحدث كوليكشن ٢. فنكشن ٢ العكس.
قد تحدث هذه المشكلة أيضا عندما تتعامل مع firebase storage الخاص بتخزين الملفات عندما يكون لديك فنكشن تقوم بالاستماع على أي عملية اضافة في مكان معين (certain path) في الستوريج بحيث عند عملية الاضافة تقوم بقراءة الملف ومعالجة البيانات و من ثم تخزينها في ملف جديد.
مثلا لديك فنكشن اسمها generateThumbnail تقوم بالاستماع عند اضافة أي صورة ومن ثم قراءة الصورة وعمل صورة جديدة مصغرة thumbnail وتخزينها. المشكلة تحدث عندما تقوم بتخزين الصورة المصغرة حيث سيتم قراءتها مرة أخرى بحكم أن الفنكشن تقرأ أي صورة جديدة يتم اضافتها.
الحل مع كل هذه المخاطر هو استخدام شرط (أو شروط) داخل كل كلاود فنكشن بحيث تضمن عدم عمل هذه الفنكشن إلا في حالات معينة ومحددة. مثلا في حالة الصورة يتم عمل الفنكشن فقط في حال كان اسم الصورة الجديدة منتهي بكلمة newly_uploaded.
في حالة فايرستور يجب عليك:
١- التأكد عند الكتابة في كوليكشن من قبل فنكشن تستمع على نفس الكوليكشن (الحالة رقم واحد) من أن الكتابة لا تؤدي إلى استدعاء نفس الفنكشن مرة أخرى (أو استدعاء فنكشن أخرى تستدعي هذه الفنكشن) وذلك بوضع شرط يحول دون ذلك.
١- التأكد عند الكتابة في كوليكشن من قبل فنكشن تستمع على نفس الكوليكشن (الحالة رقم واحد) من أن الكتابة لا تؤدي إلى استدعاء نفس الفنكشن مرة أخرى (أو استدعاء فنكشن أخرى تستدعي هذه الفنكشن) وذلك بوضع شرط يحول دون ذلك.
في المثال الذي ذكرناه سابقا يتم وضع شرط يتأكد من أن تحديث الدوكيمنت تم على حقول غير حقل الوقت updatedAt (لأن تحديث حقل الوقت يتم من الفنكشن نفسها) وفي حال كان الوضع كذلك يتم تنفيذ الفنكشن وإلا يتم التوقف.
٢- في حال استخدامك لل denormalization فيفضل دائما عند وجود نوعية من البيانات لديها تكرار في أكثر من كوليكشن أن يكون لديك primary collection بحيث يكون هو الوحيد الذي يستقبل عمليات التحديث والكتابة من المستخدم وأما بقية الكوليكشنز تكون للقراء فقط (والتحديث من الكوليكشن الرئيسي فقط)
٣- يفضل أن تكون لديك رسمة توضح كافة الكوليكشنز في الداتابيز وكافة الفنكشنز ومالذي تستمع له كل فنكشن ومالذي تقوم بتحديثه. والأفضل أن تشمل هذه الرسمة firestore + realtimeDB + storage لأنه من الممكن الاستماع لهذه الثلاثة والربط بينها عبر ال background functions.
في الحقيقة مثل هذه المشكلة ليست جديدة وهي مشكلة معروفة في ال event based systems أو ال reactive systems والتي يكثر فيها استخدام ال callback functions وهذا الاسم العلمي للأكواد التي تعمل بطريقة مشابهة لل background functions.
الجديد هنا هو أنه عند حدوث تسلسل استدعاء غير منتهي في ال background functions فإنه لا يمكن ايقافه (لا أتكلم هنا عن منعه والحماية منه بل عن ايقافه بعد حدوثه) الا بطريقة واحدة فقط وهي حذف الفنكشن (لا يوجد طريقة لإيقاف عمل الفنكشن) أو الانتظار لحين أن تقوم قوقل بإيقافها.
الانتظار - كما ذكرت سابقا - سهل جدا في حالة كنت على خطة محدودة مثل flame و spark ولكنه مكلف جدا (لا أعلم كم بالضبط ولكن قد يصل لآلاف الدولارات في يوم واحد واللي قدر الله عليه وجرب قبل يعلمنا 😁) في حال كنت تستخدم blaze. مرة أخرى لا تتيح لك قوقل طريقة لوضع حد حسب علمي.
لهذا السبب أنصح أن يكون لديك على الأقل بيئة اختبار محدودة بالخطة المجانية بحيث تجرب فيها الكلاود فنكشن اذا كنت خايف منها أو شاك فيها قبل ما تستخدمها في البيئة الرئيسية.
أختم حديثي هنا بتوضيح أن مشكلة الاستدعاء غير المنتهي هي خاصة بال background functions وهي النوع الثاني من ال cloud functions ولكنها غير موجودة في النوع الأول وهو ال http functions (ممكن تحدث في حالات نادرة جدا جدا في حالة حدوث infinite loop في ال system ككل).
نتوقف اليوم ونكمل لاحقا إن شاء الله مع المزيد من خدمات فايربيس
في الاسابيع الماضية تكلمنا كثيرا حول الجوانب والخدمات التقنية للفايربيس ولكن في أي تطبيق هناك دائما جانب الأعمال والبزنس وهو ما يغفل عنه للأسف الكثير من المطورين لقلة خبرتهم في هذا المجال. فايربيس اناليتكس firebase analytics توفر لك بيئة رائع لدعمك في هذا المجال. كيف؟ خلونا نشوف.
فايربيس اناليتكس عبارة عن نظام BI أو ذكاء أعمال (وليس ذكاء اصطناعي) مبني وجاهز لك من قبل قوقل ويوفر لك أهم المقاييس أو ال KPIs (Key Performance Indicators) اللي تستخدم عادة في قياس مدى نجاح التطبيقات من ناحية البزنس.
فايربيس اناليتكس هو الأخ الأصغر ل google analytics الشهير والمعروف والذي يستخدم على نطاق واسع لقياس أداء ونجاح مواقع الانترنت.
النظام يوفر لك مكتبة جاهزة تضعها في تطبيقك وتقوم هي مباشرة بقياس عدد كبير من المؤشرات الخاصة بأداء التطبيق (سأشرح بعضها لاحقا).
النظام يوفر لك مكتبة جاهزة تضعها في تطبيقك وتقوم هي مباشرة بقياس عدد كبير من المؤشرات الخاصة بأداء التطبيق (سأشرح بعضها لاحقا).
بمجرد استخدام المكتبة firebase analytics SDK و نشرك للتطبيق في المتجر (ابل أو قوقل) وبدء استخدام التطبيق يبدأ النظام بالتقاط كمية كبية من المعلومات والمؤشرات ووضعها لك في لوحة تحكم أو dashboard موجودة ضمن بيئة فايربيس ومجانا.
ما هي هذه المؤشرات ولماذا يعتبر وجودها ومتابعتها مهم لك؟
من أخطر الأشياء على مطور أي تطبيق هو أن تستغرق وقت طويل في تطوير تطبيقك وتحاول أن يكون التطبيق متقن إلى أبعد حد دون النظر لوجهة نظر العملاء ودون قياس نجاح تطبيقك. للأسف خطأ شائع جدا خصوصا لدى التقنيين والمبرمجين.
من أخطر الأشياء على مطور أي تطبيق هو أن تستغرق وقت طويل في تطوير تطبيقك وتحاول أن يكون التطبيق متقن إلى أبعد حد دون النظر لوجهة نظر العملاء ودون قياس نجاح تطبيقك. للأسف خطأ شائع جدا خصوصا لدى التقنيين والمبرمجين.
مرة ثانية: ما هي هذه المؤشرات التي يجب علينا متابعتها؟ أول مؤشر هو عدد المستخدمين الفاعلين أو ما يسمون بال active users. هذا المؤشر يقيس كم مستخدم يستخدم تطبيقك ويتفاعل معه بشكل (يومي، أسبوعي، شهري). هذه من أهم أهم المؤشرات التي يجب عليك متابعتها وتنميتها وزيادتها عبر الوقت.
هذه المؤشرات لها مسميات مشهورة جدا في عالم ريادة الأعمال والبزنس وهي DAU أو (Daily Active Users) عدد المستخدمين اليومي و MAU أو (Monthly Active Users) الشهري. بمجرد استخدامك firebase analytics في تطبيقك فإن هذه المؤشرات يتم حسابها آليا ويتم عرضها في الداشبورد كما في الصورة.
تعرض لك الداشبورد بشكل تلقائي قيم هذه المؤشرات في رسوم بيانية ل ٢٨ يوم السابقة (الخط الغير متقطع) مع مقارنة بال ٢٨ يوم التي قبلها (الخط المتقطع). يمكنك تحديد مدى آخر للمؤشرات كآخر ثلاثة أشهر مثلا أو بمعنى آخر تستعرض عدد المستخدمين اليومي لكل يوم خلال الثلاثة أشهر الماضية.
بالنسبة للخط الخاص بالمعدل الشهري (تم تعديل اسمه إلى 28-day في الداشبورد الآخيرة) ولأن معناه يلخبط البعض، خلوني أوضح انه هذا الخط يوضح عدد المستخدمين الشهري لكل يوم من أيام الفترة المختارة (يعني عدد مستخدمي التطبيق خلال مدة الشهر التي تسبق هذا اليوم).
ناخذ الصورة المرفقة كمثال. لاحظ انه التطبيق هذا عدد المستخدمين اليومي لهذا اليوم وصل إلى مليون ومائة ألف مستخدم بينما كان تقريبا مليون قبل شهر، بينما عدد المستخدمين الشهري في آخر يوم وصل اثنين ونص مليون بمعنى من قبل ٣٠ يوم وحتى هذا اليوم فيه ٢.٥ مليون مستخدم فتحوا التطبيق.
الرقمين هذولي دايما يلخبطون. كيف العدد اليومي مليون والعدد الشهري مليونين ونصف؟🧐😇 الموضوع جدا سهل وفي نفس الوقت رائع. فايربيس ما تعد نفس المستخدم مرتين في نفس اليوم اذا بغيت العدد اليومي ولا تعده مرتين في نفس الشهر اذا بغيت العدد الشهري.
مثلا محمد دخل اليوم على التطبيق ثلاث مرات بينما خالد دخل مرتين ونورة دخلت مرة واحدة. بالمقابل نورة دخلت قبل ثلاثة أيام وفاطمة برضه دخلت قبل خمسة أيام. فايربيس راح تقول لك انه اليوم عندك ثلاثة مستخدمين DAU بينما عندك خمسة مستخدمين MAU. أتمنى الفكرة وصلت. ركز، معليش لازم تفهمها 🤓
طيب إيش فيه مقاييس أخرى تعطيها إياك مجانا بدون أي جهد؟ فيه مقياس مهم جدا وهو ال Daily User Engagement أو ناس ثانين يسموه session duration أو مدة التفاعل اليومي أو الجلسة اليومية. باختصار: كم متوسط الوقت اللي يكون المستخدم مسنتر في التطبيق وجالس عليه كل يوم؟
يعني ما يكفي كم واحد يزورك يوميا وإنما أيضا، إذا زارك المستخدم، لمدة كم (ثانية، دقيقة، ساعة) يجلس يتصفح التطبيق؟ فايربيس تحسب الوقت ككل بحيث لو المستخدم استخدم التطبيق عدة مرات في اليوم هي تعطيك المجموع. وطبعا تعطيك في النهاية المتوسط لكل المستخدمين.
في الصورة المرفقة نلاحظ انه متوسط استعمال المستخدم اليومي للتطبيق خلال فترة ٢٨ يوم الماضية (طبعا تقدر تغير الفترة زي ما ذكرنا قبل) هو ١٠ دقايق و ٤٤ ثانية ونلاحظ انه انخفض عن فترة ال ٢٨ يوم اللي قبلها (أو الشهر الماضي) بنسبة ١.٨٪. مو بس كذا، أيضا أعلى شاشة مسنتر عليها المستخدم🤣
اذا حتى الآن عطتنا فايربيس (بدون أي جهد منا نهائيا) كم مستخدم يومي وأسبوعي وشهري للتطبيق وكذلك كم مدة استخدام التطبيق يوميا من قبل المستخدمين هذولا وما هي أكثر شاشات التطبيق جذبا للمستخدم وذلك في أي فترة أنت تختارها (عادة آخر ٢٨ يوم). طيب وش فيه بعد؟ ما خلصنا 😀
فيه مقياس آخر مهم جدا لنجاح التطبيق وبعض المستثمرين ورواد الأعمال يعتبرونه أهم مقياس (لبعض أنواع التطبيقات) وهو الريتنشن retention أو الاحتفاظ بالمستخدم والإبقاء عليه. بكل اختصار فايربس راح تحسب لك كم مستخدم يستمر في استخدام تطبيقك بعد أول مرة سواء يوميا أو اسبوعيا. كيف؟
خلوني اشرح لكم من خلال الصورة. الصورة هذي تقول لك أنه متوسط نسبة المستخدمين اللي *"يرجعون"* يستخدمون تطبيقك بعد أسبوع من تحميله للتطبيق هو ٢٥٪ وبعد اسبوعين هو ١٦٪ وبعد ثلاثة أسابيع هو ١٢.٢٪ وهكذا. فيه حاجة ثانية في الصورة برضه وهي الكوهورت cohort "المتشابهين"(ترجمتها صعبة صراحة)
فايربيس تجمع لك كل مجموعة مستخدمين حملوا التطبيق في أسبوع معين مع بعضهم كوحدة وتعتبرهم متشابهين (وجه الشبه بينهم انهم حملوا التطبيق في نفس الاسبوع) وتعطيك الريتنشن حقهم في الأسبوع الأول والثاني والثالث ... الخ. زي ما ذكرت، فيه حساب للريتنشن اليومي أيضا كما في الصورة.
خلصنا؟ لا ما راح نخلص إلا وحنا محولينك ان شاء الله من مبرمج إلى رائد أعمال 💪. فيه حاجة تعطيك إياها فايربيس اناليتكس (بالمناسبة هذي كلها في نفس لوحة التحكم أو الداشبورد) اسمها الأكويزيشن acquisition أو التملك. هذي راح تعطيك معلومات عن كيف جبت المستخدمين الجدد للتطبيق. زي أيش؟
عشان الناس تستخدم تطبيقك لازم تحمل التطبيق وعشان الناس تحمل التطبيق لازم تعرف عن التطبيق. فايربيس بتساعدك في حاجة هنا بشكل مباشر وسهل وهي كم واحد حمل التطبيق (خلال الفترة اللي أنت تختارها)؟ طيب كيف تعرفوا على التطبيق؟ هنا خلصت الأشياء السهلة وبدأت الأمور تصير أصعب شوي.
لابد تربط فايبربيس أناليتكس بأي حملة دعائية أنت تسويها. في البداية وبدون ما تسوي أي ربط، فايربيس راح تعتبر المستخدمين جايين بشكل مباشر direct. مثلا أصدقائك وأقاربك اللي أنت قلت لهم أو أصدقاؤهم (إذا هم قالوا لهم) وهكذا. خلونا ننسى فايربيس هنا شوي.
أفضل وسيلة لجذب مستخدمين جدد لتطبيقك هي ال word of mouth أو بمعنى آخر إذا الناس بدت تتكلم عن التطبيق (بدون ما تسوي أنت دعاية نهائيا). هل هذا ممكن؟ نعم ولكن صعب جدا. كل ما زاد عدد المستخدمين اللي يأتون بشكل مباشر (direct acquisition) كل ما صارت أمورك ممتازة. ليش؟ لأنهم ببلاش 😎.
ما أعرف صراحة تطبيق لم يستخدم أي دعاية نهائيا وجاه عدد عالي من المستخدمين (أتكلم ملايين) ولكن فيه تطبيقات جاها عدد عالي جدا جدا بدعاية ضئيلة جدا جدا. هذا عادة لما يكون التطبيق جذاب وباهر ويحبونه الناس وهذي صعبة جدا ولكن غير مستحيلة.
أحد طلابي في الجامعة ذكر لي قصة تطبيق كتبه لما كان في الثانوي وكان يدعم أحد الألعاب المشهورة (نسيتها) وفيه معلومات عن اللعبة. يقول رفعت التطبيق ونسيته ولما رجعت بعد أشهر لقيت أكثر من نصف مليون دانلود. كمل وحسن عليه وقدر يوصل حول المليون داونلود.
هنا ال acquisition cost أو تكلفة تملك العميل صفر وهذا شي نادر جدا. نرجع لفايربيس. فايربيس راح تعطيك: (١) كم عميل حمل التطبيق؟ و (٢) تكلفة التملك بشرط تربط الفايربيس أناليتكس بحملتك الدعائية لتحميل التطبيق (إذا كان هذا الشيء ممكن). رقم (٢) هي أول حاجة نشوفها اليوم تحتاج منك شغل
إضافة إلى كل ما سبق فإن فايربيس أناليتكس تعطيك إمكانية فلترة البيانات التي تعرضها لك حسب نوع التطبيق (ايفون أو اندرويد) لو كان عندك نسختين وكذلك نوع الجهاز ونظام التشغيل. ليس هذا فقط وإنما تسمح لك بالفلترة حسب الجنس والعمر أيضا.
أيضا إذا كان لديك عدد كافي من الزوار يمكنك معرفة الدولة والجنس والفئات العمرية لهؤلاء الزوار (هذا يتم بمساعدة قوقل والبيانات التي لديهم عن الزائر) وهذه المعلومات جاهزة بدون تعب ولكن تجدها تحت تبويب أوديانس Audiences أو الجماهير (يقصدون مستخدمي التطبيق بس هذي الترجمة الدقيقة 😅).
قبل ما ألخص ما سبق أنصحك اذا كنت أول مرة تقرأ عنه انك تقرأ الموضوع مرة ومرتين وثلاثة إلين تحفظه صم لأن المقاييس والمؤشرات هذي جدا جدا مهمة في عالم البزنس وريادة الأعمال التقني وما راح تلقى أي كورس برمجة ولا كمبيوتر يتكلم عنها
ملخص: فايربيس أناليتكس هي أداة تحليلات analytics وذكاء أعمال في منصة فايربيس تعطيك مجموعة كبيرة من الاحصائيات المهمة عن تطبيقك (مبوبة كما في الصورة). أهم الاحصائيات هي:
١- DAU عدد المستخدمين اليومي
٢-MAU عدد المستخدمين الشهري
٣- Daily user engagement طول مدة التفاعل اليومي
١- DAU عدد المستخدمين اليومي
٢-MAU عدد المستخدمين الشهري
٣- Daily user engagement طول مدة التفاعل اليومي
٤- الريتنشن retention أو معدل عودة المستخدم ويقيس القدرة على الاحتفاظ بالمستخدم
٥- اكويزيشن كوست aqcuisition cost أو تكلفة جذب مستخدم جديد وهذي تحتاج ربط مع حملتك الدعائية وإلا فستحصل على عدد المستخدمين الجدد فقط بدون معرفة التكلفة.
٥- اكويزيشن كوست aqcuisition cost أو تكلفة جذب مستخدم جديد وهذي تحتاج ربط مع حملتك الدعائية وإلا فستحصل على عدد المستخدمين الجدد فقط بدون معرفة التكلفة.
٦- تفاصيل عن المستخدمين للتطبيق Audiences (الدولة والجنس والفئات العمرية والاهتمامات) مع نسب كل نوع.
أخيرا لو كان عندك تطبيق مطور اعتمادا على تقنيات منفصلة عن فايربيس، ما زال بإمكانك الاستفادة من جزئية فايربيس أناليتكس من منصة فايربيس دون استخدام باقي الأجزاء.
أخيرا لو كان عندك تطبيق مطور اعتمادا على تقنيات منفصلة عن فايربيس، ما زال بإمكانك الاستفادة من جزئية فايربيس أناليتكس من منصة فايربيس دون استخدام باقي الأجزاء.
ماسبق هو الأشياء اللي راح تحصلها بدون جهد وتعب بمجرد استخدام فايربيس أناليتكس. نستكمل لاحقا ان شاء الله الحديث حول ما يسمى بال "أحداث" أو ال events وهي الجزء الثاني في الأناليتكس والذي يحتاج إلى شوية برمجة وكتابة كود (سهل جدا) ولكن بالمقابل يعطيك معلومات أدق وأشمل بكثير
Loading suggestions...