Feathers: اجعل إطار عمل خادم Feathers مستقلاً للعمل مع Express و Koa و Hapi

تم إنشاؤها على ١٢ مارس ٢٠١٦  ·  22تعليقات  ·  مصدر: feathersjs/feathers

الآن بعد أن أصبح Feathers يعمل بمكتبة مستقلة عن العميل بالفعل (راجع https://github.com/feathersjs/feathers/pull/193) ، لا نحتاج حقًا إلى Express باعتباره اعتمادًا صعبًا على الخادم أيضًا. بدلاً من ذلك ، يمكننا إنشاء وحدات منفصلة لـ Express و Koa وربما Hapi والتي يمكن تهيئتها تمامًا مثل أي مكون إضافي آخر:

يعبر

الشيء الوحيد الذي يجب تغييره في الترقية من تطبيق Feathers 2 سيكون app.configure(express()) :

const feathers = require('feathers');
const express = require('feathers-express');

const app = feathers()
  // Make this app Express compatible
  .configure(express())
  // Configure REST API that uses Express
  .configure(express.rest());

// Use any Express middleware
app.use(bodyParser.json());
// Use Feathers services normally
app.use('/todos', {
  get(id) {
    return Promise.resolve({ id, description: `You have to do ${id}!` });
  }
});

كوا

ظهر دعم Koa عدة مرات (انظر # 83 و # 58). يمكن القيام بذلك الآن بشكل مشابه جدًا:

const feathers = require('feathers');
const koa = require('feathers-koa');

const app = feathers()
  // Make this app Koa compatible
  .configure(koa())
  // Configure Koa REST handler
  .configure(koa.rest());

// Use normal Koa middleware
app.use(function *(){
  this.body = 'Hello World';
});

// Use a Feathers service through app.service
app.service('/todos', {
  get(id) {
    return Promise.resolve({ id, description: `You have to do ${id}!` });
  }
});
Breaking Change Feature Proposal
مصدر
picture daffl
👍25 🎉8

التعليق الأكثر فائدة

أعتقد أننا يجب أن نجعل Feathers مكتبة بدلاً من إطار عمل - وهذا سيجعلها أكثر استقلالية في النقل أيضًا.

أمثلة:

الكود المشترك
const feathersApp = feathers().configure(rest());
feathersApp.service('todos', new NeDB('todos'));
export default feathersApp;
إطار محدد

كوا

import feathersApp from './feathersApp';
import Koa from 'koa';
import adapter from 'feathers-koa';

const app = new Koa();
app.use(adapter(feathersApp));

يعبر

import feathersApp from './feathersApp';
import express from 'express';
import adapter from 'feathers-express';

const app = express();
app.use(adapter(feathersApp));

بشكل أساسي ، ستنشئ المحولات برمجية وسيطة لإطار عملها الخاص.

picture jeffijoe في ٢٠ مايو ٢٠١٦
👍14

ال 22 كومينتر

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

في لمحة سريعة ، لا يبدو الأمر سيئًا للغاية مع نظام Koa. سنحتاج فقط إلى استخدام https://github.com/rkusa/koa-passport-example و ctx بدلاً من req و res . مع Hapi ، لست متأكدًا تمامًا ولكني لست مقتنعًا بوجود قيمة كبيرة في دعم Hapi ، فهو لا يقدم أي شيء مختلف عن Express. على الأقل مع Koa لديك دعم المولد.

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

ekryski picture ekryski في ١٢ مارس ٢٠١٦

لدعم المقبس مع Koa ، نستخدم هذا للإلهام: https://github.com/koajs/koa.io.

ekryski picture ekryski في ١٢ مارس ٢٠١٦

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

http-framework ! :غمزة:

ahdinosaur picture ahdinosaur في ١٦ مارس ٢٠١٦

ahdinosaur يا يبدو وكأنه أكثر الطريق الصحيح للذهاب IMHO.

ekryski picture ekryski في ١٦ مارس ٢٠١٦

أعتقد أننا يجب أن نجعل Feathers مكتبة بدلاً من إطار عمل - وهذا سيجعلها أكثر استقلالية في النقل أيضًا.

أمثلة:

الكود المشترك
const feathersApp = feathers().configure(rest());
feathersApp.service('todos', new NeDB('todos'));
export default feathersApp;
إطار محدد

كوا

import feathersApp from './feathersApp';
import Koa from 'koa';
import adapter from 'feathers-koa';

const app = new Koa();
app.use(adapter(feathersApp));

يعبر

import feathersApp from './feathersApp';
import express from 'express';
import adapter from 'feathers-express';

const app = express();
app.use(adapter(feathersApp));

بشكل أساسي ، ستنشئ المحولات برمجية وسيطة لإطار عملها الخاص.

jeffijoe picture jeffijoe في ٢٠ مايو ٢٠١٦
👍14

ملحوظة: https://github.com/spirit-js/spirit

daffl picture daffl في ١٢ أغسطس ٢٠١٦
👍4

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

rickmed picture rickmed في ١٧ أغسطس ٢٠١٦

يجب أن تكون مصادقة العلاقات العامة https://github.com/feathersjs/feathers-authentication/pull/336 هي القطعة الرئيسية الوحيدة التي نحتاجها حتى نتمكن من دعم أطر عمل مختلفة تحتها.

ekryski picture ekryski في ٣١ أكتوبر ٢٠١٦

لقد فكرت كثيرًا في هذا الأمر خلال الأيام القليلة الماضية والآن بعد أن اقتربنا من إنهاء Auk ، سيكون هذا هو الهدف الرئيسي لإصدار Buzzard. بقدر ما هو لطيف أن تكون معياريًا عند النظر إلى أرقام الاستخدام ، فإن Express لا يذهب إلى أي مكان. لقد تم تنزيل 70 مليون تنزيل هذا العام الماضي ، و Koa موجود هناك مع 1.4 مليون و Hapi مع ~ 2.4 مليون .

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

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

  • دعم http2 (الذي يبدو أنه سيأتي في express5 في النهاية ....)
  • تقليل التبعيات. القدرة على استخدام العقدة الأولية http (s) أو شيء أقل حدًا عند إنشاء واجهة برمجة تطبيقات عديمة الحالة أو خدمة مصغرة (حالة استخدام الريش الأولية)
  • كونه دليلًا على المستقبل 👍
  • أن تصبح أكثر نمطية ، بحيث يمكنك تبديل جهاز التوجيه ومحركات القوالب وما إلى ذلك. الريش هو في الحقيقة مجرد نمط معماري + أداة مساعدة فوق التقنية الأساسية.

في رأيي ، سيكون أول "محرك" لدعم بخلاف Express هو Koa. إنه الأكثر تشابهًا في التصميم مع Express ويوفر دعمًا جيدًا لوظائف لغة ES6 / ES7 المستقبلية. يبدو أيضًا أنه الأكثر طلبًا لدينا. أنا شخصياً أفضل أن أحصل على دعم لعُقَد العقدة الخام ولكن قد يتطلب ذلك الكثير من العمل.

ما الذي يجب أن يحدث

  • [] حدد واجهة برمجة تطبيقات الريش ذات المستوى الأعلى المشتركة. لا أعتقد أنه يمكننا تحديد هذا بشكل كامل حتى نجرب محركًا آخر على الأقل تحته. ومع ذلك ، أود أن يكون الأمر سهلاً مثل:

    const feathers = require('feathers');
const app = feathers();

// use by string name
app.engine('express');

// or pass the engine with string
const koa = require('koa');
app.engine('koa', koa);

// or simply pass the engine. I like this best
const koa = require('koa');
app.engine(koa);

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

  • [] تأكد من أن جميع الطرق الصريحة المستخدمة إما متعددة التعبئة أو ذات أسماء مستعارة أو نزيل الاعتماد عليها. قد يكون هناك المزيد ولكن الأشياء التي يمكنني التفكير فيها من أعلى رأسي هي:

    • app.get

    • app.set

    • app.render

    • app.send

    • app.json

    • req.accepts

    • req.xhr

  • [] جعل محرك المصادقة / النقل محايدًا (https://github.com/feathersjs/feathers-authentication/pull/336)
  • [] الاسم المستعار / تغيير كيفية تسجيل طرق REST.
  • [] الاسم المستعار / تعديل كيفية إعدادنا للمآخذ

قد يكون هناك المزيد من الأشياء. سيكون لدى daffl فكرة أفضل ، خاصة حول إعداد المقبس / الراحة.

اعتبارات أخرى

  • هل سنقوم بدعم جميع طرق فعل HTTP الخاصة بـ Express؟ هناك الكثير . ألا يعني ذلك تنفيذ الكثير من Express؟
  • ما هي الأشياء المحددة التي نعتمد عليها حاليًا؟
  • ما هي الطرق المساعدة على الكائن app التي تريد الاحتفاظ بها كجزء من واجهة برمجة تطبيقات Feathers الأساسية.
  • ما هو شكل Express 5 للمقترح؟ مر وقت منذ أن نظرت إليه. سيكون من الجيد التواصل مع dougwilson ومعرفة ما إذا كان بإمكاننا تقديم المساعدة (إذا كان ذلك منطقيًا ، فقد يكون هناك بالفعل عدد كافٍ من الطهاة في هذا المطبخ).
  • هل هناك وحدات مثل ما كان dougwilson يعمل عليه أو Spiritjs و http-framework وما إلى ذلك من شأنه أن يمنحنا النموذجية دون الحاجة إلى إعادة كتابة تلك الأفكار المجردة فوق وظائف العقدة الأساسية.
ekryski picture ekryski في ٣١ أكتوبر ٢٠١٦ 
// or simply pass the engine. I like this best
const koa = require('koa');
app.engine(koa);

متفق! بهذه الطريقة ، يمكن للأشخاص تعلم Feathers مرة واحدة ونشرها على أي خادم يحتوي على محول. فكرة عظيمة!

Download picture Download في ١ نوفمبر ٢٠١٦

يكمن التحدي في تحويل المكتبات التي تعتمد على أشياء خاصة بالاتصال مثل الرؤوس.

حول مسابقة الشعبية ، السبب الرئيسي لرغبي في استخدام Koa ليس لأنه شائع (ليس بقدر ما هو صريح) ، ولكن لأنه أكثر استقرارًا من حيث معالجة أخطاء البرامج الوسيطة.

jeffijoe picture jeffijoe في ١ نوفمبر ٢٠١٦
👍4

من فضلك دعنا ننتقل Feathers إلى بنية أكثر ملاءمة لبوابة API رفيعة (خادم ويب كلاسيكي) وخدمات ويب غبية / بسيطة يمكن نشرها بمفردها وتكون مستقلة عن البروتوكول ، فقط الاستماع إلى الرسائل ذات الأهمية (مثل أفضل الممارسات Micro Service نمط). ثم يمكننا البدء في الاندماج بسلاسة مع Seneca وأطر عمل Node.js Micro Services الشائعة الأخرى.

ونعم ، يجب أن يكون FeathersJS محايدًا بالنسبة لـ Express و Koa و Hapi ، أيا كان ...
أحب أن أراه على Nginx مع HTTP2 / Push أيضًا :)

ايام سعيدة!

kristianmandrup picture kristianmandrup في ٨ مارس ٢٠١٧

هل شاهدتم هذا https://github.com/fastify/fastify؟

أحب استخدامه مع FeathersJS ، ما هي حالة هذه المشكلة؟

andreafalzetti picture andreafalzetti في ٥ أكتوبر ٢٠١٧
👍2

andreafalzetti ما زال يتحرك إلى الأمام. يمكنك أن ترى بعض التقدم يجري هنا: https://github.com/feathersjs/feathers-express/issues/3

marshallswain picture marshallswain في ٩ أكتوبر ٢٠١٧
👍1

نعم ، سيكون من الرائع دمج الريش مع Fastify! دعنا نقوم به :)

kristianmandrup picture kristianmandrup في ١٢ أكتوبر ٢٠١٧

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

كانت خطتنا هي إزالة الاعتماد الشديد على Express وبعد الإصدار 3 ، تحقق من معنى عمليات الدمج. لقد شاهدت حديثًا على Fastify الأسبوع الماضي وبينما كان مثيرًا للاهتمام ، قد يكون من المنطقي أكثر بالنسبة للريش أن يستخدم Nodes HTTP (و HTTP2!) مع جهاز التوجيه الذي تستخدمه Fastify كتكامل رئيسي.

daffl picture daffl في ١٢ أكتوبر ٢٠١٧
👍1

لمعلوماتك ، بدأت العمل على تكامل Feathers-koa REST في Feathers-rest-koa

أعتقد أنه سيكون من المنطقي استخراج عميل REST في وحدة / حزمة منفصلة و repo ؛)

kristianmandrup picture kristianmandrup في ١٢ أكتوبر ٢٠١٧

العملاء موجودون بالفعل على https://github.com/feathersjs/feathers-rest-client أيضًا مرتبطون: https://github.com/feathersjs/feathers-express/issues/3 بواسطةchristopherjbaker

daffl picture daffl في ١٢ أكتوبر ٢٠١٧

كمبتدئ في Feathers: بحلول عام 2018 هل الريش مستقل تمامًا عن Express؟

تحرير: أو بعبارة أخرى: ما هي الأطر الأخرى المدعومة. هل KOA مدعوم بالكامل؟

شكرا! أحب الإطار وشكرا على العمل الشاق!

bitflower picture bitflower في ٢٤ يناير ٢٠١٨

اسأل daffl ، لقد كان يعمل على ذلك ... لست متأكدًا من الوضع الحالي رغم ذلك.

kristianmandrup picture kristianmandrup في ٢٤ يناير ٢٠١٨
👍1

الريش هو إطار عمل مستقل (حيث يمكنك على سبيل المثال استخدامه فقط مع @ feathersjs / socketio أو كعميل مستقل للتحدث إلى خدمات أخرى) ولكنه يحتوي فقط على روابط HTTP API لـ Express (في @ feathersjs / express ).

نظرًا لأن الهدف الكامل من Feathers هو تجريد الأشياء المحددة للبروتوكول ، فإن إطار عمل HTTP الذي يستخدمه في النهاية لا ينبغي أن يكون مهمًا حقًا ، كما أن تجريد أشياء مثل المصادقة بعيدًا عن Express يعد مهمة كبيرة جدًا (تم تصميم كل Passport من أجل Express وحتى عمليات تكامل Koa الحالية تخترق هذه الحقيقة عن طريق التلاعب بكائن الطلب الخاص بها لجعلها تبدو وكأنها Express). ستكون الأولوية القصوى لربط إطار العمل الجديد بالنسبة لي هي Node HTTP العادي والتي من خلال آلية بحث خدمة جديدة ستحقق أداءً مشابهًا لـ Fastify وتجعل اتصالات websocket أسرع.

daffl picture daffl في ٢٤ يناير ٢٠١٨
👍3

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

lock[bot] picture lock[bot] في ٧ فبراير ٢٠١٩
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

rstegg picture rstegg  ·  3تعليقات
arve0 picture arve0  ·  4تعليقات
andysay picture andysay  ·  3تعليقات
huytran0605 picture huytran0605  ·  3تعليقات
intumwa picture intumwa  ·  3تعليقات