Thread by @muath2

بمناسبة اليوم الوطني راح أهديكم سلسلة تغريدات ألخص فيها تجربتي مع منصة #فايربيس @Firebase
فايربيس هي منصة للمبرمجين وخصوصا مطوري التطبيقات تملكها قوقل @Google وهذا رابط المنصة firebase.google.com

لماذا فايربيس؟ فايربيس عبارة عن منصة باكاند backend متكاملة توفر لمطوري التطبيقات عدة خدمات على رأسها ١) ادارة المستخدمين firebase authentication و ٢) قاعدة بيانات #فايرستور #Firestore و ٣) تحليلات فايربيس اناليتكس firebase analytics لتحليل سلوك مستخدمي التطبيق

ايش يفرق فايربيس عن خدمات أخرى مثل قوقل كلاود او أمازون كلاود او غيرها؟
الفرق الرئيسي والأساسي هو انك تحصل على الباكاند من فايربيس كخدمة backend as a service او #BaaS بدون ما تكتب ولا سطر كود خارج تطبيقك. هذا لا يعني انك راح تستغني بشكل كامل عن كتابة كود باكاند زي ما راح نشوف

بعبارة أخرى: بالطريقة التقليدية وبدون استخدام فايربيس، راح تحتاج تستأجر سيرفر أو أكثر في الكلاود عشان تركب فيه الداتابيز وكذلك الباكاند سيرفس اللي تحتاجها وراح تكتب كود باكاند سواء باستخدام Java او PHP او Python او NodeJS او .NET او غيرها

طبعا كمطور تطبيق وكون معظم خبرتك هي في تطوير التطبيقات سواء باستخدام Swift للايفون او Java للاندرويد، الطريقة التقليدية راح تكون متعبة لك لانك ستضطر اما لتعلم كيفية برمجة سيرفس في الباكاند او تطلب من غيرك يساعدك في هالشي.

بالمقابل في فايربيس النموذج فريد من نوعه ومختلف حيث توفر لك خدمات الباكاند الرئيسية بشكل جاهز وتوفر لك مكتبة جاهزة client SDK (للاندرويد والايفون) تمكنك من الاستفادة من هذه الخدمات مباشرة. ليس فقط هذا ولكن توفر لك ميزات عديدة في هذه الخدمات والتي سأتحدث عنها في بقية التغريدات

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

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

خلونا نبدأ ب firebase authentication firebase.google.com/docs/auth أو خدمة توثيق المستخدمين. تساعدك هذه الخدمة على بناء جزئية ادارة المستخدمين في موقعك أو تطبيقك وتختصر عليك الكثير في هذا الجانب حيث يمكنك أن توفر لمستخدمي التطبيق امكانية التسجيل و تسجيل الدخول بعدة طرق.

من هذه الطرق ١) تسجيل الدخول بالإيميل والباسوورد ٢) تسجيل الدخول الموحد single sign on باستخدام ما يسمى بالهوية الفيدرالية federated identity من قوقل أو فيسبوك أو تويتر بحيث يسجل المستخدم في تطبيقك باستخدام حسابه في قوقل مثلا

٣) باستخدام رقم التلفون مع pin code في رسالة نصية حيث توفر لك فايربيس ١٠ آلاف رسالة SMS شهريا مجانا.

طريقة البرمجة: تقوم بكتابة الكود الخاص فيك في التطبيق باستخدام ال client SDK من فايربيس والتي بدورها تتواصل اوتوماتيكيا مع فايربيس لعمل ال authentication.

يمكنك اختصار الموضوع أكثر باستخدام ال client UI الجاهزة من فايربيس والتي توفر لك كود جاهز لواجهات تسجيل المستخدم الجديد وتسجيل الدخول في تطبيقك أو موقعك.
عند تسجيل الدخول توفر لك فايربيس اوتوماتيكيا من خلال ال SDK اوبجيكت يمثل المستخدم بكل خصائصه.

يمكنك اضافة خصائص جديدة للأوبجيكت تخص المستخدم مثل رابط لصورة البروفايل.
لتسهيل ادارة صلاحيات المستخدمين access control يمكنك استخدام ما يسمى بال claims. مثلا يمكن اضافة خاصية admin يحث اذا كان المستخدم أدمن تكون هذه الخاصية true ويمكنك وضع levels of access لصلاحيات الأدمن.

ماذا يميز فايربيس عن الطريقة التقليدية في هذه الناحية؟
١) جزئية الباكند مبرمجة لك بالكامل بحيث لا تقلق في قضية ادارة ال session وال tokens أو التواصل باستخدام بروتوكول OAuth.

٢) الباكند مبرمجة لك بمعايير أمن سيبراني عالية جدا دون التأثير على سهولة التكامل معها. فمثلا يتم آليا عمل hash لكلمات السر كما يتم استخدام معايير عالية في ادارة ال tokens باستخدام JWT. هذا يتم بدون تدخلك وذلك من خلال التواصل بين ال Client SDK وبين الباكند في فايربيس اوتوماتيكيا.

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

٤) توفر لك فايربيس خدمة التأكد من إمتلاك المستخدم للإيميل الذي سجل باستخدامه من خلال ارسال ايميل تحقق كما توفر لك امكانية ارسال إيميل لعمل reset للحساب عند نسيان المستخدم الباسوورد.
٥) يمكنك عمل تسجيل مؤقت للمستخدم anonymous login بحيث لا تفقد بيانات المستخدم بين زيارة وأخرى

الآن نأتي للجزء الأهم والأكثر متعة وإبداعا وإبهارا بالنسبة لي في فايربيس ولا أعلم إذا كان هناك من سبقهم إلى هذه الفكرة.
أي شخص برمج تطبيقات أو مواقع سابقا سيسأل السؤال التالي: كيف يمكن تأمين الوصول للموارد في الباكاند وخصوصا تأمين الوصول لقاعدة البيانات من الكلاينت مباشرة؟

دعوني أولا أشرح كيف يتم ذلك في الطريقة التقليدية كالتالي: عادة يكون هناك اتصال بين كود الباكاند، ولنفرض ان الكود مكتوب باستخدام PHP، وبين قاعدة البيانات ويكون الاتصال مؤمن باستخدام كلمة سر. مثلا عند اتصال كود PHP بقاعدة بيانات MySQL فإن ذلك يتم باستخدام كلمة سر مخزنة في مكان ما.

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

في فايربيس لا يوجد كود باكاند (في الحقيقة توجد تقنية الكلاود فنكشن والتي سنستعرضها لاحقا ولكن لن نتطرق لها الآن) فكيف يمكن حماية الوصول لقاعدتي البيانات في منصة فايربيس وهما Firestore و/أو Realtime Database أو الملفات والصور في Cloud storage. هذا يتم من خلال ال security rules.

قامت قوقل بعمل لغة متكاملة بسيطة لكتابة قواعد أمنية security rules firebase.google.com/docs/rules لحماية قاعدة البيانات وهذه القواعد يقوم المبرمج بكتابتها. أكبر خطر أمني أحذر منه وأعتقد بانتشاره، خصوصا أني قرأت بحث مؤخرا بهذا الصدد، هو إهمالك وعدم فهمك وكتابتك لهذه القواعد الأمنية

من عبقرية وجمال تصميم فايربيس أن سمحت لكود التطبيق بعمل استعلام query مباشرة على الداتابيس. ولكن حتى تحمي الوصول الغير الآمن للبيانات طلبت من المبرمج كتابة قواعد أمنية تحدد متى يتم السماح بتنفيذ الاستعلام ومتى يتم الرفض.

على الرغم من أني لم أشرح حتى الآن طريقة عمل قاعدة بيانات فايرستور دعوني أشرح لكم باختصار كيف يمكن تأمين الاستعلام التالي: profile.userId.get(); هذا الاستعلام يقوم بقراءة بيانات بروفايل أحد المستخدمين. لنفترض أنه يسمح للمستخدم فقط بقراءة بيانات البروفايل الخاص به.

في هذه الحالية يجب عليك وضع قاعدة أمنية تمنع القراءة إلا في حالة واحدة فقط وهي مطابقة ال userId الموجود في ال firebase authentication token مع ال userId في قاعدة البيانات. هنا نلاحظ الرابط بين خدمة firebase authentication وبين تأمين القراءة المباشرة من التطبيق لقاعدة البيانات

الكثير على ما يبدو يقع في خطأ أمني خطير جدا 😣حيث يظن أن استخدام ال API key من فايربيس، الموجود في ملف ال google-config.plist في تطبيقات الايفون مثلا، كافي لتأمين الوصول لقاعدة البيانات ولكن في الحقيقة هذا المفتاح هو مفتاح للتعريف فقط وليس للتأمين.

يمكن الحصول على هذا المفتاح بسهولة عبر عمل هندسة عكسية للتطبيق. الحل الصحيح والوحيد الآمن هو بكتابة القواعد الأمنية كما ذكرت. كما أود التنبيه إلى أن القواعد الأمنية تقوم بتأمين الوصول حتى مستوى معين في قاعدة البيانات وهو ال document حيث أنها أصغر وحدة يمكن التحكم بالوصول لها

هذه الجزئية أقل حدوثا من سابقتها ولكنها أكثر صعوبة في الفهم والانتباه لها. مثلا: لو كنت تبرمج شبكة اجتماعية وأعطيت أي مستخدم امكانية قراءة البروفايل لأي مستخدم آخر وفي نفس الوقت قمت بتخزين معلومة سرية مثل رقم الهاتف في هذا البروفايل فيجب عليك فصل معلومات البروفايل عند التخزين.

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

أخيرا، كيف تعمل القواعد الأمنية security rules 🧐؟ خلف الكواليس تقوم فايربيس في جزئية الباكاند أوتوماتيكيا بمراجعة كل عملية استعلام تتم من قبل التطبيق ومقارنتها بكافة القواعد الأمنية المكتوبة وفي حال نجحت المطابقة ترد فايربيس بنتيجة الاستعلام أما في حال الفشل فترد برسالة خطأ أمني

البديل: قبل أن ننهي حديثنا اليوم عن ال firebase authentication أود الاشارة إلى وجود بدائل لعمل ال authentication as a service ويبدو لي أن أشهرها هو auth0.com علما أني لم أقم بتجربته من قبل. يتميز هذا البديل باستقلاليته حيث يمكن استخدامه مع أي خدمة خارج منصة فايربيس.

هذا لا يعني أنه لا يمكن استخدام firebase authentication مع خدمات أخرى خارج منصة فايربيس ولكن قد تكون أصعب. بالمقابل فهناك عيوب ل auth0 أهمها ١- غلاء السعر مقارنة بفايربيس ٢- كونه خدمة تغطي جانب معين فقط مقابل منصة فايربيس المتكاملة. نكتفي بهذا القدر اليوم ونكمل لاحقا بمشيئة الله

اليوم نستكمل حديثنا عن فايربيس حيث نستعرض قواعد البيانات التي توفرها فايربيس وهي فايرستور #firestore firebase.google.com/docs/firestore وهي الأحدث و ريل تايم داتابيز #realtimeDB firebase.google.com/docs/database وهي الأقدم

كلا الخدمتين تصنفان ك #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/wiki/ACID

اذا كانت قواعد البيانات العلائقية توفر كل هذا (لغة استعلام سهلة الاستخدام وضمانات قوية لتخزين البيانات) فلماذا نتخلى عنها ونبحث عن غيرها؟ ولماذا لا توفر فايربيس قاعدة بيانات علائقية؟ وهل يعني هذا أنه لا يمكنني بناء نظام بنكي باستخدام قاعدة بيانات فايربيس المسماة Firestore؟ 😰

١) سرعة التوسع. تعاني قواعد البيانات العلائقية من مشاكل كبيرة جدا عند توسع التطبيق وازدياد عدد المستخدمين (وبالتالي حجم البيانات) لملايين أو عشرات الملايين. هنا ستضطر إلى شراء أجهزة ضخمة غالية الثمن واستخدام تقنيات ال caching وهذه مشكلتها أنها لا تنمو بسهولة

بعبارة أخرى، عند استخدام SQL DB فإنه يصعب عليك التوسع الأفقي horizontal scaling بحيث لا يمكنك شراء المزيد والمزيد من أجهزة الكمبيوتر العادية لدعم توسعك، بل تحتاج زيادة قوة الأجهزة نفسها. لتتوسع بسرعة فإن هذه الطريقة التقليدية لحفظ البيانات لا تنفع ولا بد من طريقة مختلفة.

لئن كانت السرعة هي المشكلة الرئيسية فهي ليست المشكلة الوحيدة. هناك مشكلة أخرى وهي ٢) الحاجة لعمليات تتم في الزمن الحقيقي أو realtime read and write. كمثال على ذلك: لو كان هناك محادثة فلا بد أن يتم تخزين الرسائل من قبل الطرف الأول وقراءتها من قبل الطرف الثاني مباشرة دون أي تأخير.

لحل هذه المشاكل، هناك في الحقيقة عدة طرق وليست طريقة واحدة وبالتالي عدة أنواع جديدة وليس نوع واحد لقواعد البيانات والتي تصنف كلها تحت تصنيف #NoSQL en.wikipedia.org/wiki/NoSQL وهو تصنيف جامع لكافة أنواع قواعد البيانات التي تشترك فيما بينها أنها ليست 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 داخل دوكيومنت المطعم. (الصور من فيديو الشرح الرائع من قوقل )

لاحظوا من البداية كيف ظهر لنا أكثر من طريقة لترتيب هيكلة البيانات data structure داخل قاعدة بيانات فايرستور. هذا على العكس من لو كنت تستخدم SQL DB واللي غالبا تصل فيها لستركتشر معين بعد ما تسوي normalization للبيانات.

فهم كيفية هيكلة البيانات داخل فايرستور (وكثير من قواعد البيانات ال #NoSQL ) والتعمق فيه والتدرب عليه أمر جوهري وأساسي. ليش؟ 🤔

السبب هو انك بعد ما تخزن البيانات تحتاج تقرأها فيما بعد وتعرضها للمستخدم، وعشان تقرأ البيانات لابد تستخدم استعلامات queries. في فايرستور لا تستطيع استخدام لغة الاستعلام SQL (أكيد طبعا) ولكن هناك لغة خاصة query language تأتي مع ال firestore SDK firebase.google.com/docs/firestore….

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

لماذا هي كذلك؟ لا أعلم حقيقة وهو لغز بالنسبة لي (لعل أحد من قوقل أو من خبراء قواعد البيانات يشرح لنا) ولكني سأتكلم عن ١) متى تكون هذه المشكلة كافية لترك فايرستور (وليس فايربيس) و ٢) متى تكون غير كافية وما هي الخيارات الموجودة في هذه الحالة لتجاوز هذه المشكلة وكيفية التعامل معها.

مشكلة الاستعلام في فايرستور (على الأقل ما رأيته في تجربتي حتى الآن) هي في ١) عدم وجود or وعدم وجود نفي في لغة الاستعلام في حال استعلمت على حقلين أو أكثر داخل الدوكيومنت و ٢) عدم وجود like (للبحث المبسط في النصوص) ٣) ضعف التجميعات أو aggregations .

مثلا في رقم واحد لا تستطيع تستعلم عن كافة المطاعم التي صنفها ليس "إيطالي". في رقم ثلاثة لا تستطيع معرفة عدد المطاعم التي صفنها "إيطالي".
ما هو الحل؟ ١) اختيار هيكل بيانات مناسب. مثلا أن يكون لديك إلى جوار الكوليكشن الرئيسي مجموعة من الكوليكشنز الأخرى بحيث لكل صنف كوليكشن.

كذلك أن يكون لديك عداد في مكان ما يكون فيه عدد المطاعم من كل صنف. ماذا لو احتجت عد المطاعم بناء على معيار آخر؟ تبني عداد آخر 😅.
فايرستور انتبهت لهذا الشيء ولذلك أ- صممت قاعدة البيانات بحيث لا تحتاج إلى مخطط او schema على عكس الوضع في SQL DB.

ليس هذا فقط وإنما ب- أضافت فايرستور call back cloud functions وهي عبارة عن أكواد جافاسكربت و nodejs يتم تشغيلها عند كل عملية على كوليكشكن معين. عارف ان الموضوع بدأ يتشعب ولكن ضروري نستعرض الشيئين هذولي

أ- كون قاعدة البيانات schemaless يساعدك كثيرا على تعديل البيانات تبعا لحاجة البزنس في التطبيق. لا يوجد أي مشكلة في فايربيس من أن تكون الحقول متفاوتة بين الدوكيومنتس في نفس الكوليكشن. مثلا بعد فترة أدركت الحاجة لوجود الموقع للمطعم GPS location.

في هذه الحالة بكل بساطة تضيف حقل جديد على الدوكيومنتس الجديدة دون التأثير على الموجودة حاليا بشرط أن يكون الكود لديك متوافق مع النوعين. يمكن أيضا الاستعلام على هذا الحقل بدون مشاكل. هذا الشيء لا يعالج مشكلة ضعف الاستعلام (جزئيا) فقط بل يسمح لك بالتغيير السريع في الكود.

كثيرا ما نسمع عن أهمية سرعة اختبار البزنس والتغيير حسب الحاجة في الشركات الناشئة وهنا راح تستفيد كثير من هذه المرونة في فايرستور.
ب- كون وجود كلاود فنكشن أو كود يعمل اوتوماتيكيا في الفايربيس عند كل عملية تتم على دوكيومنت معينة أم عظيم.

بكل بساطة خل عندك كوليكشن رئيسي لكل المطاعم ومجوعة كوليكشنز بحيث لكل صنف كوليكشن واكتب كلاود فنكشن تقوم بتحديث أي مطعم في أي واحد من الكوليكشنز هذي عندما يتم تحديث المطعم في الكوليكشن الرئيسي (أو اضافة أو حذف). لفة طويلة ولكن ناجحة 🤣

هذا الأسلوب هو بالضبط ما تكلمت عنه سابقا وهو ال denormalization للبيانات. ليس هذا فقط ولكن تم دمجه مع مايكرو سيرفس microservice. لإن كان استخدام التقنيتين هنا حاجة غريبة (للتغلب على ضعف الاستعلام) فإنك راح تضطر إليه رغما عنك لما توصل عدد كبير من المستخدمين.

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

قبل نروح لرقم ٢ أشير أن كثير من قواعد البيانات ال #nosql ترمي جزء لا بأس به من موضوع ادارة البيانات وهيكلتها على المبرمج لتقدم لك بعض الضمانات وعلى رأسها عادة السرعة في العمل والتوسع الأفقي.
ولكن مازلت أعتقد أنه من الممكن أن تكون خيارات الاستعلام أفضل في فايرستور. لماذا؟

لأن المنافس الرئيسي في نظري لفايرستور هو #mongoDB فهي تعمل بطريقة مشابهة إلى حد ما ولكن توفر لغة استعلام أغنى بكثير. صحيح أن فايرستور تضمن لك توسع أفقي لا محدود دون الاخلال بالسرعة ولكن ما فائدة السرعة عند التوسع لتطبيقك اذا كنت غير قادر على توفير الخدمات للزبون في البداية؟

ليس هذا فقط، بل إن mongoDB توفر حاليا منصة اسمها stitch mongodb.com/cloud/stitch وهي حسب فهمي تنافس فايربيس كمنصة وليس فايرستور فقط وتضمن التوسع الافقي اللامحدود (وإن كنت لم أستخدمها حتى أقيمها).

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

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

نكمل حديثنا اليوم حول فايرستور وكيفية التعامل مع النقص الموجود في لغة الاستعلام. ذكرنا في الحل الأول فكرة تكرار الكتابة denormalization وهي فكرة ممتازة جدا في كثير من الأحيان خصوصا في ظل امكانية ربط الكلاود فنكشنز cloud functions (راح نشرحها لاحقا باذن الله) بفايرستور.

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

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

بعض الأمثلة لذلك woocommerce في التجارة الالكترونية woocommerce.com/?utm_source=ad… و odoo او erpnext في مجال ادارة موارد الشركات erpnext.com odoo.com وغيرها. هذه توفر لك واجهة برمجية API لتربط معها تطبيقك مع باكاند متكاملة مخصصة للخدمة نفسها.

هنا يتعدى الموضوع قاعدة بيانات فايرستور حيث أنك قد لا تحتاج لفايربيس نهائيا أو قد تحتاج خدمة أو خدمتين من فايربيس مثل cloud messaging و analytics (راح نتكلم عنهم لاحقا).
ماذا لو كان تطبيقك فريد من نوعه ويقدم خدمة جديدة أو يقدم نفس الخدمات السابقة ولكن بطريقة جديدة ومختلفة كليا؟

هنا نأتي لمرحلة التقييم الثانية وهي مدى حاجتك للاستعلام والفلترة المعقدة؟ هل تحتاجها داخل التطبيق وضمن وظائفه أو تحتاجها لعمل تحليل للبيانات analytics؟
اذا كنت تحتاجها ضمن وظائف التطبيق وكانت الطريقة الأولى denormalization غير مقبولة نهائيا أو غير مفهومة فهنا أمامك خيارين.

أ) استخدام قاعدة بيانات بديلة غير فايرستور مثل مونقو دي بي أو ماي سيكول وستكون هذه خارج نطاق منصة فايربيس مع الاستفادة من خدمات فايربيس الأخرى (وهي في نظري متعددة ورائعة ومغرية).
ب) استخدام قاعدة بيانات مساندة لفايرستور واستخدام الكلاود فنكشن لعمل ال 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/bigquery/ من شركة قوقل مع google data studio datastudio.google.com/overview

تعتبر #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) اذا عندك تطبيق معتاد ومعمول مثله الكثير من قبل مثل المتجر الالكتروني.

٢) استمر في استخدام فايربيس وخدماتها المتعددة ولكن استخدم قاعدة بيانات بديلة لفايرستور
٣) استخدم قاعدة بيانات مساندة لفايرستور وانا أرشح elasticsearch للبحث والفلترة باستخدام خدمة appbase.io و bigqyery مع قوقل ستوديو للتحليلات analytics>

بين الحلول السابقة كلها فاختياري هو Firestore + Elasticsearc + bigquery في حالة كان لديك تطبيق فريد من نوعه أما في حال تريد عمل شي معروف مسبقا فلا تعد اختراع العجلة أصلا.

ملاحظات أخيرة بخصوص فايرستور:
١- فايرستور تحاسبك 💸 ب (١) حجم البيانات المخزنة + (٢) عدد مرات القراءة والكتابة وهي عادة التكلفة الأكبر + (٣) حجم الباندويدث (البيانات) الخارج للزوار أو مستخدمي التطبيق. firebase.google.com/pricing#blaze-… يمكنك البدء مجانا حتى حد معين (سخي) حسب الشرح في الرابط

يمكنك أيضا وضع حد معين للفاتورة (بحيث يتوقف عمل فايرستور عند هذا الحد وهو طبعا أفضل من فاتورة فلكية 😰) cloud.google.com/firestore/pric… وأعتقد أن هذا شيء مهم جدا حتى ما تجيب العيد. غالبا التكلفة اذا ارتفعت فستكون من كثرة عمليات القراءة أو الكتابة في الكود فيجب الانتباه لذلك.

٢- يمكنك عمل نسخ احتياطي لفايرستور ويوجد شرح كامل لذلك من قبل قوقل firebase.google.com/docs/firestore… الحل ليس بالسهولة المطلوبة ولا أعلم لماذا ولكنه على الأقل موجود.

٣- يمكنك تصفح البيانات في فايرستور من خلال ال console الخاص بفايربيس ولكن للأسف لا يمكنك عمل export و import من خلاله (مثلا عند رغبتك في نقل بيانات من قاعدة بيانات لأخرى). عموما ادارة قاعدة بيانات في فايرستور عن طريق ال console ينقصها تحسينات عدة أتمنى تعملها قوقل.

٤- فايرستور توفر خدمة realtime synchronization ضمن كافة استعلاماتها (بمعنى الاستعلام لا يقرأ البيانات مرة واحدة فقط بل بشكل مستمر أوتوماتيكيا عند كل تغيير) وهذه خدمة مهمة لبعض التطبيقات خصوصا الألعاب بالدرجة الأولى (وان كانت ال realtime DB أفضل في هذا المجال) وكذلك السوشال ميديا

الملخص أن فايرستور لها مستقبل كبير لو استمرت قوقل بالاهتمام بها وحل المشاكل التي ذكرتها. نكمل لاحقا ان شاء الله عن realtime DB ومن ثم بقية الخدمات في منصة فايربيس.

نكمل اليوم حديثنا عن منصة فايربيس وراح يكون الموضوع عن الكلاود فنكشنز (راح نؤجل الحديث عن reatime DB لوقت لاحق). مثل ما كان حديثنا عن فايرستور عني بكثير من التفاصيل الممتعة، نفس الشي حديثنا عن الكلاود فنكشنز راح يكون غني بالكثير من التفاصيل الممتعة.

خلونا نبدأ أولا بإجابة السؤال التالي: بما أن الكلاود فنكشنز cloud functions هي باكاند هل كمطور تطبيقات أصلا أحتاجها؟
غالبا لن تكون بحاجة إلى الكلاود الفنكشنز خصوصا في بداية تطوير التطبيق. ولكن سيأتي عليك وقت ستضطر فيه إلى كتابة كلاود فنكشنز وذلك لسببين رئيسيين.

١- ستحتاج إلى كتابة كلاود فنكشنز لتساعدك في عمل ال denormalization للبيانات في قاعدة بيانات فايرستور كما شرحنا سابقا خصوصا عندما تكبر قاعدة البيانات وتتشعب.

٢- ستحتاج إلى كتابة كلاود فنكشنز كباكاند لتقديم بعض الخدمات التي يصعب جدا (وقد يستحيل) تقديمها من خلال كود التطبيق فقط دون الاخلال بأمن تطبيقك 😅 أو كنت تحتاج التواصل مع خدمات أخرى 3rd party خارج منصة فايربيس (دفع الكتروني مثلا).

بغض النظر أنت مطور تطبيق أو لا، خلونا نشرح التقنية وكيفية استخدامها سواء كنت مطور تطبيق أو شغوف بالتقنيات الجديدة في تطوير الباكاند والمعتمدة على مبادئ microservices و serverless خصوصا وأن الكلاود فنكشنز يمكن استخدامها مستقلة من خلال منصة google cloud الأخ الأكبر لمنصة فايربيس.

عشان أقرب لك فكرة الكلاود فنكشنز firebase.google.com/docs/functions تخيل ان عندك صديق فاهم مرة في السيرفرات وادارة السيرفرات على الكلاود وكيف يركب nodejs وكيف يركب ويب سيرفر زي nginx أو apache مثلا ويشغلها ويسوي لها تحديث كل ما نزل تحديث.

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

مثلا تبغى تكتب كود مهمته ياخذ أي صورة يرفعها المستخدم ويسوي منها نسخة مصغرة thumbnail. بغض النظر عن باقي الكود في الباكاند، تكتب فنكشن وحدة تسميها مثلا generateThumbnail بحيث تقرأ الصورة من مكان محدد (مثلا google storage) وتصغرها وترجع تخزنها. بس هذا الشي الوحيد اللي تسويه.

بعد ما تخلص تعطي خويك الكود وهو يتولى الباقي 😀. لاحظ معي انك راح تستفيد حاجتين:
١- بعد فترة راح تلاحظ ان مشروعك عبارة عن مجوعة من الفنكشنز (أو الخدمات الصغيرة microservices) كل وحدة تؤدي غرض معين بشكل مستقل عن بقية الفنكشنز مما يسهل الكتابة والصيانة.

٢- باستخدام هذه الطريقة في التطوير بامكانك تشغيل فنكشن معينة بشكل منفصل عن الآخرى بحيث لو الفنكشن هذي صار عليها ضغط فإنك تسوي scale لها وحدها بدون ما تتأثر بقية الفنكشنز. هذا يساعد في سهولة وقلة تكلفة ال scalability أو التوسع السريع في تنفيذ الكود.

صراحة الطريقة سهلة جدا (ومجانية لحد معين) لدرجة انه يمديك الآن (بشرط تعرف شوي جافاسكربت) انك خلال نصف ساعة تكتب كود باكاند متكامل وترفعه وتجربه وتطفيه بدون سيرفرات أو دومين أو تركيب ويب سيرفر أو معرفة بلنكس أو غيرها من الأمور. هنا تجد مثال متكامل firebase.google.com/docs/functions…