مقدمة أساسية
لنبدأ بمفهوم مهم "قالب". بشكل عام ، قالب في الويب هو صفحة يمكنها إنشاء ملف بعد ملء البيانات. بالمعنى الدقيق للكلمة ، يجب على محرك القالب استخدام الملفات بتنسيق محدد والبيانات المقدمة لتجميع وإنشاء الصفحات. تنقسم النماذج تقريبًا إلى قوالب في الواجهة الأمامية (مثل EJS) والقوالب الخلفية (مثل علامة الثقب) التي تم تجميعها على جانب المتصفح والخادم على التوالي.
نظرًا لأن بعض الطلاب على الفور لم يعرفوا الكثير عن Node.js ، إليك بعض المعرفة ذات الصلة بـ Node.js. لن أتحدث عن تعريفات الحدث غير المتزامن وما إلى ذلك على الموقع الرسمي. هنا أستعير صورة من Pu Lingshu لشرح بنية Node.js. إذا فهمت Java ، فيمكنك فهمها كإصدار JS من JVM. تشمل المتصفحات عمومًا العارضين ومحركات نص JS. أخذ متصفح Chrome كمثال ، يستخدمون WebKit kernel Renderer ومحرك Script V8 ، بينما يستخدم Node.js محرك V8. باختصار ، إنها بيئة تشغيل JS ، تمامًا مثل أداة تصحيح تصحيح F12 للمتصفح ، لكن Node.js ليس لديها DOM و BOM.
تصف هذه الصورة بعض المعلومات حول Node.js ، مثل NPM ، ومدير الحزمة الممتاز ، ومجتمع CNODE ، و Github ، والتي شجعت على ازدهار Node.js إلى حد ما وقدمت ضمانات فنية.
الشركات الكبيرة عادة ما تكون دولة الطقس للتكنولوجيا. على سبيل المثال ، تحظى رد فعل Google Angular و Facebook بشعبية كبيرة الآن. فقط 3 شركات كبيرة مدرجة هنا كأمثلة. وغني عن القول ، أن بنية Midway في Taobao هي ، يأتي Pu Ling ، رائد Node.js ، من Taobao. قامت Qunar أيضًا بتطوير إطار فني يجب أن يسمى "QTX". أطلق الفريق 75 بقيادة Yueying إطار عمل خادم الويب يعتمد على ES6/ES7 - ThinkJs. في ذلك الوقت ، كان مديرنا الفني متفائلًا للغاية ، لكن نظرًا لأنه لم يكن لدي وقت لتعلم ES6 والمكونات الإضافية لم تكن غنية بما فيه الكفاية ، ما زلت اخترت صريحًا أكثر نضجًا.
بالعودة إلى الموضوع ، يسرد هذا الجدول ثلاث طرق تطوير لفصل نهايات الأمام والخلفية التي تعرضت لها. الأول هو أكثر قوالب لغة الخلفية شيوعًا التي تستخدم Java ، وهي صديقة لكبار المسئولين الاقتصاديين ، وهي أفضل في استخدام ذاكرة التخزين المؤقت وتقليل عبء عرض المتصفح. المشكلة الأكبر هي أن درجة اقتران ملفات القالب مرتفعة للغاية. لا أحد يريد حل المشكلة. لا يمكن للموظفين الأماميين رؤية البيانات ، ولا يفهم الموظفون الخلفيون الصفحة ، وملفات القالب تشبه البطاطا الساخنة. والثاني هو الحل الحالي للتنفيذ لمحطة الهاتف المحمول في مشروعنا ، والذي يستخدم إطار عمل الزاوي (يمكن اعتبار التعليمات الزاوية قوالب الواجهة الأمامية) وخادم الوكيل العكسي لـ NGINX لفصل الواجهة الأمامية والخلفية تمامًا ، والتفاعل فقط مع البيانات من خلال AJAX. هذا الحل هو بالضبط عكس مزايا وعيوب السابق. يعد أداء القوالب الأمامية مشكلة دائمًا ، خاصة على الأجهزة المحمولة ، وخاصة على الأجهزة المحمولة المنخفضة. آخر المشروع هو المشروع الجديد الذي يستخدم Node.js كخادم أمامي ، والذي يقسم المسؤوليات الأمامية من المتصفح إلى مستوى القالب ، وحل جميع المشكلات المذكورة أعلاه ، ولكن هناك بالفعل مشاكل جديدة ، وسيتم تحليل هذه المشكلة لاحقًا.
بطبيعة الحال ، فإن تطوير المكاسب الكاملة مناسب جدًا للمشاريع الصغيرة. بالنسبة لتطوير JSP/PHP التقليدي ، تكون تكلفة الاتصال لتطوير الكامل أقل ، ويمكن للمطورين فهم الوحدة الوظيفية بأكملها بسهولة ، وبالتالي استعادة تصميم المنتج بشكل أفضل. لا سيما تطوير المكاسب الكاملة القائمة على لغة JS: Meteor و Mean Technology التي تظهر الآن تجعل التطوير الأمامي والخلفي يتم التعامل معه مباشرة بلغة واحدة. مع MongoDB ، يتم استخدام البيانات من المتصفح إلى قاعدة البيانات مباشرة دون الهروب ، وليس هناك حاجة لكتابة SQL ، مما يقلل إلى حد كبير من تكلفة التطوير.
بعض الإضافات المستخدمة لإنشاء خادم Node.js هذه المرة. ليست هناك حاجة لتقديم إطار خادم الويب الخفيف الوزن الشهير. كما أنه من قبيل الصدفة استخدام محرك قالب المقاود ، لأن Express4 هو افتراضيًا. المقاود يستحق كونه محرك قالب "المنطق الضعيف". يدعو إلى تقليل منطق القالب ومحاولة استخدام المتغيرات والترحيل فقط. بناءً على مفهوم التصميم ، قمت بتوسيع مساعدين فقط. مقال محدد: https://yalishizhude.github.io/2016/01/22/handlebars/superagent لا يزال يستخدم بسبب Express4. نظرًا لأن رمز الاختبار الخاص به يستخدم الاختبار الرائع ، فإن الاختبار الطائفي يعتمد على SuperAgent ، لذلك يتم استخدام SuperAgent لإعادة توجيه الطلبات وبدء الطلبات. لا يزال Superagent ضعيفًا جدًا ولا يمكن تأسيسه لاتصالات طويلة. ما زلت أوصي بالمكون الإضافي للطلب. لا يوجد شيء لتقديمه إلى Restfleapi. يستخدم الخادم والمتصفح الأمامي والخادم الأمامي وخادم النهاية الخلفية هذه المجموعة من المواصفات. في الأساس ، يشير عنوان URL إلى الموارد ، والإضافة ، وحذف ، وتعديله ، ويتم التعبير عن طريقة الطلب المحددة ، وتمثل رموز الحالة النتائج ، وما إلى ذلك. هذا مؤلم للغاية ، لذلك استسلمت.
عملية التنمية
إذا كانت هذه المشاركة تتحدث بشكل أساسي عن كيفية استخدام Node.js كخادم أمامي لتحقيق الفصل الأمامي ، فلا يوجد شيء يمكن قوله ، فقط انظر إلى المقالة على Taobao ued. أكبر مشكلة في فصل النهايات الأمامية والخلفية هي أنها تثير تكاليف الاتصال ، وتحديداً تعريف وتصحيح الواجهات. في عملية التطوير التقليدية في الشكل أعلاه ، سيتم وضع تعريف الواجهة في خادم الواجهة ، وبعد ذلك سيجري النهايات الأمامية والخلفية تصحيح الأخطاء المحلية بناءً على بيانات احتيال مستند الواجهة ، ثم إجراء تصحيح الأخطاء المشتركة. هذا الرابط هو عندما ينتهي الأمام والخلفية في القتال. هذه المعلمة خاطئة وقيمة الإرجاع خاطئة. باختصار ، إنه مضيعة للوقت. بعد ذلك ، دعونا نرى كيف يتم حل هذه المشكلة في مشروعنا ~
كانت مشكلة الواجهة المتوترة في الأطراف الأمامية والخلفية موجودة دائمًا. بصفتي محافظًا ، أؤمن بالتطور التكراري ، وبالتالي فإن الخطوة الأولى هي إضافة خادم وهمية. السحر لهذا الخادم هو أنه يقوم تلقائيًا بإنشاء بيانات مزيفة استنادًا إلى مستند الواجهة ، وتنفيذ الواجهة ، أي واجهة برمجة التطبيقات (API) ، والطلاب الأماميين لم يعد يتعين عليهم كتابة البيانات حتى الموت للاختبار. لا توجد طريقة ، من قال أنني مطور واجهة؟ بادئ ذي بدء ، أفكر في شعبي. hehe ~ بالطبع ، هذا مفيد فقط للتنمية في الواجهة الأمامية إلى حد ما. ستكون هناك أيضًا مشاكل عندما تكون واجهات ومستندات الواجهة الخلفية غير متناسقة وهي متصلة. ما يجب القيام به؟
رأيت بطريق الخطأ مقالاً من قبل لاو ما على مدونة The Blade Master ، والتي تتحدث بشكل خاص عن فصل النهايات الأمامية والخلفية. أحد المفاهيم المهمة هو اختبار العقود ، وتسمى أيضًا الاختبار الثنائي. المفهوم الأساسي هو حل مشكلة تصحيح الأخطاء عن بعد المشتركة. تحقق من معلمات النهايات الأمامية والخلفية وتطلب من الجميع تطوير وفقًا لمستند الواجهة. مستوحاة من ذلك ، تمت إضافة قاعدة JSON-SCHEMA لتحقيق التحقق من المعلمة من طلبات HTTP ، وكل من لا يتبع القواعد سيغيرها.
هذا Redmine هو مدير الوثائق الأقدم لدينا وليس له وظيفة أخرى باستثناء وظائف التسجيل والعرض.
يُعرف Swagger باسم خادم مستندات الواجهة الأكثر شعبية في العالم. لديها واجهة جميلة والعديد من المكونات الإضافية. يمكنه إنشاء رمز الاختبار مباشرة للغات الخلفية. ومع ذلك ، لم أفهمها أبدًا عند نشرها ، وتنسيق Yaml ليس جيدًا مثل JSON ، لذلك تخليت عنه.
هذا هو خادم المستندات وخادم Mock المستخدم في مشروعنا ، والخادم الذي تم تنفيذه على أساس التكنولوجيا المتوسطة ، والوظائف الأساسية:
باستخدام المكون الإضافي MOCKJS ، يمكن إنشاء بيانات عشوائية ديناميكيًا لإجراء اختبارات واجهة Checksum على معلمات الواجهة استنادًا إلى JSON-SCHEMA ، ويمكن حفظ وقت الاستجابة للاختبار. يحتوي محرر JSON البسيط على وظيفة التحقق من تسجيل الدخول ، ويمكن تنفيذ تصحيح أخطاء الواجهة بعد تسجيل الدخول. يستجيب خادم Mock للطلب وفقًا لخادم API ، وسيتم تحديثه تلقائيًا عند تحديث الواجهة.
بعض الأسئلة
Node.js هي أجنحة المهندسين الأماميين ، وهل يجب أن أصبح ملاكًا أو شيطانًا مع أجنحة؟ هذا يعتمد على ما إذا كان يمكن حل المشكلات الناتجة عن استخدامه.
بادئ ذي بدء ، فإن عبء العمل على الواجهة الأمامية سيزداد بلا شك ، ولكن سيتم تقليل تكلفة الاتصال. إن استقرار خادم NODE.JS واحد ليس جيدًا في الواقع بما فيه الكفاية ، ولكن يمكن تجنب متانة الكود والسجل المثالي بشكل فعال. أتصل مرة أخرى. هناك الكثير من الحلول لهذه المشكلة ، بما في ذلك وحدة Node.js 'Q/Async و ES6/ES7. node.js تصحيح الأخطاء. على الرغم من أنني كنت أرفض دائمًا IDE ، إلا أنني يجب أن أعترف أن عاصفة الويب مريحة للغاية لتصحيح الأخطاء. إن المصفاة العقدة التي أستخدمها جيدة جدًا ، كما أن الواجهة مشابهة لأداة مطور Chrome ، وتبدو مألوفة تمامًا.
إذا كنت مبرمجًا للواجهة الخلفية ، فيجب أن تكون أكثر عرضة لاستيعاب Node.js. يتم تسليم عمل تكامل الواجهة إلى الخادم الأمامي للمعالجة ، ويتم تقليل درجة الاقتران مع الواجهة الأمامية بشكل كبير ، ويتم تقليل عبء العمل وكفاءة العمل.
هناك نقطتان للتجربة
على الرغم من أن استخدام Node.js له تكلفة تعليمية معينة ، إلا أنه لا يزال ودودًا للغاية للمطورين في الواجهة الأمامية. علاوة على ذلك ، إذا تم استخدام Node.js في الواجهة الأمامية ، فسيتم تحسين كل من المحتوى الفني وعبء العمل ، وبالتالي تعزيز أهمية الوظيفة. فقط عندما يمكن للمطورين الحاليين خلق المزيد من القيمة المؤهلين للطلب رواتب أعلى. يوصى بتقديم اقتراحات أقل وإعطاء المزيد من خطط الجدوى في العمل ، وإجراء البحوث التقنية المسبقة بدلاً من كتابة HelloWorld بسيطة.
لخص
قد يقول بعض الناس أن مجموعة الأشياء التي قدمتها معقدة للغاية وأنها مزعجة للغاية لاستخدامها ، لذلك من الأفضل التواصل وجهاً لوجه. لمثل هذه الشكوك ، لا يمكنني سوى استخدام مثال ذكره مهندس واجهة المستخدم Tencent Yu Guo في "زراعة مهندسي المكدس الكاملة على الويب". مرة واحدة ، عندما سأله الشخص الأمامي المسؤول عن شركة صغيرة في الهاتف عن كيفية إدارة الكود ، قال الطرف الآخر إنه سيستخدم FTP لتحميله مباشرة ، واشتكى من أن مرؤوسيه يقومون دائمًا بتحديث الكود الخاطئ. كما سأله لماذا لم يستخدم SVN أو Git. قال إنه سيكون من الأسهل تحديثه يدويًا. حقيقة هذه القصة هي إجابتي على السؤال ~
PPT عنوان تنزيل