App Engine vs Firebase - مرحبا بكم في عالم Bizzaro

إنه عام 2018 تقريبًا ، وستبحث عن قرار لسنة جديدة. إليك بعض الأشياء الجيدة:

  • سأعترف بأنه لا يمكنني الوثوق في بيانات اعتماد المستخدم
  • سأتوقف عن كتابة تدفقات مصادقة المستخدم الخاصة بي

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

مثل معظمكم ، يجب أن أتعامل مع الأنظمة الحالية التي تحمل أوراق اعتماد و yada yada ، ما الذي ستفعله. لكن ما يمكنني فعله هو التوقف عن جعل الأمور أسوأ.

المصادقة - لا يمكن لشخص آخر القيام بذلك؟

لا يمكن لشخص آخر القيام بذلك؟

Google و Facebook و Twitter و Github ، هناك الكثير من مزودي المصادقة العامة هناك. من المعقول دعمهم جميعًا ، ولكن للقيام بذلك ، يمكنك استخدام خدمات الجهات الخارجية مثل Auth0.

في حالة مشاريع App Engine ، لدينا خيار مدمج رائع في Google Cloud Platform.

أو ، حسنًا ، تقريبًا في Google Cloud Platform. إنها موجودة في منصة Bizarro World Cloud Platform المعروفة باسم Firebase.

Firebase - محرك Bizarro App

لماذا لديك واحد من شيء عندما يمكن أن يكون لديك خيارين أو أكثر غير متوافقين بمهارة؟ تحب Google القيام بذلك ، مع أنظمة التشغيل والتطبيقات الاجتماعية والدردشة ، فلماذا لا تفعل ذلك مع الأنظمة الأساسية السحابية؟

سيتم استخدام أولئك الذين هم على دراية بتطبيق Engine لاستخدامه بطريقة قياسية من نوع خادم العميل ، أي: النظام الأساسي كخدمة:

محرك التطبيقات ، النظام الأساسي كخدمة (PAAS)

Firebase ، مثل Google Cloud Platform ، مليء بالخدمات السحابية لأنظمة البرامج المعقدة. ومع ذلك ، على عكس برنامج GCP القياسي (وخاصة محرك التطبيقات) ، فإن جذوره هي Backend كخدمة ، والتي تخرج من عالم الأجهزة المحمولة ، وتكره مطوري الأجهزة المحمولة على وجه الخصوص كتابة أنظمة النهاية الخلفية. العمارة تبدو مثل هذا:

Firebase ، Backend كخدمة (BaaS)

لاحظ أن العملاء يتحدثون مباشرة مع الخدمات في Firebase ، باستخدام SDKs الخاصة لبيئات الويب والجوال ، مع تشغيل javascript Cloud Functions (boo! ماذا عن لغة لائقة!) بواسطة تلك الخدمات بناءً على الأحداث التي تحدث في الخدمات الأخرى . لا يقوم العملاء أبدًا بالاتصال بالرمز ، ولا يمكنك إنشاء واجهات برمجة التطبيقات.

هذا على عكس App Engine ، حيث يجب عليك كتابة واجهة برمجة التطبيقات لعملائك للاتصال بهم ، ثم تتحدث إلى خدمات GCP الأخرى نيابة عن العميل.

إن الشيء الإيجابي حقًا حول بنية عالم Firebase الغريبة هو أنه يفعل بعض الأشياء بشكل أفضل. أكثر ما يلفت انتباهي هو أغراض المصادقة وتغيير الإشعارات (عبر قاعدة بيانات Firebase Authentication و Realtime Database ، على التوالي).

Firebase + App Engine - بنية Cat Dog

الأمر الصعب هو أنه على الرغم من أن تطبيق Engine و Firebase لا يتنازعان حقًا مثل Superman و Bizzaro ، إلا أنهما لا يربطانهما بسهولة خاصة. إنه كلب صغير. دعونا نلقي نظرة على الهندسة المعمارية:

Firebase + AppEngine - Cat Cat as a Service (CDaaS)

هذه هي البنية الأساسية التي سأنشرها في الكود التالي من المقالات. الأساسيات هي:

1 - سيقوم العميل بالتصديق عبر مصادقة Firebase.

2 - سيكون بعد ذلك رمز مصادقة لاستخدامه عند التحدث إلى App Engine.

3 - عندما تحدث أحداث مهمة في App Engine نريد أن يعرفها العميل ، فسوف ندفع المعلومات إلى Firebase Realtime Database.

4 - ستدفع قاعدة بيانات Firebase Realtime Database التغييرات إلى العميل. يمكن للعميل أيضا الاستعلام عن قاعدة البيانات في الوقت الحقيقي على النحو المرغوب فيه.

ستلاحظ أني ألغيت وظائف السحاب من الصورة ؛ لن نستخدمها هنا. أريد أن لا يزال هذا الإعداد يبدو وكأنه تطبيق App Engine بسيط يستند إلى Python ، لذلك دعونا لا ندخل في كتابة javascript لـ node.js.

لاحظ أيضًا أننا لن نضع الكثير في قاعدة البيانات الفعلية ؛ انها مكلفة (5 دولارات / غيغابايت!). سنستخدمها فقط لإشعارات التغيير ، ونضع بيانات حقيقية في Cloud Datastore.

ماذا بعد؟

في المقالة التالية ، سنتطرق إلى الشفرة الفعلية ، حيث أتناول الخطوتين 1 و 2 أعلاه ، باستخدام FirebaseUI. سننتهي بهيكل هيكلي مفيد يتعامل مع تسجيل الدخول / الخروج في تطبيق ويب من صفحة واحدة باستخدام مصادقة Firebase ، ونتحدث على الأرجح إلى النهاية الخلفية لـ Python Flask.

سيناريو المشاركة: وماذا عن Cloud Firestore؟

لقد تركت الحرارة الساخنة ، Cloud Firestore. بينما أنا مفتون به ، لا يمكنني معرفة كيفية استخدامه.

Firebase’s Cloud Firestore هو مخزن البيانات السحابي في GCP (أي: Megastore) ، مع بعض التغييرات الرائعة جدًا:

  • إنه أبسط ؛ لا هياكل مفتاح غامضة ، لا فئات ، مجرد مجموعة بسيطة + هياكل البند
  • لديها إشعارات في الوقت الفعلي للعملاء ، مثل Firebase's Realtime Database
  • إنه مقياس مثل Cloud Datastore.

لسوء الحظ ، هناك بعض العيوب أيضًا:

  • يفتقد إلى بعض من قوة المعاملات في Cloud Datastore.
  • عندما تستخدم Cloud Firestore في تطبيق App Engine ، لا يمكنك استخدام Cloud Datastore
  • يتطلب التخصيص استخدام وظائف السحاب (وحتى مع ذلك ، لا تتمتع بقدرة ، على سبيل المثال ، معالج تم وضعه مسبقًا على فئة طراز ndb). يمكنك كتابة وظيفة سحابة عامة تمر فقط إلى تطبيق appthine بيثون أفترض.

لكن العائق الأكبر بالنسبة لي هو أنه نظرًا لأنه جزء من Firebase ، فإن البنية تبدو كما يلي:

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

أنا أفهم لماذا يريد أن يعمل بهذه الطريقة ؛ عند القيام بهذه الطريقة ، يمكنك القيام بإعلامات تغيير الوقت الفعلي للعملاء بشكل صحيح ، والتكامل مع بقية Firebase أفضل. لكنني لا أرى كيف تصمم تطبيقًا خطيرًا بالفعل في هذا التكوين ، وإذا كنت لا ترغب في إنشاء شيء خطير ، فكيف ستستفيد من حل يستند إلى megastore (وهو أمر مفيد للغاية قوية ، ولكن يتطلب معالجة متأنية)؟

في المستندات ، من الواضح أن مكتبات الويب (جافا سكريبت بجانب المتصفح) و Android و iOS هم المواطنون من الدرجة الأولى ، وأن بيئات جانب الخادم هم مواطنون من الدرجة الثانية. تتطلب Python مكتبة firebase-admin والتي تعد بمثابة أحد الأوغاد للحصول على تطبيق Engine (رغم أن هذه مشكلة في خدمات firebase الأخرى أيضًا).