دليل المطور لتحسين هيكل المشروع في تطبيقات النيازك

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

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

السقالات: التسلسل الهرمي للدليل القابل للإدارة في Meteor

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

لحل هذه المشكلة ، أوصي بفحص مكواة حزمة npm الخاصة بـ Chris Mather. تحتوي الحزمة على مجموعة متنوعة من خيارات التكوين ، لذا سيكون من الصعب وصفها هنا ، لكنها بشكل عام تبني هيكل مشروع سيبدو مثل هذا:

 my-app/ |- .iron/ |- config.json |- bin/ |- build/ |- config/ |- development/ |- env.sh |- settings.json |- app/ |- client/ |- collections/ |- lib/ |- stylesheets/ |- templates/ |- head.html |- lib/ |- collections/ |- controllers/ |- methods.js |- routes.js |- packages/ |- private/ |- public/ |- server/ |- collections/ |- lib |- methods.js |- publish.js |- bootstrap.js

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

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

هناك طريقتان لأداء أدنى مستوى من التنظيم: الأولى حسب نوع الملف ، والثانية حسب الوظيفة. يعني التنظيم حسب نوع الملف أنه في مجلد العميل / القوالب ، على سبيل المثال ، سيكون لديك ثلاثة مجلدات - واحد لملفات JavaScript ، وواحد لملفات CSS ، وواحد لـ HTML. سيحتوي مجلد HTML على جميع ملفات HTML الخاصة بالقالب ، على سبيل المثال Login.html و Main.html وما إلى ذلك. سيحتوي مجلدا JavaScript و CSS على ملفات نماذج من نوعها ، على التوالي. التنظيم حسب الوظيفة ، من ناحية أخرى ، يعني التنظيم بالمفهوم الذي تجسده الملفات. على سبيل المثال ، في العميل / القوالب ، سيكون لدي مجلد "تسجيل الدخول" ، مع جميع ملفات JavaScript و CSS و HTML المرتبطة بعملية تسجيل الدخول للتطبيق. أفضل التنظيم حسب الوظيفة لأنه يتيح لك أن تكون أكثر وضوحًا حول المكان الذي يمكنك العثور فيه على ملفات أو أجزاء معينة من التعليمات البرمجية. ومع ذلك ، فهي ليست بالأبيض والأسود فقط ، ومعظم الأفراد والفرق يستخدمون مزيجًا من هذه الأساليب لهيكلة ملفاتهم ومجلداتهم.

المخطط: يحتاج تطبيقك إلى ذلك حتى إذا كانت قاعدة البيانات لديك لا تتطلب ذلك

النوع الثاني من الهيكل الذي أود مناقشته مرتبط بقاعدة البيانات. تفترض هذه المقالة أنك تستخدم MongoDB. إذا لم تكن كذلك ، فمن المحتمل أن تظل المفاهيم سارية ولكن التفاصيل لن تكون كذلك. يعرف أولئك الذين يستخدمون MongoDB أنه يتيح للطريقة التي نخزن بها بياناتنا أن تكون غير منظمة. نظرًا لأن MongoDB هي قاعدة بيانات مخزن مستندات NoSQL ، فلا يوجد مخطط ثابت لأي "نوع" من البيانات. تعني هذه الحرية أنه لا داعي للقلق بشأن التأكد من أن جميع الكائنات موحدة إلى شكل جامد ، في الواقع ، يمكن إلقاء جميع بيانات تطبيقك في مجموعة واحدة إذا كنت ترغب في ذلك. ومع ذلك ، عندما يتعلق الأمر بصنع تطبيقات بجودة الإنتاج ، فإن هذا ليس مرغوبًا حقًا. من أجل إدارة هذا وإضافة ميزات مفيدة مثل التحقق من صحة طلبات الكتابة ، يمكننا اللجوء إلى حزمتين رائعتين من Meteor: Aldeed's SimpleSchema و Collection2.

تسمح لك حزمة SimpleSchema ، كما يوحي الاسم ، بالتحقق من صحة الكائنات بشكل تفاعلي في تطبيقك. تحقق من المستندات على GitHub. تعمل حزمة Collection2 على التمهيد من SimpleSchema وتسمح لك بإحضار المخططات المناسبة إلى مجموعات Meteor. ما يمكّنه هذا هو التحقق التلقائي من طلبات الكتابة من جانب الخادم والعميل لأي مجموعة مع مخطط مرفق بها. كلتا الحزمتين عميقة جدًا وقابلة للتخصيص ، لذا من الصعب تقديم فهم كامل لهما في بضع فقرات. بدلاً من ذلك ، أوصيك بإلقاء نظرة على القراءات التفصيلية التي جمعها Aldeed للتفاصيل. سأتحدث ببساطة عن كيف حصلت على قيمة من هذه الحزم. كان من أفضل الأشياء التي تم تمكينها هو التحقق من صحة إدخال النموذج الخاص بالمستخدم. هذا مفيد للتحقق من مستندات مستخدم Meteor (من حزمة الحسابات). افتراضيًا ، يمتلك مستخدمو Meteor مخططًا ضمنيًا معقدًا بشكل مدهش. إليكم صورة لجزء منه من الكود الذي كان الدييد لطيفًا جدًا لإتاحته:

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

هذا ببساطة مخطط كائن ملف تعريف المستخدم. ستكون محاولة التحقق من صحة كل كائن المستخدم بمثابة فوضى بدون حزمة مصممة لهذا الغرض مثل SimpleSchema. بينما تظهر كل هذه الحقول اختيارية في الصورة ، إذا كنت تريد مخطط مستخدم تم التحقق من صحته بشكل صحيح ، فمن المحتمل ألا يكون كذلك ، وتقوم أشياء مثل "Schema.UserCountry" بإعادة التوجيه إلى مخططات أخرى للتحقق من صحتها. من خلال إرفاق هذا المخطط بكائن المستخدم ودمج هذا بشكل تفاعلي مع نماذجنا ، ربما مع حزمة مثل النموذج التلقائي لـ Aldeed ، يمكننا الحصول على درجة جيدة من التحكم فيما يفعل وما لا يدخل في قواعد بياناتنا ، مما يوفر الوقت والجهد باستخدام نموذج مفاهيمي لكيفية معالجة البيانات في تطبيقنا يمكن الإشارة إليه ومناقشته بشروط محددة.

الأدوار: للخطوتين 401 و 403

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

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

على الرغم من أن جوهر النظام بسيط نسبيًا ، إلا أنه يسمح بأذونات معقدة ودقيقة لأي جزء من تطبيقك. نظرًا لأنه يتم تخزين جميع الأدوار كسلاسل ، يمكنك إعداد نظام عميق كما تريد - "admin" ، "admin.division1.manage" ، "admin.division1.manage.group2" ، وهكذا.

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

تغليف

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

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