قصة ولادة خدمة البحث والحجز عبر الإنترنت لسفر حقوق الطبع والنشر حول العالم: كلمة من المطور

كيف بدأ كل شيء
عذاب مثالي
التقنيات وكيف أنها ليست فريدة من نوعها
كيف تخزن وأين؟
ليس فقط للتخزين ، ولكن أيضا للبحث
هذا هو SEO المشفر
كندي كل شيء لدينا
لتلخيص

كيف بدأ كل شيء

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

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

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

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

عذاب مثالي

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

في البداية ، لم تكن أمتعة التقنيات التي لدينا كانت مسجلاً للغاية و C # (التي استخدمناها في مشاريعنا السابقة). لم تسمح لنا هذه الأدوات بمواجهة التحديات بسرعة ومرونة. لحسن الحظ ، لقد أخذنا في الاعتبار بالفعل مناهج جديدة لكل من تطوير الخادم والعميل. وقع اختيارنا على Angular 2 و Node.js. سمح لنا هذا الحل بتشكيل المكونات والوحدات التي يمكننا تعديلها بسرعة في أقصر وقت ممكن (في اليوم الذي يمكننا فيه إعادتها مرتين أو ثلاث مرات).

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

ولكن إذا اكتشفنا الأدوات بسرعة كافية وفي المعركة ضاعفت مهاراتنا أكثر فأكثر (سألاحظ Google على الفور لمساعدتك ، ولكن لا تنسى مقاطع الفيديو التعليمية) ، عندها ظهر سؤال آخر حول مكان تخزين البيانات. لكن سأتحدث عن هذا بعد ذلك بقليل ، وأعود الآن إلى الفكرة نفسها.

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

ما هذا؟

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

التقنيات وكيف أنها ليست فريدة من نوعها

كيف تخزن وأين؟

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

وهكذا ، في عملية البحث ، تم العثور على حل يغطي جميع متطلباتنا ، كان قاعدة بيانات Firebase Realtime. ساعدتنا هذه الخدمة على حل مشكلات تخزين البيانات ، والاستضافة ، وخدمة المصادقة ، والتخزين لتخزين البيانات الثابتة. بالإضافة إلى ذلك ، فإن هذه الخدمة تحت جناح Google ، والتي أعطتنا بدورها مكافآت رائعة ، حيث قدمت مكتبات منفصلة للعمل مع Angular 2 وكانت مريحة وسريعة. لكن أروع شيء لدينا هو قاعدة بيانات RealTime خارج الصندوق. كانت أحاسيسنا الأولى رائعة ببساطة.

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

ليس فقط للتخزين ، ولكن أيضا للبحث

وهكذا ، بمجرد أن أصبح الإصدار التجريبي الأول جاهزًا ، ظهر السؤال في تصفية البيانات ، وأدركنا العيوب الأولى في Firebase. كما اتضح ، فإن عملية أخذ عينات البيانات لعدد كبير من الشروط غير مدعومة ببساطة. من الممكن تحديد البيانات بشرط واحد فقط ، أو جمع عدة قيم في حقل واحد ثم التصفية عليها. لم يناسبنا هذا النهج ، وبدأنا مرة أخرى في البحث عن حل.
بالطبع ، لم نرفض Firebase ، نظرًا لأن هذا السالب لم يتداخل مع مجموعة المزايا التي توفرها هذه الخدمة. لحسن الحظ ، كانت لدينا تجربة استخدام Google Big Query ، والتي حصلنا عليها في عملية البحث ، وقررنا تطبيقها. الميزة الأولى هي أنها Google ، والثانية - استعلامات SQL الأصلية والمفضلة والتكلفة المنخفضة لامتلاك 1 تيرابايت من البيانات شهريًا مجانًا.

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

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

لم يكن لدينا الوقت للاسترخاء والاستمرار بهدوء في إنشاء خدمتنا عندما بدأ اختبار مجموعة التركيز ، وأدركنا أن المستخدمين معتادون على تبديل الفلاتر بسرعة كبيرة ويريدون رؤية نتيجة عملهم على الفور. أجبرتنا هذه المتطلبات على التخلي عن Big Query والبحث عن شيء جديد. نظرًا لأن Big Query أعطانا سرعة استجابة بحد أقصى 2 ثانية ، وهذا بحد أدنى من البيانات. هنا ، بالطبع ، لا يوجد شيء يمكن إلقاء اللوم عليهم فيه ، لأن هذه الخدمة مخصصة لمعالجة كميات كبيرة من المعلومات ، وليس للرد السريع على مجموعة من الطلبات المتتالية.

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

هذا هو SEO المشفر

والآن يتم تشغيل الخدمة ، ويتم تطوير المنصات ويبدو أن كل شيء على ما يرام ، ونحن نسعى جاهدين من أجل مستقبل مشرق. ولكن هذا يثير قضية تعزيز خدمتنا وقضية تحسين محركات البحث الرئيسية. لم أفكر أبدًا في أن هذا السؤال قد لا يتم وضعه في الاعتبار من قِبل منشئي Angular. كما اتضح ، تطبيق الصفحة الواحدة ضعيف جدًا في توفير هذه الميزة ، ولأكون صريحًا ، فهو ليس كذلك على الإطلاق. نعم ، يمكنك خياطة البيانات الثابتة في العلامات الوصفية وعندما تتجاوز Crowl أو عندما تقدم المشاركة نفس المعلومات ، حسنًا ، ستكون خاطئة إلى حد ما وغير فعالة. بعد تصفح الإنترنت ، صادفنا مثل هذه الخدمة الرائعة ، والتي تعد جزءًا من Angular 4 ، Angular Universal. بعد قراءة الوصف ، أدركنا أن هذا هو ما نحتاجه وأنه عبثًا وبخنا مطوري الإطار.

بدأت ملحمة بتثبيت هذه السعادة على مشروعنا ، وألاحظ أنه في تلك اللحظة تمت كتابة حوالي 10 وحدات كبيرة بالفعل وتم استخدام حوالي 12 حزمة npm خارجية. ذهب التكوين الأول لمشروع نظيف بشكل مثالي ، وذلك بفضل الأدلة على الإنترنت ، وبدا كل شيء يبدأ. علاوة على ذلك ، قمنا بلف جزء الخادم جميعًا على نفس وظيفة Cloud من Firebase. حسنًا ، علينا الآن تجربة رمز المعركة ، ثم حدثت مشاكل. أولاً ، كما اتضح ، يجب أن تدعم جميع حزم npm التابعة لجهة خارجية Angular 4 ، في التعليمات البرمجية على جانب الخادم ، لا يمكنك استخدام نافذة المتغيرات ، والوثيقة ، وما إلى ذلك ، حسنًا ، تصحيح كل هذه السعادة ليس ببساطة واقعيًا.

لن أصف كل عذابنا بهذه الخدمة ، لأنها كانت مؤلمة للغاية. سأقول شيئًا واحدًا ، لم نتغلب عليه ، لا أعرفه أو لم أفهمه بالكامل ، أو أنه لا يزال رطبًا وغير جاهز للاستخدام المنتج. بشكل عام ، الأمر متروك لك لتحديد من يمكنه النجاح ، لكننا قررنا التوقف عند هذا الحد. ونتيجة لذلك ، تمت كتابة خدمة تستمع إلى جميع طلبات http وترجع طلب index.html ، ولكن قبل ذلك ، تقوم بإلقاء العلامات الوصفية اللازمة عليها. ونتيجة لذلك ، سارت الأمور على ما يرام ولمدة 3 أشهر كانت الرحلة طبيعية. بالمناسبة ، نحن نستضيف كل شيء على Azure أيضًا لجميع عوامل الطرف الثالث نفسها.

كندي كل شيء لدينا

وهنا مرة أخرى بعض الوقت من الاستقرار ، والعمل الهادئ نسبيًا. ولا أحد يعتقد أن المفاجأة تنتظرنا من Facebook. في أحد الأيام الجميلة اتضح أن المشاركة في FB لا تعمل. في البداية اعتقدنا أن هذا يرجع إلى تشديد السياسات الأمنية في FB ، ثم مع حظر IP ، لكننا لم نجد السبب. تم الاتصال به لدعم كل من FB و Firebase ، ولكن كل منهما ركل في آخر.

الشيء الوحيد الذي حددناه هو أن المشكلة تكمن في عناوين URL للصور التي قمنا بتخزينها في متجر Firebase ، وأن عنوان url ، أقول لك على الفور ، محدد للغاية هناك. قررنا نقل كل المحتوى الثابت إلى Azure أيضًا ، وسأخبرك أن هذا القرار كان صحيحًا ، حيث زادت سرعة تحميل الصورة ، ويمكنك إدارة كل هذا بمرونة وشفافية أكبر.

لتلخيص

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

ما أود أن ألخصه من كل ما قيل:

1. لا حاجة لمحاولة حل جميع المشاكل التي تظهر في مشاريعك بسبب خدمة واحدة أو تقنية واحدة.
2. حاول تطوير وحدات عالمية لمزيد من المرونة في المستقبل.
3. يعد اختيار مزود الخدمة السحابية مسألة شخصية بحتة ، حيث أنهم عمومًا يقدمون نفس مجموعة الخدمات. يبقى السؤال في السعر وتفضيلاتك.
4. صمم الحل الخاص بك بحيث يمكنك الترحيل بين مقدمي الخدمات والتقنيات المختلفة ، أو على الأقل التفكير في استراتيجية لتحرك محتمل.
5. حسنًا ، لا تخف من التجربة.