دع LoopBack تفعل ذلك: تجول حول إطار عمل Node API الذي كنت تحلم به

لا داعي لذكر الشعبية المتزايدة لـ Node.js لتطوير التطبيقات. تدير eBay خدمة إنتاج Node API منذ عام 2011. تعمل PayPal بنشاط على إعادة بناء واجهتها الأمامية في Node. أصبح موقع Walmart للجوّال أكبر تطبيق Node ، من حيث حركة المرور. في عطلة نهاية الأسبوع بعيد الشكر في عام 2014 ، عالجت خوادم Walmart 1.5 مليار طلب ، تم تسليم 70 بالمائة منها عبر الهاتف المحمول ومدعومة من Node.js. على جانب التطوير ، يستمر مدير حزمة Node (npm) في النمو بسرعة ، متجاوزًا مؤخرًا 150000 وحدة مستضافة.

في حين أن Ruby has Rails و Python لديها Django ، إلا أن إطار تطوير التطبيقات السائد لـ Node لم يتم إنشاؤه بعد. ولكن ، هناك منافس قوي يكتسب قوة: LoopBack ، إطار عمل API مفتوح المصدر تم إنشاؤه بواسطة شركة StrongLoop في سان ماتيو بكاليفورنيا. StrongLoop هو مساهم مهم في أحدث إصدار من Node ، ناهيك عن المشرفين لفترة طويلة على Express ، أحد أكثر أطر عمل Node شيوعًا في الوجود.

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

ما هو LoopBack وكيف يعمل مع Node؟

LoopBack هو إطار عمل لإنشاء واجهات برمجة التطبيقات وربطها بمصادر البيانات الخلفية. مبنيًا على قمة Express ، يمكن أن يأخذ تعريف نموذج البيانات وإنشاء واجهة برمجة تطبيقات REST كاملة الوظائف بسهولة ويمكن لأي عميل الاتصال بها.

يأتي LoopBack مع عميل مدمج ، API Explorer . سنستخدم هذا لأنه يجعل من السهل رؤية نتائج عملنا ، وحتى يمكن لمثالنا التركيز على بناء واجهة برمجة التطبيقات نفسها.

ستحتاج بالطبع إلى تثبيت Node على جهازك للمتابعة. أحضره هنا. npm يأتي معه ، لذا يمكنك تثبيت الحزم الضرورية بسهولة. هيا بنا نبدأ.

قم بإنشاء هيكل عظمي

سيدير ​​تطبيقنا الأشخاص الذين يرغبون في التبرع بالهدايا ، أو الأشياء التي لم يعودوا بحاجة إليها بعد الآن ، إلى شخص قد يحتاج إليها. لذلك ، سيكون المستخدمون هم المانحون والمستقبلون. يمكن للمتبرع إنشاء هدية جديدة والاطلاع على قائمة الهدايا. يمكن للمستلم رؤية قائمة الهدايا من جميع المستخدمين ، ويمكنه المطالبة بأي هدايا لم تتم المطالبة بها. بالطبع ، يمكننا بناء المانحين والمستلمين كأدوار منفصلة في نفس الكيان (المستخدم) ، ولكن دعونا نحاول الفصل بينهما حتى نتمكن من معرفة كيفية بناء العلاقات في LoopBack. سيكون اسم هذا التطبيق الرائد Givesomebody .

قم بتثبيت أدوات سطر أوامر StrongLoop من خلال npm:

 $ npm install -g strongloop

ثم قم بتشغيل منشئ تطبيق LoopBack:

 $ slc loopback _-----_ | | .--------------------------. |--(o)--| | Let's create a LoopBack | `--------- | application! | ( _U`_ ) '--------------------------' /___A___\ | ~ | __'.___.'__ ` |° Y ` ? What's the name of your application? Givesomebody

دعونا نضيف نموذجًا. سيطلق على نموذجنا الأول هدية. سيطلب LoopBack مصدر البيانات والفئة الأساسية. نظرًا لأننا لم نقم بإعداد مصدر البيانات حتى الآن ، يمكننا وضع db (memory) . الفئة الأساسية هي فئة نموذج يتم إنشاؤها تلقائيًا ، ونريد استخدام PersistedModel في هذه الحالة ، لأنها تحتوي بالفعل على جميع طرق CRUD المعتادة بالنسبة لنا. بعد ذلك ، يسأل LoopBack عما إذا كان يجب أن يعرض النموذج من خلال REST (نعم) ، واسم خدمة REST. اضغط على Enter هنا لاستخدام الافتراضي ، وهو ببساطة جمع اسم النموذج (في حالتنا ، gifts ).

 $ slc loopback:model ? Enter the model name: Gift ? Select the data-source to attach Gift to: (Use arrow keys) ❯ db (memory) ? Select model's base class: (Use arrow keys) Model ❯ PersistedModel ? Expose Gift via the REST API? (Y/n) Yes ? Custom plural form (used to build REST URL):

أخيرًا ، نقدم أسماء الخصائص وأنواع بياناتها والعلامات المطلوبة / غير المطلوبة. سيكون للهدية خصائص name description :

 Let's add some Gift properties now. Enter an empty property name when done. ? Property name: name invoke loopback:property ? Property type: (Use arrow keys) ❯ string ? Required? (y/N)Yes

أدخل اسم خاصية فارغًا للإشارة إلى أنك انتهيت من تحديد الخصائص.

سينشئ منشئ النموذج ملفين يحددان النموذج في common/models : gift.json و gift.js يحدد ملف JSON جميع البيانات الأولية حول الكيان: الخصائص والعلاقات والتحقق من الصحة والأدوار وأسماء الأساليب. يتم استخدام ملف JavaScript لتحديد سلوك إضافي ، ولتحديد الخطافات البعيدة التي يجب استدعاؤها قبل أو بعد عمليات معينة (على سبيل المثال ، إنشاء أو تحديث أو حذف).

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

هيكل المشروع

دعنا نلقي نظرة على هيكل المشروع الذي تم إنشاؤه:

الدلائل الرئيسية الثلاثة هي: - /server - تحتوي على برامج نصية لتطبيق العقدة وملفات التكوين. - /client - يحتوي على .js و .html و .css وجميع الملفات الثابتة الأخرى. - /common - هذا المجلد مشترك لكل من الخادم والعميل. ملفات النماذج تذهب هنا.

فيما يلي تحليل تفصيلي لمحتويات كل دليل مأخوذ من توثيق LoopBack:

بناء علاقات

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

 $ slc loopback:relation ? Select the model to create the relationship from: Donor ? Relation type: has many ? Choose a model to create a relationship with: Gift ? Enter the property name for the relation: gifts ? Optionally enter a custom foreign key: ? Require a through model? No

لاحظ أنه لا يوجد نموذج من خلال ؛ نحن فقط نحتفظ بالإشارة إلى الهدية.

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

 // common/models/donor.json ... "relations": { "gifts": { "type": "hasMany", "model": "Gift", "foreignKey": "" } }, ...

أضف مصدر بيانات

لنرى الآن كيفية إرفاق مصدر بيانات حقيقي لتخزين جميع بيانات التطبيق لدينا. لأغراض هذا المثال ، سنستخدم MongoDB ، لكن LoopBack بها وحدات للتواصل مع Oracle و MySQL و PostgreSQL و Redis و SQL Server.

أولاً ، قم بتثبيت الموصل:

 $ npm install --save loopback-connector-mongodb

بعد ذلك ، أضف مصدر بيانات إلى مشروعك:

 $ slc loopback:datasource ? Enter the data-source name: givesomebody ? Select the connector for givesomebody: MongoDB (supported by StrongLoop)

الخطوة التالية هي تكوين مصدر البيانات في server/datasources.json . استخدم هذا التكوين لخادم MongoDB محلي:

 ... "givesomebody": { "name": "givesomebody", "connector": "mongodb", "host": "localhost", "port": 27017, "database": "givesomebody", "username": "", "password": "" } ...

أخيرًا ، افتح server/model-config.json وقم بتغيير datasource لجميع الكيانات التي نريد استمرارها في قاعدة البيانات إلى "givesomebody" .

 { ... "User": { "dataSource": "givesomebody" }, "AccessToken": { "dataSource": "givesomebody", "public": false }, "ACL": { "dataSource": "givesomebody", "public": false }, "RoleMapping": { "dataSource": "givesomebody", "public": false }, "Role": { "dataSource": "givesomebody", "public": false }, "Gift": { "dataSource": "givesomebody", "public": true }, "Donor": { "dataSource": "givesomebody", "public": true }, "Receiver": { "dataSource": "givesomebody", "public": true } }

اختبار REST API الخاص بك

حان الوقت لنرى ما بنيناه حتى الآن! سنستخدم الأداة المدمجة الرائعة ، API Explorer ، والتي يمكن استخدامها كعميل للخدمة التي أنشأناها للتو. دعنا نحاول اختبار استدعاءات REST API.

في نافذة منفصلة ، ابدأ MongoDB بـ:

 $ mongod

قم بتشغيل التطبيق باستخدام:

 $ node .

في متصفحك ، انتقل إلى http://localhost:3000/explorer/ . يمكنك رؤية الكيانات الخاصة بك مع قائمة العمليات المتاحة. حاول إضافة جهة مانحة واحدة مع مكالمة POST /Donors .

API Explorer سهل الاستخدام للغاية ؛ حدد أيًا من الطرق المكشوفة ، وسيتم عرض مخطط النموذج المقابل في الركن الأيمن السفلي. في منطقة نص data ، من الممكن كتابة طلب HTTP مخصص. بمجرد ملء الطلب ، انقر فوق الزر "جربه" ، وسيتم عرض استجابة الخادم أدناه.

مصادقة المستخدم

كما ذكرنا أعلاه ، فإن أحد الكيانات التي تم إنشاؤها مسبقًا مع LoopBack هي فئة المستخدم. يمتلك المستخدم طرق تسجيل الدخول والخروج ، ويمكن أن يرتبط بكيان AccessToken الذي يحتفظ بالرمز المميز للمستخدم المحدد. في الواقع ، نظام مصادقة المستخدم الكامل جاهز للخروج من الصندوق. إذا حاولنا الاتصال /Donors/login من خلال API Explorer ، فإليك الرد الذي نحصل عليه:

 { "id": "9Kvp4zc0rTrH7IMMeRGwTNc6IqNxpVfv7D17DEcHHsgcAf9Z36A3CnPpZJ1iGrMS", "ttl": 1209600, "created": "2015-05-26T01:24:41.561Z", "userId": "" }

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

الطرق البعيدة

الطريقة البعيدة هي طريقة ثابتة لنموذج ، يتم عرضها على نقطة نهاية REST مخصصة. يمكن استخدام الطرق البعيدة لإجراء عمليات لا يوفرها نموذج LoopBack القياسي REST API.

بجانب طرق CRUD التي نخرجها من الصندوق ، يمكننا إضافة العديد من الطرق المخصصة كما نريد. يجب أن ينتقل كل منهم إلى ملف [model].js . في حالتنا ، دعنا نضيف طريقة عن بُعد إلى نموذج الهدية للتحقق مما إذا كانت الهدية محجوزة بالفعل ، وأخرى لسرد جميع الهدايا غير المحجوزة.

أولاً ، دعنا نضيف خاصية إضافية إلى النموذج تسمى reserved . فقط أضف هذا إلى الخصائص في gift.json :

 ... "reserved": { "type": "boolean" } ...

يجب أن تبدو الطريقة البعيدة في gift.js :

 module.exports = function(Gift) { // method which lists all free gifts Gift.listFree = function(cb) { Gift.find({ fields: { reserved: false } }, cb); }; // expose the above method through the REST Gift.remoteMethod('listFree', { returns: { arg: 'gifts', type: 'array' }, http: { path: '/list-free', verb: 'get' } }); // method to return if the gift is free Gift.isFree = function(id, cb) { var response; Gift.find({ fields: { id: id } }, function(err, gift) { if (err) return cb(err); if (gift.reserved) response = 'Sorry, the gift is reserved'; else response = 'Great, this gift can be yours'; }); cb(null, response); }; // expose the method through REST Gift.remoteMethod('isFree', { accepts: { arg: 'id', type: 'number' }, returns: { arg: 'response', type: 'string' }, http: { path: '/free', verb: 'post' } }); };

لذلك لمعرفة ما إذا كانت هدية معينة متاحة ، يمكن للعميل الآن إرسال طلب POST إلى /api/Gifts/free ، مع تمرير id الهدية المعنية.

خطاف بعيد

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

• يتم تشغيل beforeRemote() قبل الطريقة البعيدة.
• afterRemote() بعد الطريقة البعيدة.

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

في حالتنا ، دعنا نضع خطافًا لطباعة المعلومات إلى وحدة التحكم كلما تم إنشاء مانح جديد. لإنجاز ذلك ، دعنا نضيف خطاف "قبل الإنشاء" في الجهات المانحة. donor.js :

 module.exports = function(Donor) { Donor.beforeRemote('create', function(context, donor, next) { console.log('Saving new donor with name: ', context.req.body.name); next(); }); };

يتم استدعاء الطلب وفقًا context المحدد ، ويتم استدعاء رد النداء () next() في البرنامج الوسيط (الذي تمت مناقشته أدناه) بعد تشغيل الخطاف.

ضوابط الوصول

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

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

 $ slc loopback:acl

للبدء ، دعنا نرفض وصول الجميع إلى جميع نقاط النهاية.

 ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: All methods and properties ? Select the access type: All (match all types) ? Select the role: All users ? Select the permission to apply: Explicitly deny access

بعد ذلك ، اسمح للجميع بالقراءة من نماذج الهدايا:

 $ slc loopback:acl ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: All methods and properties ? Select the access type: Read ? Select the role: All users ? Select the permission to apply: Explicitly grant access

بعد ذلك ، نريد السماح للمستخدمين المصادق عليهم بإنشاء هدايا:

 $ slc loopback:acl ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: A single method ? Enter the method name: create ? Select the role: Any authenticated user ? Select the permission to apply: Explicitly grant access

وأخيرًا ، دعنا نسمح لمالك الهدية بإجراء أي تغييرات:

 $ slc loopback:acl ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: All methods and properties ? Select the access type: Write ? Select the role: The user owning the object ? Select the permission to apply: Explicitly grant access

الآن عندما نراجع gift.json ، يجب أن يكون كل شيء في مكانه:

 "acls": [ { "accessType": "*", "principalType": "ROLE", "principalId": "$everyone", "permission": "DENY" }, { "accessType": "READ", "principalType": "ROLE", "principalId": "$everyone", "permission": "ALLOW" }, { "accessType": "EXECUTE", "principalType": "ROLE", "principalId": "$authenticated", "permission": "ALLOW", "property": "create" } ],

ملاحظة مهمة هنا: $authenticated عليه هو دور محدد مسبقًا يتوافق مع جميع المستخدمين في النظام (كل من المانحين والمستلمين) ، لكننا نريد فقط السماح للمانحين بإنشاء هدايا جديدة. لذلك ، نحن بحاجة إلى دور مخصص. نظرًا لأن الدور هو كيان آخر نخرجه من الصندوق ، فيمكننا الاستفادة من استدعاء واجهة برمجة التطبيقات لإنشاء دور المانح $authenticatedDonor في وظيفة التمهيد ، ثم فقط تعديل pricipalId في gift.json .

سيكون من الضروري إنشاء ملف جديد ، server/boot/script.js ، وإضافة الكود التالي:

 Role.create({ name: 'authenticatedDonor' }, function(err, role) { if (err) return debug(err); })

يعين كيان RoleMapping الأدوار على المستخدمين. تأكد من أن يتم عرض كل من الدور وتخطيط الأدوار من خلال REST. في server/model-config.json ، تحقق من تعيين "public" على " true " لكيان الدور. بعد ذلك في الجهات المانحة. donor.js ، يمكننا كتابة خطاف "قبل الإنشاء" والذي سيعين معرف المستخدم ودور roleID في استدعاء userID POST API.

الوسيطة

تحتوي البرامج الوسيطة على وظائف يتم تنفيذها عند تقديم طلب إلى نقطة نهاية REST. نظرًا لأن LoopBack يعتمد على Express ، فإنه يستخدم برمجية وسيطة Express بمفهوم إضافي واحد ، يسمى "مراحل البرامج الوسيطة". تُستخدم المراحل لتعريف الترتيب الذي يتم من خلاله استدعاء الوظائف في البرمجيات الوسيطة بوضوح.

فيما يلي قائمة بالمراحل المحددة مسبقًا ، على النحو المنصوص عليه في مستندات LoopBack:

1. الأولي - النقطة الأولى التي يمكن تشغيل البرامج الوسيطة عندها.
2. جلسة - تحضير كائن الجلسة.
3. المصادقة - معالجة المصادقة والتفويض.
4. تحليل - تحليل نص الطلب.
5. المسارات - مسارات HTTP التي تنفذ منطق التطبيق الخاص بك. يتم تشغيل البرامج الوسيطة المسجلة عبر تطبيق Express API app.use و app.route و app.get (وأفعال HTTP الأخرى) في بداية هذه المرحلة. استخدم هذه المرحلة أيضًا للتطبيقات الفرعية مثل loopback / server / middleware / rest أو loopback-explorer.
6. الملفات - خدمة الأصول الثابتة (الطلبات تصل إلى نظام الملفات هنا).
7. نهائي - التعامل مع الأخطاء والطلبات الخاصة بعناوين URL غير المعروفة.

كل مرحلة لها ثلاث مراحل فرعية. على سبيل المثال ، المراحل الفرعية للمرحلة الأولية هي:

1. الأولي: قبل
2. مبدئي
3. الأولي: بعد

دعنا نلقي نظرة سريعة على middleware.json الافتراضية لدينا:

 { "initial:before": { "loopback#favicon": {} }, "initial": { "compression": {}, "cors": { "params": { "origin": true, "credentials": true, "maxAge": 86400 } } }, "session": { }, "auth": { }, "parse": { }, "routes": { }, "files": { }, "final": { "loopback#urlNotFound": {} }, "final:after": { "errorhandler": {} } }

في المرحلة الأولية ، نسمي loopback.favicon() ( loopback#favicon هو معرف البرنامج الوسيط لهذا الاستدعاء). بعد ذلك ، يتم استدعاء compression وحدات npm و cors التابعة لجهات خارجية (مع أو بدون معلمات). في المرحلة الأخيرة ، لدينا مكالمتان إضافيتان. urlNotFound هو استدعاء LoopBack ، و errorhandler هو وحدة تابعة لجهة خارجية. يجب أن يوضح هذا المثال أنه يمكن استخدام الكثير من المكالمات المضمنة تمامًا مثل وحدات npm الخارجية. وبالطبع ، يمكننا دائمًا إنشاء برمجتنا الوسيطة الخاصة بنا واستدعائها من خلال ملف JSON هذا.

loopback-boot

للختام ، دعنا نذكر وحدة تقوم بتصدير وظيفة boot() التي تهيئ التطبيق. ستجد في server/server.js الجزء التالي من الكود ، والذي يقوم بتشغيل التطبيق:

 boot(app, __dirname, function(err) { if (err) throw err; // start the server if `$ node server.js` if (require.main === module) app.start(); });

سيبحث هذا البرنامج النصي في مجلد server/boot ، ويحمل جميع البرامج النصية التي يجدها هناك بترتيب أبجدي. وبالتالي ، في server/boot ، يمكننا تحديد أي برنامج نصي يجب تشغيله في البداية. أحد الأمثلة على ذلك هو explorer.js ، الذي يدير API Explorer ، العميل الذي استخدمناه لاختبار API الخاص بنا.

خاتمة

قبل أن أتركك ، أود أن أذكر StrongLoop Arc ، وهو واجهة مستخدم رسومية يمكن استخدامها كبديل لأدوات سطر أوامر slc . ويتضمن أيضًا أدوات لبناء تطبيقات العقدة وتحديد سماتها ومراقبتها. بالنسبة لأولئك الذين ليسوا معجبين بسطر الأوامر ، فهذا بالتأكيد يستحق المحاولة. ومع ذلك ، فإن StrongLoop Arc على وشك أن يتم إهماله ويتم دمج وظائفه في IBM API Connect Developer Toolkit.

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